Asmus Freytag wrote,
> And any recommendation that is not compatible with what the overwhelming
> majority of software has been doing should be ignored (or only
enabled on
> explicit user input).
>
> Otherwise, you'll just advocating for a massively breaking change.
It seems like the recommendations are already in place and the
“overwhelming majority of software” is already disregarding them.
I don’t see the massively breaking change here. Are there any
illustrations?
If legacy text containing NON-BREAK SPACE characters is popped into a
justifier, the worst thing that can happen is that the text will be
correctly justified under a revised application. That’s not breaking
anything, it’s fixing it. Unlike changing the font-face, font size, or
page width (which often results in reformatting the text), the line
breaks are calculated before justification occurs.
If a string of NON-BREAK SPACE characters appears in an HTML file, the
browser should proportionally adjust all of those space characters
identically with the “normal” space characters. This should preserve
the authorial intent.
As for pre-Unicode usage of NON-BREAK SPACE, were there ever any exlicit
guidelines suggesting that the normal SPACE character should expand or
contract for justification but that the NON-BREAK SPACE must not expand
or contract?
Received on Tue Dec 17 2019 - 19:50:12 CST
This archive was generated by hypermail 2.2.0 : Tue Dec 17 2019 - 19:50:12 CST