How do you group symbols without the word "Topics" displaying?

From Adding Structure to Your Documentation Page:

A collection contains a Topics section, which instructs DocC to treat what would otherwise be an article as a collection.

Using ## Topics does make it so that symbols show up as full signatures, rather than links that have the symbol names.

But, for example, a set of top-level functions is not "Topics". What can be done?

It's a bit difficult to tell what top-level functions you are looking to group and on what page you are looking to group them but I'll try to give a general description of how I approach topic sections and API collections in DocC.

To have something concrete to talk about, I'll pretend to document a 2D graphics API with functions like these:

func addRectangle(_ rect: Rect)
func addCircle(in rect: Rect)
func addLine(from: Point, to: Point)
func addPath(_ path: Path)
func fill(color: Color)
func stroke(color: Color, width: Double)
func mask(clipShape: Path)

If I do nothing, these will all be automatically be grouped into a "Functions" topic section on the top-level page (since they're top-level functions).

I could move all of them into an unnamed topic sections like this:

## Topics

- ``addRectangle(_:)``
- ``addCircle(in:)``
- ``addLine(from:to:)``
- ``addPath(_:)``
- ``fill(color)``
- ``stroke(color, width)``
- ``mask(clipShape:)``

or a named topic section like this:

## Topics

### My graphics functions

- ``addRectangle(_:)``
- ``addCircle(in:)``
- ``addLine(from:to:)``
- ``addPath(_:)``
- ``fill(color)``
- ``stroke(color:width:)``
- ``mask(clipShape:)``

Neither of these options meaningfully change the organization of the documentation because all the same functions are grouped the same as the automatic topic section. I can use the authored topic section to order the functions within the group, but that's about it.

However, looking at what these functions are used for I can identify at least 3 different categories of behavior: "adding shapes", "drawing", "masking/clipping". These categories translate into "topics" in DocC and I could organize the functions into these topic sections to make it easer for readers to understand your API:

## Topics

### Adding shapes

- ``addRectangle(_:)``
- ``addCircle(in:)``
- ``addLine(from:to:)``
- ``addPath(_:)``

### Drawing

- ``fill(color:)``
- ``stroke(color:width:)``

### Masking

- ``mask(clipShape:)``

For a small API like this example, a few topic sections on the top-level page is probably sufficient to organize the API well. However, for larger API surfaces it may become infeasible to list everything on a single page.

Leveraging types (structs, classes, enums, protocols, etc.) with members (properties, methods, etc) in the API provides additional default organization but if the API is large enough, it may be difficult to listing all the top-level types on a single page. In such cases, using "API collection" pages can be a great way to further break down the API into smaller groups.

For example, imagine that this 2D graphics framework included a lot more drawing API such as gradients, advanced blend modes, color spaces, image patterns, shadows, line dash patterns, line join styles, line cap styles, and more. These are all related to "drawing" but they can also be organized into smaller subcategories. One way to think of "subcategories" in DocC is topic sections on an API collection. For example, I could create a "drawing" API collection and organize the various drawing API like this:

# Drawing

A brief overview of the drawing API in this library

## Topics

### Gradients

- ``fill(gradient:)``
- ``LinearGradient``
- ``RadialGradient``

### Working with colors

A brief overview of colors and color management in this API.

- ``Color``
- ``BlendMode``
- ``ColorSpace``

### Stroking shapes

- ``stroke(color:width:dashPhase:lineCap:lineEnd)``
- ``LineCapStyle``
- ``LineEndStyle``

...

The API collection itself can contain arbitrary content but it's commonly not more than a few paragraphs.

If you find that an API collection doesn't need to be break down the symbols that it organizes into further subcategories, then it's possible that the scope of the API collection is too narrow and that those symbols could instead be organized in a topic section one level higher. If the rest of the content of that API collection is short it can be included inline in that topic section:

## Topics

...

### Working with colors

A brief overview of colors and color management in this API.

Another paragraph that talks more about working with colors in this API.

- ``Color``
- ``BlendMode``
- ``ColorSpace``

If the rest of the content of that API collection is very long and detailed, it's possible that it's better suited as an article, without any topic sections.

If you still want to display a list of links in an article without changing the hierarchical organization of your documentation you can use the @Links directive.

Take these operators as an example. There is surely more work that could be done to categorize them further. But as it is, it would be a fast improvement to the one-level-higher page to just move them into a separate article.

This seems to be the answer. Thank you!

However, this is different than ## Topics in that a horizontal line doesn't render above. A small number of hyphens don't render as that line, as they do in other environments:


How can we achieve :point_up_2:?