doctools:...port::html(3tcl)

📦
version 2.0 · 2 versions
, in debian trixie, ubuntu questing, ubuntu resolute, ubuntu stonking

okay so this is doctools::toc::export::html from the Documentation tools manual, section 3tcl, and bestie… it's the HTML export plugin for tables of contents. It's long, so we're doing this in two parts, and this is part one. Buckle up. 🎀

✨ NAME ✨

doctools::toc::export::html — HTML export plugin. That's literally it. That's the whole name. Iconic, brief, no notes. 💅

🌸 SYNOPSIS 🌸

package require Tcl 8.5 9
package require doctools::toc::export::html ?0.2?
package require doctools::text
package require doctools::html
package require doctools::html::cssdefaults

export serial configuration

Look at those version numbers. Tcl 8.5 9, plugin version ?0.2?, and a whole little crew of helper packages. ✨

🦋 DESCRIPTION 🦋

Okay so, this package implements the doctools table of contents export plugin for the generation of HTML markup. That's the whole job. ToC goes in, HTML comes out, everybody claps. 👑

Now the important gossip: this is an internal package of doctools. It exists to be used by the higher level management packages that handle tables of contents — especially doctools::toc::export, the export manager. So it's giving backstage crew, not main character on the red carpet. 🎬

Can you use it from a regular interpreter? Technically yes. Is it recommended? Absolutely not. The manpage says it's possible "however only with contortions", which is the most polite way anyone has ever said "bestie, don't". 😭

The proper way to use this functionality is through the package doctools::toc::export and the export manager objects it provides. Do it that way. Fr fr. 🫶

💖 API 💖

The API provided by this package satisfies the specification of the doctoc export plugin API version 2. So it's certified, it's compliant, it ate. ✅

  • export serial configuration — this command takes the canonical serialization of a table of contents (as specified in section ToC serialization format, iykyk) and it's sitting there in serial, plus the configuration, which is a dictionary. It generates HTML markup encoding the table, and then the created string gets returned as the result of the command. In goes the serial, out comes the HTML. Slay. 💅

🌈 CONFIGURATION 🌈

Here's where it gets juicy, because the html export plugin recognizes the following configuration variables and changes its behaviour as they specify. Yes, every single one. We're not skipping anybody, everyone gets their moment. 🌟

  • string user — a standard configuration variable holding the name of the user running the process which invoked the export plugin. The plugin puts this info into the provenance comment at the beginning of the generated document. It's like a little signature. 🖊️
  • string file — a standard configuration variable holding the name of the file the table of contents came from. Heads up: this variable may not be set or may contain the empty string. If it is defined — meaning set and not the empty string — the plugin puts this information into the provenance comment at the beginning of the generated document.
  • dictionary map — a standard configuration variable holding a dictionary that maps from the (symbolic) document ids in reference entries to the actual filenames and/or urls to be used in the output. ✨

Document ids without a mapping are used unchanged. No mapping, no problem, it just vibes as-is.

  • boolean newlines — if this flag is set, the plugin will break the generated html code across lines, with each markup command on a separate line. Nice and airy. 🌬️

If this flag is not set — and that's the default — the whole document gets written on a single line, with minimum spacing between all elements. One line. The entire document. It's giving longest sentence ever, honestly. 😭

  • boolean indented — if this flag is set, the plugin will indent the markup commands according to the structure of indices. And to make that work, this also implies that newlines is set. So it drags its friend along. 🫶

If this flag is not set — again, the default — the output is formatted as per the value of newlines, and no indenting is done.

  • string meta — this variable is meant to hold a fragment of HTML. Default is empty. The fragment it contains will be inserted into the generated output in the <head> section of the document, just after the <title> tag. Perfect little sneak-in spot. 🎀
  • string header — this variable is meant to hold a fragment of HTML. Default is empty. The fragment it contains will be inserted into the generated output just after the <h1> title tag in the body of the document, in the class.header <div>'ision. 📌
  • string footer — this variable is meant to hold a fragment of HTML. Default is empty. The fragment it contains will be inserted into the generated output just before the </body> tag, in the class.footer <div>'ision. 📎
  • dictionary rid — the value of this variable (default: empty) maps references to the identifiers to use as their anchor names. Each reference FOO not found in the dictionary uses REF-FOO as anchor, i.e. itself prefixed with the string REF-. So if it's not in the map, it just gets a REF- glow-up. ✨
  • string sepline — the value of this variable is the string to use for the separator comments inserted into the output when the outpout is broken across lines and/or indented. (Yes, the manpage spells it "outpout". We love a typo era. 🙈) The default string consists of 60 dashes. Sixty. That's a lot of dashes and honestly? Respect.
  • string class.main — this variable contains the class name for the main <div>'ivision of the generated document. The default is doctools.
  • string class.header — this variable contains the class name for the header <div>'ision of the generated document. The default is toc-header. This division contains the document title, the user specified header (if any), and a visible separator line.
  • string class.title — this variable contains the class name for the <h1> tag enclosing the document title. The default is toc-title.
  • string class.navsep — this variable contains the class name for the <hr> separators in the header and footer sections of the generated document. The default is toc-navsep.
  • string class.contents — this variable contains the class name for the XXXXX holding the keywords and their references in the generated document. The default is toc-contents.
  • string class.ref — this variable contains the class name for the table elements which are references to other documents. The default is toc-ref.
  • string class.div — this variable contains the class name for the table elements which are divisions. The default is toc-div.
  • string class.footer — this variable contains the class name for the footer <div>'ision of the generated document. The default is toc-footer. This division contains a browser-visible separator line and the user specified footer, if any.
