Using TiddlyWiki to write a book, in this case non-fiction

#21

I meant mostly wikitext markup and CSS. If you could share a full-size image of that page, I could show you how I might try it. If you have the two images from it in separate files, it would be even easier – but that’s not essential.

However, it sounds like you’re interested in much more precision than I was imagining, and perhaps what I would come up with would not be nearly enough for your needs. I think it’s worth a try, though.

Just drag an image onto your wiki. That’s it. You can include them in other content with a transclusion or the $img widget. Others will have to explain external images as I haven’t had any real need for them yet. I know how to use the _canonical_uri field, but not if there’s some slick TW way to import and image and then move it externally. (Possibly in Node? Maybe not in single-file mode? I don’t know.)

Most of those sound like things that can be handled with CSS.

1 Like
#22

Thanks all for your contributions, sad that this not already a mature use of tiddlywiki, I expected it was :frowning_face:

You see during writing I would insert a description/sketch of an image example and move on. I would only think about the visual aspects at the very end. There an economy or effort worring about the whole books visual apperance at once. So for now at least its not importiant.

I have systems like Streams, tags etc… that can manage the heirachy, for me the title is just meaningful searchable text that is not included in the book. It may be different if my content needed a lot of cross referencing.

  • I expect a lot of it will be moved and expanded as I write, so I cant start with the full structure known.

Now you can drop images into the text field and it will place, the image there and save it in the wiki. One could later apply CSS to control its relationship to the text. Even single file wikis, can be used while later exporting the images to a local folder, externalising them, and linking to them.

Most importiant?

Being able to write and develop written content, specifically ideas, is the most importiant thing to me.

  • I think book marks inside text may be importiant so I can flag areas needing review or rewrite :thinking:
  • Ways to raise index references, footnotes etc… whilst writing without too much destraction.
  • Perhaps tools for others to review and edit etc… will be important even before visual considerations.

I have in the past rendered content into html and saved it, then imported it into word, which I understand is XML under the covers, and may use Word for the final layout, review and preperation. But I would only do this when 99% completed.

#23

WHAAAT!? I need to explore this at depth but that is fantastic @EricShulman !!! Even snap-to-grid. And ingenious use of fields here. A somewhat simpler use case, for me, than a full book is to create “worksheets” or “exam tests” and this could very well be what makes that possible. (A difference between those and a book, is that those things are more about crafting than authoring.)

#24

@TW_Tones I read the thread with interest. I’ve worked in editing, DTP & commercial publishing.

What Authors do is highly variable. Some methodical (outline first then write every section); some using the “bucket” method (just record fragments and let the structure emerge).

My own particular approach is to “work backwards” (envision the final output physical form and structure work to that).

It is easiest, for instance, in writing Screenplays, to understand their standard format and tweak your wiki to follow it.

But you seem to have a good grasp of a methodology for you!

TW can be bent any which way to help that.

What I don’t think you’ll get is any universal answer. I don’t think there is one for authoring.

Just side comments
TT

1 Like
#25

Footnote #362: I can attest @CodaCoder did it. I saw it. Phenomenal!

2 Likes
#26

It has been going on a while.

Some many years back (CSS 3) a commercial product, Prince, was in commercial publishing trying to replace older systems of Typographic markup (laTeX et. al.) with CSS.

That struggle is over.

Now it is easy. You can do most anything with CSS.

TT

#27

