Up to Main Index Up to Journal for March, 2019 JOURNAL FOR SUNDAY 31ST MARCH, 2019 ______________________________________________________________________________ SUBJECT: Now I remember… DATE: Sun 31 Mar 19:43:20 BST 2019 In my last entry I wrote: “When writing WolfMUD’s recordjar package I tried to be clever. Never bodes well does it? I think I’m starting to see a pattern here. I though it would be a good idea to only preserve meaningful white-space. This works well. Until WolfMUD reformats all outgoing text using the text.Fold function that is, then the extra effort is wasted. More importantly, should reading a jar file be monkeying around with your carefully crafted text in the first place? I have come to realise it should not.” Never bodes well indeed. While working on my little static site generator I needed to fold some text for the abstracts used on the index pages. I used WolfMUD‘s text.Fold and it broke. It simply would not fold the text properly and it took me ages to work out why. The line I was trying to fold from 80 columns to 70 columns was: A report on MUDs from December, 1990. Written by Dr Richard Bartle of MUD1 fame. An interesting read into the past. What I wanted, and what I expected to get was: A report on MUDs from December, 1990. Written by Dr Richard Bartle of MUD1 fame. An interesting read into the past. What I ended up with was: A report on MUDs from December, 1990. Written by Dr Richard Bartle of MUD1 fame. An interesting read into the past. What the hell? I ran all of the recordjar and text package tests, everything passed. I then spent hours debugging and pulling everything apart. The problem turned out to be due to the fact that text.Fold only folds text, but it does not unfold the text first. The unfolding of the text had been performed when reading the Jar and ‘only preserving meaningful white-space’. For example. Assume we have the following text: This is a split line. This is a split line after a blank line. This is an indented split line. If we only preserve meaningful white-space, so that we can fold the text later to fit any width, we end up with: This is a split line. This is a split line after a blank line. This is an indented split line. The blank lines are preserved as is the indent. Preserving only meaningful white-space in text like that is quite simple. However some of the odd, corner cases are a pain. For example: \x1b[32m An indented green line. Here we have an indented line, but it has the prefix ‘\x1b[32m’ which is the escape code to make the line green. The prefix is invisible and has a zero display width. It is expected that the indent be preserved in this case. I tried to enhance text.Fold to unfold text, before folding it, and the code became horribly complicated. I tried unfolding the text while folding it, again horrible code. I tried to implement a text.Unfold, but that kept failing on odd corner cases. It seems the best course of action would be to add the unfolding back into recordjar.Read, but I really don’t like that idea :( For now, I’m still working on my preferred solution of having a text.Unfold that handles all corner cases. WolfMUD can then read all of the zone files once, unfold all of the free text sections once, and then fold it to any width needed as often as needed. I find playing with text — folding, unfolding and formatting — an interesting area of programming for problem solving. I spent a lot of time on WolfMUD’s text.Fold function. Plain ASCII text is quite simple to handle. However, throw in multi-byte Unicode, non-spacing and enclosing marks, combining marks, escape sequences and other non-printing formatting sequences and things tend to get a lot more interesting. If you have not read it already, please take a moment to read one of my previous entries 22.html — your time is greatly appreciated. -- Diddymus Up to Main Index Up to Journal for March, 2019