doctools::t...export::html(n)

📦
version 2.0 · 2 versions
, in fedora 43, fedora 44, nixos 26.05, nixpkgs unstable

💖 doctools::toc::export::html — HTML export plugin 💖

okay bestie, welcome to the manual page for doctools::toc::export::html, part of the doctools docs tooling (that's the <pink>Documentation tools</pink> vibe). This is part 1 of 2, so buckle up, we are not done yet 🎀

✨ NAME ✨

doctools::toc::export::html — the HTML export plugin. she exports HTML. that's the whole thing. iconic 💅

🌸 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

like. look at her. ?0.2? is optional, everything else is required, no cap.

🦋 DESCRIPTION 🦋

So this package implements the doctools table of contents export plugin for generating HTML markup. that's her whole job and she does it well ✨

Real talk though: this is an internal package of doctools. It's meant to be used by the higher level management packages that handle tables of contents — especially doctools::toc::export, aka the export manager. 👑

Can you use it from a regular interpreter? Technically yes. Should you? no bestie. The original is very clear that it's possible "only with contortions", and it is not recommended. contortions!! like a whole gymnastics routine just to call a plugin. not the vibe. 🙈

The proper way to use this functionality is through the package doctools::toc::export and the export manager objects it provides. that's the main character path. do that one. 💖

👑 API 👑

The API this package gives you satisfies the spec of the doctoc export plugin API version 2. periodt.

  • export serial configuration — this command takes the canonical serialization of a table of contents (as specified in the section ToC serialization format, which lives in serial), plus the configuration, which is a dictionary, and generates HTML markup encoding that table. The created string gets returned as the result of the command. slay 🫶

🌈 CONFIGURATION 🌈

The html export plugin recognizes these configuration variables and changes her behaviour based on what you give her. she's flexible like that 💁‍♀️

  • string user — the standard config variable holding the name of the user running the process that invoked the export plugin. She drops this info into the provenance comment at the very beginning of the generated document. credit where credit is due 💜
  • string file — the standard config variable holding the name of the file the table of contents came from. Heads up: this variable may not be set, or it may be the empty string. If it is defined (meaning: set and not the empty string), she puts it into the provenance comment at the beginning of the generated document. no empty-string shenanigans allowed ✋
  • dictionary map — a standard config variable containing a dictionary that maps from the (symbolic) document ids in reference entries to the actual filenames and/or urls to use in the output. And here's the little detail: document ids that don't have a mapping get used unchanged. no map, no makeover. 💅
  • boolean newlines — if this flag is set, the plugin breaks the generated html code across lines, with each markup command on its own separate line. if it is not set (which is the default), the whole document gets written on a single line, with minimum spacing between all elements. one line. everything. a whole wall of html. 😭
  • boolean indented — if this flag is set, the plugin indents the markup commands according to the structure of indices. And to make that actually work, setting this also implies that newlines is set. if it's not set (the default), the output is formatted per the value of newlines and no indenting happens at all. the two are a package deal, iykyk 🎀
  • string meta — this variable is meant to hold a fragment of HTML (default: empty). The fragment it contains gets inserted into the generated output in the <head> section of the document, just after the <title> tag. right there, snug. ✨
  • string header — this variable is meant to hold a fragment of HTML (default: empty). The fragment it contains gets inserted into the generated output just after the <h1> title tag in the body of the document, inside the class.header <div>. yes she really does say <div>'ision in the original and honestly? iconic 💀
  • string footer — this variable is meant to hold a fragment of HTML (default: empty). The fragment it contains gets inserted into the generated output just before the </body> tag, inside the class.footer <div>. bottom of the page energy 🦋
  • dictionary rid — the value of this variable (default: empty) maps references to the identifiers to use as their anchor names. Each reference FOO that isn't found in the dictionary uses REF-FOO as its anchor — that is, itself prefixed with the string REF-. so if you don't map it, she just adds REF- and moves on. no cap 🌸
  • string sepline — the value of this variable is the string to use for the separator comments inserted into the output when the output is broken across lines and/or indented. The default string consists of 60 dashes. sixty. that's a lot of dashes and she's committed to every one of them. ✨
  • string class.main — this variable contains the class name for the main <div> of the generated document. The default is doctools. that's the whole main character division right there 👑
  • string class.header — this variable contains the class name for the header <div> 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. those little lines are doing so much work 🎀
  • 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. (yes, XXXXX is literally what it says in the source. we love a mysterious placeholder 💀)
  • 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> 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 bestie: this plugin ignores the standard configuration variable format, and its value. completely. doesn't even look at it. do not bother setting it, she will not read it. 💀

and that's where part 1 wraps... but wait, there's more 👀

✨ TOC SERIALIZATION FORMAT ✨

Okay bestie, so this bit is where we spec out the format that the doctools v2 packages use to serialize tables of contents — turning them into immutable values so they can be transported, compared, all that good stuff. 🎀

We distinguish between regular and canonical serializations, and this is important: while a table of contents may have more than one regular serialization, only exactly one of them will be canonical. One. Singular. The main character. 👑

🌸 regular serialization 🌸

  1. The serialization of any table of contents is a nested Tcl dictionary. 🪆
  2. This dictionary holds a single key, doctools::toc, and its value. This 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. An alternative description would be that it is 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. To this end its value is a Tcl dictionary containing an id for the referenced document, a label, and a longer textual description which 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. 🚨
    • 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. To this end 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. 💅
    • 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. This closes the recusrive definition of the structure, with divisions holding the same type of elements as the whole table of contents, including other divisions. 🌀

🦋 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.
That's it. That's the whole constraint. One little rule and suddenly there's only one true version of your toc. Iconic behaviour honestly. ✨

💀 BUGS, IDEAS, FEEDBACK 💀

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 [http://core.tcl.tk/tcllib/reportlist](http://core.tcl.tk/tcllib/reportlist). Please also report any ideas for enhancements you may have for either package and/or documentation. 🫶

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

Note further that attachments are strongly preferred over inlined patches. Attachments can be made 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. 📎

🌈 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 that's the whole page bestie, you made it to the end, so proud of you 🥹💖 this one came from tcllib, version 0.2, dated doctools::t...export::html(n) — go forth and serialize responsibly, no cap. 🦋✨

📦 where this page comes from