A little bit of usage and “behind the scenes” info about TiddlyTools PasteUp:

  • Rather than tracking the mouse X,Y pixel coordinates, the PasteUp layout grid is actually built from an array of $button widgets. It is these $button widgets that create the “snap-to-grid” effect. Each button is wrapped in a $draggable and $droppable widget to handle mouse interactions for moving and sizing “field rectangles” as well as the usual click handler to invoke the modal field editor interface.

  • The fields are drawn as rectangles on top of the button array and then a secondary button array (the “field grid”) is drawn on top of each field. This allows you to grab the field from any button inside it and drag to move the entire field.

  • Each field also has “drag handles” that appear in the top-left, top-right, bottom-left, and bottom-right of each field. You can use these handles to resize a field, rather than moving it. You can also use alt-click to change the field’s “layer” (bring-to-front, send-to-back), and ctrl-click to copy the field’s value to the clipboard.

  • To add a new field to the PasteUp layout, just place the mouse over an empty grid button and drag to highlight a desired target rectangle for the new field. Then click anywhere in the highlighted area to open a modal field editor and enter the new field’s name, value, and optional styles. You can also adjust the fields top,left,bottom and right coordinates. Click in the empty space in the middle of the layout inputs to set the field’s layer

  • In addition to direct mouse interaction with the PasteUp button grids, you can also perform all the same field creation and editing activities by using the “field table” that can be shown above the grid. Click on the PasteUp caption (e.g., “This is a Sample PasteUp”) to show the field table.

  • The gear icon (upper-right above the grid layout and field table) shows a “settings” popup that lets you select an image or X11 color value to use for the background of the grid, as well as inputs to specify the size of the grid array (width x height).

  • The settings popup also lets you select how many button grid “pages” are available in a tiddler’s PasteUp layout. To move a field to a different “page”, you can use drag-and-drop or use the modal grid editor or the field table to enter a page number. When printing the PasteUp layout, each page button grid is automatically printed on a separate physical page of the output.

There’s more features I could describe, but the above should be enough to get you started.

enjoy,
-e

1 Like
The Amazing PasteUp of @EricShulman
#28

Well yes. I meant here on TW, specifically. I’m sure there have been discussion threads in the past, but there seem to have been a lot of them in the last six or eight months, and @Mohammad especially has been demoing very useful print techniques.

As specified, yes. But as implemented in common browsers, there are still some gaps.

  • Widow and orphan control is not yet available in Firefox.
  • Links to page number was specified and then dropped. It’s hard to build a useful print table of contents without this.
  • In my testing, I couldn’t get break-before: right to work properly, so there seems to be no way to ensure chapters start on a right-hand page. (That may be just me. I’ve read that this is fully implemented in most browsers.)

and I’m sure there are others. However, you’re certainly correct that CSS has gotten most of the way there.

1 Like
#29

Thanks, I might get back on that. I’ll see what I can do with Erics SamplePasteUp.

As for images…

Just drag an image onto your wiki. That’s it.

Well, no, as you hint it needs to be _canonical_uri images because it’s hundreds of images.

Here’s a hypothetical workflow that would work for creating the types of image heavy books I refer to: Drag an image onto a page (i.e a tiddler) and it is added as a _canonical_uri tiddler, and its transclusion is somehow automatically injected at the position it is dropped on the tiddler text. For us tiddlywikians this may sound totally unrealistic but it is probably totally basic features for any “page making” software.

[ … ] text flowing around the image, or not… annotations

Most of those sound like things that can be handled with CSS.

Yes, I’m sure it can, it’s just that we don’t. And even if we did, for realistic use there would need to be a UI to set e.g the text flow around the image, not something like @@.textflow.floatright {{theimage}}@@ when there are several hundred pages and several images per page.

#30

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.

#31

Without, I hope, belabouring into this thread, I think these points are often central to final print output. And it’s good you cite them.

Conversion from potentially infinite length web-pages to print-ready format Is mainly simple and predictable for the “book body text”.

Now for my two cents.
Front Matter & End Matter can be very complicated in physical books.
There are various conventions on Lead-Ins & Lead-Outs.

Pretty much, if going for commercially printing a book (not a handout), they (front & end) are easiest handled in a bespoke manner (in cognizance of the necessary publisher’s “style manual”).

Side thoughts
TT

#32

I know things have moved on in this thread, but, just to prove I’m not mad…

From the Google groups discussion :

https://groups.google.com/g/tiddlywiki/c/_VLufc4Svp8/m/tOuaKenGAwAJ

I’ve no idea if they continue to use TW to publish…

1 Like
#33

Their “read an extract” still goes to a TW version of things, I’m guessing TW is their “web version” format.

5.1.22-prerelease

1 Like
#34

I have come to realise as I start to work on this book is I most likely need to read a lot. so although my wiki is for writing it is now also about reading and research.

2 Likes