The name of the tiddler containing the code should be “PrintAll” so that its content will be shown when tm-open-window
is triggered to open the “preview” window.
-e
The name of the tiddler containing the code should be “PrintAll” so that its content will be shown when tm-open-window
is triggered to open the “preview” window.
-e
It’s actually very easy to add this, and it does NOT require hiding all other content!
Instead, we use the same tm-open-tiddler
method I previously demonstrated to open a “preview” window that renders only the current tiddler. Then use your browser’s right-click popup menu to choose “print…”
Put the following content in a tiddler tagged with $:/tags/ViewToolbar
:
<$button class=<<tv-config-toolbar-class>> selectedClass=tc-selected tooltip="print this tiddler">
<%if [<tv-config-toolbar-icons>match[yes]] %>{{$:/core/images/print-button}}<%endif%>
<%if [<tv-config-toolbar-text>match[yes]] %>@@.tc-btn-text print@@<%endif%>
<$action-sendmessage $message="tm-open-window"/>
</$button>
Also, add a caption
field containing
{{$:/core/images/print-button}} print this tiddler
so it will appear properly listed in $:/ControlPanel > Appearance > Toolbars > View Toolbar
enjoy,
-e
It worked. Thanks. Place the code in the tiddler named “PrintAll” and it will work fine.
I had AI rewrite this post.
You might not believe this, but I recently stumbled upon a real pain point: our team’s wiki system is beautifully structured — hierarchical, organized, logical. But the moment you try to print it, share it, or feed it to an AI? It’s like handing someone a puzzle instead of a document.
Think about it — who actually wants to click through five layers just to read something? Most people still crave that simple, linear experience: open, scroll, done. Or better yet — print it out, grab a coffee, and flip through pages like a real book. That’s what a “human-friendly document” looks like.
So I started wondering: what if we had a “core macro” — something like the TOC macro — that could automatically flatten all hierarchical content into a single, linear document? Like pressing a 3D pop-up book flat into a clean, scrollable PDF.
Why PDF? Because reality doesn’t care about fancy tech — it cares about what works:
Let’s be honest — what people need first is a document they can just read, smoothly, from start to finish. Clickable tables of contents? That’s a luxury feature. We often assume interactivity equals progress — but sometimes, simplicity is the real kindness.
Every time I send someone a wiki link, I hold my breath: “Will they find the right section? Will they miss a nested page? Do they even know how to navigate this?” That anxiety? Gone. The moment you send a PDF.
So let’s stop hiding knowledge behind clicks. What we need is a “Flatten Everything” button — to turn structured, branching content into a linear, universally readable, AI-friendly, printer-ready PDF. That’s what knowledge deserves: no barriers, no detours, open and accessible from the first second.
After all — no matter how brilliant your content is… if people can’t open it, can’t read it, can’t share it… it might as well not exist.
I have a feeling that this goal is useful for only a quite small minority of TiddlyWikis. There are some that are definitely hierarchical. I created one along these lines (https://charter2024.andoverct.info/), and am working on another (https://crosseye.github.io/rham-policy/). But I think such wikis are rare.
On the first tiddler of the first TW most users see, TiddlyWiki is described specifically as “non-linear”. And I think that covers most usage of it. While they might have some hierarchical, linear sections, wikis tend toward random access and surfing.
Think about tiddlywiki.com. How would you arrange a linear overview? The TOC is arranged for skimming and searching, and it’s definitely not hierarchical. And if you did still decide to print it in a hierarchical manner, would you print three copies of Filter Operators
because it appears under Filters
, under Reference > Filters
, and under Reference > Concepts > Filter
? If not, how do you decide where it goes? And of course with transcluded content, would you expect to repeat it everywhere its used or somehow change it to a reference?
It’s not that I think this is a bad idea to have, but I think its scope is fairly limited. And I’m not sure how to make it generic. My two wikis that are so hierarchical are still fairly different. The charter has a fixed hierarchy. Chapters consist of sections; sections may have subsections, and subsections may have sub-subsections. Each level has a consistent numbering scheme. The policy manual has sections, which contain numbered policies. Policies are usually broken into sections, some numbered, some not. Those sections may be subdivided, and those subdivisions themselves may be, and so on, without a fixed hierarchy. Their numbering is inconsistent. Some use roman numerals, some use arabic numbers, others use letters.
I have a difficult time imagining one macro/procedure that would easily handle both of these, never mind all the other possibilities users might have for hierarchies. But I do have a print stylesheet in place for the charter, and at least the start of one for the policy manual. Because these are linear, hierarchical documents, and can be displayed that way, this is important.
I just feel that it would be hard to capture a general mechanism that wouldn’t be to constricting. But the TW community continually surprises me, so perhaps you’ll be able to come up with something.
I respect that there are situations where such a document is needed. But there are public-facing wikis where this is not at all what anyone needs! (I give my students a link to my course’s learning resources page, so they can find what they need. A printed PDF of all the tiddlers would run into hundreds of pages. And it would have to strip away all the interactive elements that make it a good learning tool!)
Then again, if an LLM suggested those phrases for you (“Let’s be honest — what people need is … So let’s stop…”), that only shows us that these mediocre prose engines tend toward a breezy “everybody-think-the-same” style.
At any rate, you don’t need to convince us that PDF is always best, or is the “true universal” — you only need to find out whether there is community interest in a PDF export tool.
Even though I would never convert-to-PDF for an entire real wiki, even I experience situations where I’d like to export a set of tiddlers in PDF form.
For now, when that happens, I choose to make one container tiddler, and in that container I set up a list filter to make sure all the needed tiddlers are transcluded. (I call this the “compilation” tiddler, because it compiles all the tiddlers I wish to display.)
Two benefits of this approach:
list-before
and list-after
fields wisely).@Springer – A little warning
If you drag & drop sort a list. All the list-before
and list-after
fields are deleted in the tiddlers that contain them.
Usually that’s not a problem, but in your usecase it most likely is one.
The “solution” is to use drag & drop sort only except you work with a read only wiki, where the next reload fixes the changes.
In my use-case, I’ve mostly disciplined myself not to drag and drop. There’s always a reason for the order, and I prefer to encode those reasons in my use of list-before and list-after. But yes, this is a good reminder to anyone about the pitfalls of trying both ways of “fixing” a list.
hihi, Yea, that’s the second option
I did experiment with custom templates for my tocP - plugin. – It works, but the templates are very usecase specific. I did test it with a “streams” outline and there where some interesting results. All of it was highly experimental and not really production ready.
My toc-rewrite should be able to handle that, but I did never test it, in the way you describe it.
As I wrote it is very use-case specific. So it highly depends on the structure of your TOC and if that toc structure is already in the right order for printing. Otherwise it would need a different “print-structure” to be able to create a linear flow that is needed for printing.
I have long held the view that there are content tiddlers and report, list or view tiddlers (in addition to code and others). As a result I would always create an additional tiddler to consolodate a view or multiple tiddlers and this stands for printing as well.
The single-page content you generated looks great. I hope that if a flatten core macro becomes available in the future, it can produce such beautiful single pages.
Here’s a thought: The knowledge structure in the human brain is non-linear, but when we need to express it, we must convert it into a linear structure.
Personal notes are non-linear, aligning with the brain’s knowledge structure. Wikis are also non-linear, well-suited for expressing complex interconnections between knowledge.
However, when the goal is information transmission, a conversion process from non-linear to linear structure is necessary to enable effective communication with others and AI. This conversion isn’t automated; it requires the author to invest significant effort and time to arrange the sequence.
Tutorials and manuals are typically linear. Currently, the content on the official TiddlyWiki website is linear. Documentation for numerous TiddlyWiki plugins uses the toc macro, which is also linear.
After reading your post, I realized that while having multiple tags for a single tiddler isn’t an issue for the toc macro, it becomes a problem when printing.
As seen in the macro from @EricShulman 's earlier post, maintaining a list of previously printed content resolves this issue. It would be even better if repeated print locations included a prompt like “This content can be found ahead at a certain point.”
Earlier I mentioned the need for a feature to customize numbering and title styles. If customization is to be avoided, then at the very least, the titles should be preceded by a numbering system like 1.1.1.7.
The AI’s statement is somewhat imprecise. Not everyone requires PDFs. However, based on the information I’ve reviewed, the number of documents I’ve read far exceeds those on wiki sites.
Exporting a specific set of tiddlers to generate documentation is indeed an excellent approach. Alternatively, this functionality could be incorporated into the flatten macro to filter out a group of tiddlers possessing a particular field value.
Specific use cases may also suit certain individuals’ needs, and publishing solutions can benefit others.
I also believe that having a tiddler that brings together all relevant content would be ready for communication with others at any time.
This AI rewrite was successful. The number of participants in the discussion increased from 2 to 5. After the AI rewrite, the effectiveness of the expression significantly improved. The AI’s text is impactful and resonates deeply, with a persuasive structure that guides the reader rather than being formulaic like my previous posts.
This AI-rewritten text style originates from ruanyifeng.com. A master of documentation.
Inspired by @Mark_S. Here’s a simple kin-based solution. This approach can flatten tiddlers and includes a directory at the front.
Add the content “<<toc test/t1>>” to the tiddler test/t1.
Select “Filer” in Advanced Search.
Enter [kin[test/t1]]
After obtaining the search results, export them to static HTML.
another:
The translink macro and $list widget can replace the “export” to generate a flattened single page.
yaisog.tiddlyhost.com’s descendants plugin can replace kin plugin.
My point, though, was that such work was custom. The flattening is hand-crafted. Look at all the complexity in the TOC macros… which still aren’t flexible enough for many. And then think of how much more flexibility we would want in a flattener. It strikes me as too complex a problem to solve generically. But I’d love to be proven wrong.
Can I suggest that if you want to work toward this, you do a custom one for a medium complexity wiki, without worrying yet about a generic approach. If that works well, then look to two or three other wikis (not your own), which have similar needs (feel free to use mine above) and see if you can find a common design that would cover all of them with reasonable amounts of customization. You don’t need to implement it, not yet: just document a design. If you can do that, I’ll be impressed and will be much more willing to try to coordinate on a generic implementation.
Tutorials, yes, almost by definition. But reference manuals usually are meant to be random access. Diátaxis has more information.
As far as I can tell, there is no way to actually make print references to specific pages.
I think customization would be necessary. There are plenty of times when an outline format would not be appropriate. Sometimes you don’t want markers at all.
Before your rewrite was posted, I count you, Tony, Eric, and Mohammad participating. After that, I still count you and Tony, and add Springer, Mario, and me; not a big difference. I don’t remember the thread from it’s early days, and I almost skipped it simply this time because the post was AI generated. I only read it because of our recent interaction on a related thread. I was barely able to read it after the click-bait style first sentence. So, in short, I don’t think AI added much to this conversation.
Note: I split some posts from here into the Page breaks for printing/PDF Generation topic, because they seemed useful stand-alone. But if you haven’t read them, it’s probably worth doing.