On Wed, Aug 09, 2023 at 10:58:52PM +0000, Thorsten Glaser wrote: > Some fanfiction is written like this: > > <p>[10*U+00A0][the actual long paragraph text]</p> > > This is physical formatting done by the author to achieve some kind > of first-line indentation for the paragraphs, and it is annoying. > > This renders okay-ish in lynx, but the first p line is thus not > justified, leading to awful reading like: > > […] > The manic leader was disturbed from his thoughts as he heard > footsteps go past his door. That must be Tabby. The man looked down to the > corner > of his computer screen to see the clock display. Ah, it was breakfast > time for > […] > > I’ve looked a bit at the source code, and I understand that there > is a deliberate decision to not justify if the line contains U+00A0 > (otherwise I’d say to just do it because if people use it to align > e.g. ASCII art, it’d only work in the presence of <br /> anyway). > > Therefore I believe we need a run-time togglable (ideally per key, > like the one toggling between comment parsing modes) configuration > to switch between different modes of handling U+00A0. > > Unfortunately, I believe that we need THREE modes (a cycle toggle), > because I’ve also seen fanfiction written (or, more likely, exported > from Office software) in a way that uses not one (or more) whitespace > between words but a combination of whitespace and U+00A0 for extra > spacing the author thought prudent, or perhaps not so: > > <p>Word[U+00A0][space]next[U+00A0][space]word…</p> > > So the three modes of U+00A0 handling are: > > • do not indent lines with U+00A0 on them (current behaviour) > • do indent lines with U+00A0 on them (fixes first kind of doc) > • ignore nōn-breaking property of U+00A0 for indentation > > The third one would work like this: U+00A0 between characters > that are not whitespace will still make lynx refrain to wrap > the line at that place, but a sequence of one or more U+00A0 > or whitespace characters is treated as single whitespace (like > multiple <br /> are collapsed into one, too), so… > > <p>Word[U+00A0][space]next[space][U+00A0][U+00A0][space]word…</p> > > … renders the same as <p>Word next word…</p> but in… > > <p>(something long) 2.5[U+00A0]kg garlic (…)</p> > > … the “2.5” and “kg” are not split (although multiple U+00A0 > are still collapsed into one). > > I think offering these three as runtime-changable configuration > makes the most amount of documents render well.
...I'd consider a patch for this -- Thomas E. Dickey <dic...@invisible-island.net> https://invisible-island.net
signature.asc
Description: PGP signature
