Wrapping of long lines

[steveculshaw]

Basic question ... does wrapping of long lines work?

I've tried toggling "Wrap" in VS Code, but the output lines are still not being wrapped ... just trimmed

This is in plain text files

[PeterWone]

Actually this isn't a basic question. It's exactly the right question, and it's one of those nasty "simple" questions that rock the foundation of an application's architecture.

In order to get print jobs to reflow according to whatever paper size, orientation, margins and scaling you specify in the browser settings - and I must do this because I can't stop you from changing them and I can't set them programmatically - I allow the browser to do the line-breaking.

When a run of text doesn't contain anything the browser recognises as a potential line-break site, it causes the behaviour you have noted.

The solution is to insert <wbr> to break up long runs. Simple, right?

Where?

• If you do it before the document renderer the tags will be treated as source text and escaped.
• If you do it in the document renderer you have to do it in every document renderer.
• If you do it after the document renderer you have to identify runs of text that are continuous, do not include tags but may contain non-block HTML elements.

The former won't work and the latter is ... complicated and expensive.

At the moment I do it in the source code document renderer but not in the plaintext renderer. The right place for it isn't in any doc renderer because this problem is global.

I'm going to have to parse a DOM and scan it for block elements and then use a state machine to scan forward through the DOM fragment computing run length.

Great question.

[steveculshaw]

Wow ... way over my head :-)

[PeterWone]

There's another thing contributing to this, the plain text renderer puts the text in a <pre> tag to get it to honour embedded linebreaks and to stop HTML from collapsing runs of whitespace. I was working on the problems I mentioned above when it dawned on me that by default <pre> doesn't wrap. For most plaintext files it would suffice to add the CSS

pre {
  white-space: pre-wrap;
}

That's two bugs you've found.

[steveculshaw]

Yikes :-( .... ;-)

[PeterWone]

Well, Steve... is it working as you would expect? I have yet to implement the fancy soft line-break opportunity strategy I mentioned, so far that's just the CSS fix.

[steveculshaw]

Peter, looks good
Actually even better than good ... the line breaks are looking "sensible", i.e. they're happening at spaces or hyphens, rather than hard breaks at the 80 character position

[PeterWone]

Here's the handling for when there's no natural line-break opportunity. I had to modify the sample to contrive this, but I assure you this has actually been reported by people printing old FORTRAN source with long names and few spaces. Look closely at the end of line 2 and you'll see I've even marked forced line-breaks with a ↩

While this is good enough for the time being I'd like to make forced breaks a bit smarter. The above works by appending a ­ (soft hyphenation point) to the end of every run of 20 characters that does not contain a natural break opportunity. I would like to also add one at linguistic natural break points like un-, anti-, counter-, -ing, -able and between certain doubled consonants (bookkeeping becomes book­keep­ing) but if I do that I have to replace my existing use of ­ with <wbr /> and use some CSS trickery to get ↩ displayed after those.

[steveculshaw]

The CSS is black magic to me :-)

The aim sounds brilliant 👍

[PeterWone]

It looks like I can only have one symbol displayed at system generated breaks. For plaintext it will be the standard hyphen, for source code it will be the ↩

Extended line-breaking will be in the next release.