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.

Thanks in advance,
//mirabilos
-- 
15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha
15:48⎜<thkoehler:#grml> also warum machen die xorg Jungs eigentlich alles
kaputt? :)    15:49⎜<novoid:#grml> thkoehler: weil sie als Kinder nie den
gebauten Turm selber umschmeissen durften?      -- ~/.Xmodmap wonders…

Reply via email to