lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lynx-dev] nōn-breaking space breaks justification


From: Thomas Dickey
Subject: Re: [Lynx-dev] nōn-breaking space breaks justification
Date: Wed, 9 Aug 2023 19:42:51 -0400

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 <dickey@invisible-island.net>
https://invisible-island.net

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]