If you’re including many large, high-resolution photos, then yes, you will need external images. But I have wikis with at least a few hundred images, either line drawings in SVG or png, and smaller (300px or so) JPG photos. And I don’t think any of these wikis go over 9MB; all load quickly.
For a single-file wiki, dropping it to a separate file is not likely to work because of browser security restrictions. But I imaging this can be added to the Node version, and to tools like TiddlyDesktop.
Right now if you drop an image onto the tiddler editor, the image is imported by name and a link is inserted at the cursor, which sounds reasonably close.
Well, certainly. Tiddlywiki is a general-purpose tool, and print publishing is not something it was particularly designed for.
This may explain the difference in our expectations. I work in the markup all the time. I rarely use the editor toolbar button. (Pretty well never except for Excise and Preview.) So marking things up with CSS feels second nature to me, although I would almost always prefer to use classes than direct CSS properties. If I use something like this often, I might write a procedure to optimize it.
So my own workflow would probably be to drop, say, MyImage.png onto the wiki (not on the editor) and import it, then, where I want the image inside my text, to add something like:
<$image source="MyImage.png" class="right text-around" width="35%"/>
If I don’t already have CSS for the combination of “right” and “text-around”, I’ll add a <style> tag to the tiddler, and fiddle with it until I get it right. Either then or when working on the next tiddler where I need one like it, I’ll remove the <style> tag and move this to an appropriate stylesheet.
If I did have to move the images to _canonical_uris, I would probably find or write something to do that in Node. (Any substantial work I do in TW is in the Node version.) I would run this when I think of it, and perhaps as part of a build step.
I also would generally not think very much in terms of pages. It would be trivial to write a widget which simply wraps its content in a div with a class that has CSS print rules for break-before: always; and break-after: always; And we could similarly create a <<page-break>> procedure we could insert wherever we chose. But I would use these judiciously, only where I needed strong control of the layout, trusting otherwise to the natural breaking of the layout engine.
I think we have very different workflows. Maybe yours would be difficult to achieve with TW. Mine seems quite achievable. But I haven’t actually tried writing something book-length in TW, so I might well still be underestimating the challenges. My closest wiki to book length is that charter I’ve mentioned a few times, at 45 pages. The policy manual will eventually by many hundreds of pages, though, so eventually, I’ll get to see for myself.
). My suggestion about your page was that if you could lay this out in a tiddler using your usual TW tools and CSS, then this would be easy enough to incorporate into a book.
