[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
signature.asc
Description: PGP signature