On 1/19/2019 3:53 AM, James Kass via
Unicode wrote:
Marcel Schneider wrote,
> When you ask for knowing the foundations and that knowledge
is persistently refused,
> you end up believing that those foundations just can’t
Marcel Schneider wrote,
> When you ask for knowing the foundations and that knowledge is
persistently refused,
> you end up believing that those foundations just can’t be told.
>
> Note, too, that I readily ceased blaming UTC, and shifted the blame
elsewhere, where it
> actually belongs
On 19/01/2019 09:42, Asmus Freytag via Unicode wrote:
[…]
For one, many worthwhile additions / changes to Unicode depend on getting written up in
proposal form and then championed by dedicated people willing to see through the process.
Usually, Unicode has so many proposals to pick from that
have any hints about why some powerful UTC members
seem to hate NNBSP in French?
I’m mainly talking about French punctuation spacing here.
Which is why I suggested an “opt-in” alt form that apps wanting “civilized”
behavior could opt-into (at least for long enough that enough badly behaved
ap
On 1/18/2019 11:34 PM, Marcel Schneider
via Unicode wrote:
Current
practice in electronic publishing was to use a non-breakable
thin space, Philippe Verdy reports. Did that information come
in somehow?
==>
line wrap is typically turned off. That could
make non-breakable spaces sort of pointless (but I’m aware of your point
below), except if people are expected to re-use the data in other environments.
In that case, best practice is to use NNBSP as thousands separator while
displaying it like o
On Fri, 18 Jan 2019 10:20:22 -0800
Asmus Freytag via Unicode wrote:
> However, if there's a consensus interpretation of a given character
> the you can't just go in and change it, even if it would make that
> character work "better" for a given circumstance: you simply don't
> know (unless you
sation. We have pretty much zero feedback that the OS’s
French formatting is “uncivilized” or that the NNBSP is required
for correct support.
>> As long
as SegoeUI has NNBSP support, no worries, that’s what CLDR data
is for.
For
compat
wly that it has been used. Only by
comprehensively identifying ALL uses of comparable spaces in
various languages and scripts, you can hope to develop a
solution that doesn't simply break all non-French text in
favor of supporting French typography.
>> If they are obsolete apps, they don’t use CLDR / ICU, as these are designed
>> for up-to-date and fully localized apps. So one hassle is off the table.
Windows uses CLDR/ICU. Obsolete apps run on Windows. That statement is a
little narrowminded.
>> I didn’t look into these date
On 18/01/2019 23:46, Shawn Steele wrote:
*>> *Keeping these applications outdated has no other benefit than providing a
handy lobbying tool against support of NNBSP.
I believe you’ll find that there are some French banks and other institutions
that depend on such obsolete applic
>> Keeping these applications outdated has no other benefit than providing a
>> handy lobbying tool against support of NNBSP.
I believe you’ll find that there are some French banks and other institutions
that depend on such obsolete applications (unfortunately).
Additionally, I be
codepages that were mentioned predating
Unicode.
Whether or not NNBSP provides a better typographical experience, there are a
lot of legacy applications, and even web services, that depend on legacy
codepages. NNBSP may be best for layout, but I doubt that making it work
perfectly for thousand
or not NNBSP provides a better typographical experience, there are a
lot of legacy applications, and even web services, that depend on legacy
codepages. NNBSP may be best for layout, but I doubt that making it work
perfectly for thousand separators is going to be some sort of magic bullet
those documents
retroactively, is not acceptable.
That is however what was proposed to do in PRI #308: change Gc of NNBSP from Zs
to Pc (not to Cf, as I mistakenly quoted from memory, confusing with the
*MONGOLIAN SUFFIX CONNECTOR, that would be a format control). That would break
for example thos
On 18/01/2019 19:02, Asmus Freytag via Unicode wrote:
On 1/18/2019 7:27 AM, Marcel Schneider via Unicode wrote:
I understand only better why a significant majority of UTC is hating French.
Francophobia is also palpable in Canada, beyond any technical reasons,
especially in the IT
Marcel,
about your many detailed *technical* questions about the history
of character properties, I am afraid I have no specific
recollection.
French is not the only language that uses a space to group
figures. In fact, I grew up with thousands separators being
On 1/18/2019 7:27 AM, Marcel Schneider
via Unicode wrote:
Covering existing
character sets (National, International and Industry)
was an (not "the") important goal at
the time: such
On 1/18/2019 7:27 AM, Marcel Schneider
via Unicode wrote:
I understand only better
why a significant majority of UTC is hating French.
Francophobia is also palpable in Canada, beyond any
technical reasons, especially in the IT
reliability of
my sources. I’d already identified a number of errors but wasn’t savvy enough
for seeing the other one reported by Richard Wordingham. Now the paper ends up
as a mere libel. It doesn’t mention the lack of NNBSP, instead it piles up a
bunch of gratuitous calumnies. Should that be the
On Thu, 17 Jan 2019 18:35:49 +0100
Marcel Schneider via Unicode wrote:
> Among the grievances, Unicode is blamed for confusing Greek psili and
> dasia with comma shapes, and for misinterpreting Latin letter forms
> such as the u with descender taken for a turned h, and double u
> mistaken for a
[Just a quick note to everyone that, I’ve just subscribed to this public list,
and will look into this ongoing Mongolian-related discussion once I’ve mentally
recovered from this week’s UTC stress. :)]
Best,
梁海 Liang Hai
https://lianghai.github.io
> On Jan 17, 2019, at 11:06, Asmus Freytag via
On 1/17/2019 9:35 AM, Marcel Schneider
via Unicode wrote:
[quoted mail]
But the French "espace fine insécable" was requested
long long before Mongolian was discussed for encodinc in
e frequently limited to 8-bit
encodings (DOS, Windows, Unix(es), and even Linux at its early start).
Was there a lack of foresightedness?
Turns out that today as those characters are needed, they aren’t ready. Not
even the NNBSP.
Perhaps it’s the poetic ‘justice of time’ that since Unicode
On 17/01/2019 14:36, I wrote:
[…]
The only thing that searches have brought up
It was actually the best thing. Here’s an even more surprising hit:
B. In the rules, allow these characters to bridge both
alphabetic and numeric words, with:
* Replace MidLetter
learn why the French use of NNBSP is sort of taken with a grain of salt, while
all involved parties were knowing that this NNBSP was (as it still is) the only
Unicode character ever encoded able to represent the so-long-asked-for “espace
fine insécable.”
There is also another question I’m asking sin
was and still is present in WG2, and even if not being a
Frenchman (but knowing French), as an Anglophone he might
have been aware of the most outstanding use case of NNBSP
with English (both British and American) quotation marks
when a nested quotation starts or ends a quotation, where
ur fonts behave incorrectly on your system because it does not
> >> map any glyph for NNBSP, don't blame the font or Unicode about this
> >> problem, blame the renderer (or the application or OS using it, may
> >> be they are very outdated and were not aware of these features
Courier New was lacking NNBSP on Windows 7. It is including it on
Windows 10. The tests I referred to were made 2 years ago. I
confess that I was so disappointed to see Courier New unsupporting
NNBSP a decade after encoding, while many relevant people in the
industry were surely aware of its role
G2, and even if not being a
> Frenchman (but knowing French), as an Anglophone he might
> have been aware of the most outstanding use case of NNBSP
> with English (both British and American) quotation marks
> when a nested quotation starts or ends a quotation, where
> _‘ ”_ or _“ ’_ and _
On 16/01/2019 21:53, Richard Wordingham via Unicode wrote:
On Tue, 15 Jan 2019 13:25:06 +0100
Philippe Verdy via Unicode wrote:
If your fonts behave incorrectly on your system because it does not
map any glyph for NNBSP, don't blame the font or Unicode about this
problem, blame the renderer
On Tue, 15 Jan 2019 13:25:06 +0100
Philippe Verdy via Unicode wrote:
> If your fonts behave incorrectly on your system because it does not
> map any glyph for NNBSP, don't blame the font or Unicode about this
> problem, blame the renderer (or the application or OS usin
On Fri, 2 Oct 2015 09:25:01 +0200
Mark Davis ☕️ <m...@macchiato.com> wrote:
> We add:
>
> WB13c Mongolian_Letter × NNBSP
> WB13d NNBSP × Mongolian_Letter
>
> *If* we want to also change behavior on the other side of the NNBSP,
> whenever the Mongolian_Letter and NNBS
The background document for PRI #308 (Property Change for NNBSP),
http://www.unicode.org/review/pri308/pri308-background.html , says,
"The only other widely noted use for U+202F NNBSP is for representation
of the thin non-breaking space (espace fine insécable) regularly seen
next to ce
34 matches
Mail list logo
