Syntax highlighting is easy to dismiss as decoration until the same code sample has to survive a website, a terminal, a document, and a slide deck. Each destination has its own color rules, escaping behavior, font assumptions, and output format. Copying from an editor works once. Automating publication requires a converter that treats highlighted code as build output.
Saalen/highlight is built for that job. It reads programming or markup source and emits highlighted material for web pages, rich-text documents, typesetting systems, vector graphics, chat markup, and terminals. The project is written in C++, published under the GNU General Public License version 3.0, and provides both a command-line interface and an optional Qt graphical interface (Qt is a cross-platform toolkit for desktop applications).
The useful framing is not “another pretty code viewer.” Highlight can sit between a source repository and several publishing targets, with language definitions, themes, line numbers, wrapping, and batch behavior controlled in one place. That makes it interesting for documentation pipelines where repeatability matters more than manually choosing colors.
One parser can feed several publishing paths
The source lists a wide output range: HTML, XHTML, RTF, ODT, LaTeX, TeX, SVG, BBCode, Pango markup, and multiple terminal color modes. That spread covers substantially different consumers.
HTML and XHTML fit documentation sites. RTF and ODT target word-processing workflows. LaTeX and TeX fit technical publishing. SVG preserves highlighted code as a vector asset. BBCode and Pango markup serve narrower systems, while ANSI output supports terminal display.
A shared converter can prevent small inconsistencies from multiplying across those destinations. The same input language and theme can drive a web snippet, a printable document, and a command-line preview. The rendered forms will not be visually identical because each output medium has different capabilities, but the token classification and palette can start from one source of truth.
That enables a cleaner build design:
- Keep code canonical. Store the source sample once rather than pasting styled copies into every document.
- Choose output at build time. Generate HTML, SVG, terminal escapes, or document markup for each destination.
- Version the theme. Review palette changes like any other documentation change.
- Pin command options. Make line numbering, wrapping, fonts, and stylesheets reproducible.
- Regenerate instead of editing. Treat highlighted artifacts as disposable products of the source.
Those are editorial recommendations based on the tool’s described capabilities. The imported overview does not prescribe a particular build system.
The terminal modes deserve separate attention. Highlight can produce ANSI, 256-color, and true-color output. ANSI refers to terminal escape sequences that control color and styling. A basic palette is more portable, while true color permits a much larger range on terminals that support it. A pipeline should choose the least demanding mode that still communicates the code clearly.
Language rules and themes are separate controls
Highlight recognizes common token classes such as keywords, types, strings, numbers, comments, operators, and preprocessor directives. The project supports customizable language descriptions and color themes implemented with Lua (a small scripting language often embedded in applications). Plug-ins can modify or extend both areas, according to the source.
Separating language recognition from visual presentation is the right abstraction. A parser decides that a token is a comment. A theme decides whether that comment is gray, italic, or otherwise styled. Mixing those decisions would make every color change a language-maintenance problem.
Nested languages add another layer. A single file may contain HTML, CSS, JavaScript, a template language, or embedded queries. The source says Highlight recognizes nested programming languages within files. That is important for realistic web templates and documentation examples, where one-language assumptions fall apart quickly.
Custom definitions also create a maintenance question. If a team adds an internal configuration language, it now owns a small parser description. Useful tests would include:
- Representative keywords and identifiers.
- Strings with escaped delimiters.
- Single-line and multi-line comments.
- Embedded or nested language regions.
- Malformed input that should fail gracefully.
- Theme output with readable contrast.
This test list is editorial guidance. The source confirms custom definitions and nested-language support but does not claim that every private grammar can be represented without work.
Plug-ins should be treated as code, not harmless theme files. A documentation team can review them, pin their versions, and run the converter in a constrained build environment. That operational discipline is especially relevant when source samples come from outside the repository.
Command-line operation is the real automation surface
The optional Qt interface offers live output previews, which is useful while choosing a theme or testing language recognition. The command line is where Highlight becomes repeatable infrastructure. It can process a single file, consume standard input, or traverse batches recursively, according to the source.
Standard input is valuable because it allows another program to generate or filter a snippet without creating an intermediate source file. Recursive batch processing is useful for a documentation tree, but it should be paired with explicit include rules so generated directories and vendored code do not become accidental inputs.
Configuration extends beyond color. The source identifies line numbering, wrapping, fonts, and stylesheets as controllable features. It also says the tool can reformat and indent C, C++, C#, and Java. Reformatting changes content presentation rather than merely annotating tokens, so I would keep it disabled in a fidelity-sensitive pipeline unless the team explicitly wants normalized examples.
A practical workflow could divide preview and production duties:
- Use the graphical preview to compare themes on difficult code samples.
- Save the chosen language and theme definitions in version control.
- Run the command line with pinned flags during documentation builds.
- Compare generated artifacts in review when themes or converter versions change.
- Publish only artifacts produced by the build, not manually edited copies.
No benchmark or timing claim is implied here. The imported source describes interfaces and batch modes, not conversion speed on a particular repository.
Semantic tokens can improve difficult code
Highlight supports Language Server Protocol features, including semantic tokens and syntax-error information. The Language Server Protocol (LSP, a standard way for editors and language tools to exchange code intelligence) can provide meaning that a text grammar cannot infer from characters alone.
A lexical highlighter may color every identifier with the same rule. Semantic information can distinguish a type, method, parameter, property, or namespace based on the language server’s analysis. That can make complicated examples easier to read, particularly where identical spelling appears in different roles.
Syntax-error information also helps a publishing pipeline detect that an example may be incomplete or invalid. It should not automatically block every fragment because documentation often shows partial code deliberately. Instead, a team can decide which directories require complete compilable examples and which permit snippets.
The feature introduces dependencies. Semantic output relies on an appropriate language server and whatever project context that server needs. A standalone conversion may be simpler and more portable. An LSP-assisted conversion may be richer but harder to reproduce outside the original build environment.
That choice should follow the document. A short shell command does not need semantic analysis. A dense C++ API example may benefit from it. Use the extra machinery where it changes comprehension, not merely because the option exists.
Where Highlight fits among other highlighters
The imported directory names Prism, Re-Highlight, Chroma, Pygments, Rouge, and Highlight.js as related tools. Those projects occupy different runtimes and integration models. A browser application may prefer a JavaScript library. A Python documentation stack may already have Pygments. A Go service may find Chroma convenient. A Ruby site may favor Rouge.
Highlight’s case is strongest when output diversity and command-line use matter. Generating terminal colors, office-document formats, TeX-family markup, SVG, and web output from one converter is a different requirement from highlighting code inside one browser page.
The comparison should begin with the consuming systems:
- Does rendering happen during a build or in a reader’s browser?
- Must the same sample appear in web, print, and terminal contexts?
- Are custom languages or nested grammars required?
- Is a desktop preview helpful to the people maintaining themes?
- Does the license fit how the converter or its output will be distributed?
A project should also test its own code corpus. Fixed language names on a feature page do not reveal how a tool handles unusual templates, generated code, giant lines, or deliberately incomplete snippets.
Trade-offs
Output breadth is the first cost. Every target format has different limits, so a theme that reads well in true-color terminals may not translate cleanly to a small ANSI palette or a word-processing document.
Customization creates another cost. Lua definitions and plug-ins give teams control, but custom grammars and themes become maintained assets that need review and tests.
Semantic analysis adds setup cost. LSP-based tokens can classify code more precisely, while requiring a language server and enough project context to make its answers reproducible.
Reformatting is a separate risk. Automatic indentation for C-family languages and Java may improve display, but it can also make published code differ from the source being explained. Keep presentation and content changes distinct.
License review also matters. Highlight is GPLv3 software. The source establishes that license, but it does not answer every distribution question for a specific organization or product.
Bottom line
Saalen/highlight is worth evaluating when source code needs to become several kinds of publishable artifact. Its advantage is the combination of many output formats, scriptable language and theme rules, terminal support, batch operation, and an optional visual preview.
I would use it as a build tool: keep code and configuration under version control, generate artifacts deterministically, and test the ugliest examples in the repository before standardizing on a theme. If the only target is one browser page, a runtime-native library may be simpler. If the same code must travel across web, documents, typesetting, and terminals, Highlight’s broader converter model earns its place.