One more thing before you go configuring your heart out: this plugin ignores the standard configuration variable format, and its value. Straight up doesn't care. 💀

…and that's where part one ends, bestie — the configuration drama continues in part two. Keep scrolling, we're not done. 💖

🌸 TOC SERIALIZATION FORMAT 🌸

okay so here's the whole vibe of how the doctools v2 packages serialize tables of contents — like, turning them into immutable values so you can ship them around, compare them, whatever. bestie, this is the tea ☕

We gotta distinguish between regular and canonical serializations, okay? A table of contents can have more than one regular serialization, but exactly one of them is the canonical one. Only one. It's giving main character. 👑

✨ regular serialization ✨

  1. The serialization of any table of contents is a nested Tcl dictionary. yes, nested. buckle up. 🪆
  2. This dictionary holds a single key, doctools::toc, and its value. That value holds the contents of the table of contents.
  3. The contents of the table of contents are a Tcl dictionary holding the title of the table of contents, a label, and its elements. The relevant keys and their values are:
    • title — the value is a string containing the title of the table of contents.
    • label — the value is a string containing a label for the table of contents.
    • items — the value is a Tcl list holding the elements of the table, in the order they are to be shown. ✨

Each element is a Tcl list holding the type of the item, and its description, in this order. Another way to say it: it's a Tcl dictionary holding a single key — the item type — mapped to the item description.

The two legal item types and their descriptions are:

  • reference — this item describes a single entry in the table of contents, referencing a single document. For that, its value is a Tcl dictionary containing an id for the referenced document, a label, and a longer textual description that can be associated with the entry. The relevant keys and their values are:
    • id — the value is a string containing the id of the document associated with the entry.
    • label — the value is a string containing a label for this entry. This string also identifies the entry, and no two entries (references and divisions) in the containing list are allowed to have the same label. no duplicates, we don't do that here 💅
    • desc — the value is a string containing a longer description for this entry.
  • division — this item describes a group of entries in the table of contents, inducing a hierarchy of entries. For that, its value is a Tcl dictionary containing a label for the group, an optional id to a document for the whole group, and the list of entries in the group. The relevant keys and their values are:
    • id — the value is a string containing the id of the document associated with the whole group. This key is optional.
    • label — the value is a string containing a label for the group. This string also identifies the entry, and no two entries (references and divisions) in the containing list are allowed to have the same label. same rule as before, bestie 🫶
    • items — the value is a Tcl list holding the elements of the group, in the order they are to be shown. This list has the same structure as the value for the keyword items used to describe the whole table of contents, see above. And that right there closes the recursive definition of the structure — divisions hold the same type of elements as the whole table of contents, including other divisions. it's divisions all the way down 🐇

💅 canonical serialization 💅

The canonical serialization of a table of contents has the format as specified in the previous item, and then additionally satisfies the constraints below, which make it unique among all the possible serializations of this table of contents.

  1. The keys found in all the nested Tcl dictionaries are sorted in ascending dictionary order, as generated by Tcl's builtin command lsort -increasing -dict.

so yeah, same structure, just with everything sorted. that's the one true form. periodt. ⭐

🐛 BUGS, IDEAS, FEEDBACK 🐛

ngl, this document and the package it describes will undoubtedly contain bugs and other problems. 😭 Please report such in the category doctools of the Tcllib Trackers at http://core.tcl.tk/tcllib/reportlist. And please also report any ideas for enhancements you may have for either the package and/or the documentation — we wanna hear it, fr fr.

When proposing code changes, please provide unified diffs, i.e the output of diff -u.

Also, heads up: attachments are strongly preferred over inlined patches. You can make attachments by going to the Edit form of the ticket immediately after its creation, and then using the left-most button in the secondary navigation bar. it's right there, you got this 🫶

🔑 KEYWORDS 🔑

HTML, doctools, export, serialization, table of contents, toc

🎀 CATEGORY 🎀

Text formatter plugin

Copyright (c) 2009-2019 Andreas Kupries <andreas_kupries@users.sourceforge.net>

okay bestie that's the whole page, we made it to the end 🌈💖 this one came from tcllib, version 0.2, and it's the doctools:...port::html(3tcl) page — no date on the footer so it's giving timeless icon energy, slay ✨

📦 where this page comes from