On Mon, 23 Jan 2017 10:30:17 +0100 (CET), I wrote:
> […] I now believe and will
> spread the word that […] on the other
> hand, the recommendations in TUS may be considered a mere official discourse
> for
> encoding process management purposes, but with little through no real impact
> on
> a
On Sat, 16 Jul 2016 06:14:45 +0200 (CEST), I wrote(1):
> I note that now that the Unicode repertoire is built at cruise speed,
> few to no feedback items are reported.[1][2]
> [1] http://www.unicode.org/review/pri327/feedback.html
> [2] http://www.unicode.org/review/pri328/feedback.html
It see
On Fri, 7 Jul 2017 16:14:04 +0100 (BST), William_J_G Overington via Unicode
wrote:
>
[…]
>
> For example, it mentioned the u diaeresis used in French, though I learned
> later that words that have a u diaeresis in French are rather rare.
>
Today, words containing 'u diaeresis' have become more
stays the old way: "Tronoën", "Citroën". Since Iʼve been kindly
informed off-list that this point of the reform actually “regularizes” (as you
put it) a mistake, Iʼll have to make use of the optionality of applying the new
rules, and reset the words in my files to the old
On Tue, 23 Jan 2018 21:52:46 +, Richard Wordingham wrote:
>
> On Wed, 24 Jan 2018 03:22:37 +0800
> Phake Nick via Unicode wrote:
>
> > >I found the Windows 'US International' keyboard layout highly
> > >intuitive for accented Latin-1 characters.
> > How common is the US International keyboa
On Sun, 28 Jan 2018 05:02:47 +, Richard Wordingham via Unicode wrote:
>
> On Sat, 27 Jan 2018 22:54:57 +0100 (CET)
> Marcel Schneider via Unicode wrote:
>
> > The US-Intl is so weird “you canʼt just leave it on all the time” as
> > reported in:
> >
> &
On Sun, 28 Jan 2018 16:20:16 -0700, Doug Ewell wrote:
>
> Mark Davis wrote:
>
> > One addition: with the expansion of keyboards in
> > http://blog.unicode.org/2018/01/unicode-ldml-keyboard-enhancements.html
> > we are looking to expand the repository to not merely represent those,
> > but to also
On Sun, 28 Jan 2018 14:11:06 -0700, Doug Ewell wrote:
>
> Marcel Schneider wrote:
>
> > We can only hope that now, CLDR is thoroughly re-engineering the way
> > international or otherwise extended keyboards are mapped.
>
> I suspect you already know this and just misspoke, but CLDR doesn't
> pre
On Sun, 28 Jan 2018 21:56:25 -0800, Mark Davis replied to Doug Ewell:
>
> It is not a goal to get "vendors to retire these keyboard layouts and
> replace them" — that's not our role. (And I'm sure that a lot of people
> like and would continue to use the Windows Intl keyboard.)
Instead of “replac
BTW the 5 dead keys of Windows US Intl are already on
Appleʼs *normal* US layout, along with the letter o-with-e.
US Extended adds 20 more deadkeys.
On Sun, 28 Jan 2018 16:20:16 -0700, Doug Ewell wrote:
[…]
> Nothing in the PRI #367 blog post or background document communicated to
> me that CLD
On Mon, 29 Jan 2018 16:07:11 -0700, Doug Ewell wrote:
>
> Marcel Schneider wrote:
>
> > Prior to this thread, I believed that the ratio of Windows users
> > liking the US-International vs Mac users liking the US-Extended was
> > like other “Windows implementation” vs “Apple implementation” ratios
OnMon, 29 Jan 2018 11:13:21 -0700, Tom Gewecke wrote:
>
> > On Jan 29, 2018, at 4:26 AM, Marcel Schneider via Unicode wrote:
> >
> >
> > the Windows US-Intl
> > does not allow to write French in a usable manner, as the Œœ is still
> > missing, and
On Tue, 30 Jan 2018 08:54:19 -0700, Tom Gewecke wrote:
>
> > On Jan 30, 2018, at 3:20 AM, Alastair Houghton wrote:
> >
> > The “alt” annotation isn’t on the latest keyboards (go look in an Apple
> > Store if you don’t believe me :-)).
>
> Interesting! Apple’s documentation shows these keys mos
On Tue, 30 Jan 2018 10:20:46 +, Alastair Houghton wrote:
>
> On 30 Jan 2018, at 05:31, Marcel Schneider via Unicode wrote:
> >
> > OnMon, 29 Jan 2018 11:13:21 -0700, Tom Gewecke wrote:
> >>
[…]
> >>
> >> They are also all on the MacOS "
On Tue, 30 Jan 2018 11:34:40 -0700, Doug Ewell via Unicode wrote:
>
> Marcel Schneider wrote:
>
> > That tends to prove that Mac users accept changes, while Windows users
> > refuse changes.
>
> I was going to say that was a gross over-generalization, but that didn't
> adequately express how gro
On Tue, 30 Jan 2018 11:50:49 -0700, Doug Ewell wrote:
>
> Marcel Schneider wrote:
> >
> > http://recycledknowledge.blogspot.com/2013/09/us-moby-latin-keyboard-for-windows.html
> >
> >
> > Sadly the downloads are still unavailable (as formerly discussed). But
> > I saved in time, too (June 2015
On Tue, 30 Jan 2018 08:18:49 +0100, Philippe Verdy wrote:
>
> I have always wondered why Microsoft did not push itself at least the five
> simple additions needed since long in French for the French AZERTY LAYOUT:
Many people in Fɽanƈë are wondering, but it is primarily a matter of honoring
a co
On Tue, 30 Jan 2018 23:30:59 +, David Starner via Unicode wrote:
>
> On Tue, Jan 30, 2018 at 2:23 AM Alastair Houghton via Unicode wrote:
>
> > This pattern exists across the board at the two companies; the Windows API
> > hasn’t changed all that much
> > since Windows NT 4/95, whereas Apple
On Wed, 31 Jan 2018 19:05:17 +0100, Philippe Verdy wrote:
>
> Another idea: you can already have multiple layouts loaded for the same
> language : For French, nothing prohibits to have a "technical/programmer
> layout", favoring input of ASCII, a "bibliographic/typographical" one with
> improved c
Approx. 400 or more subscribers of Unicode Public happen not to be subscribed
to CLDR-Users.
Now there is a thread that might be of some interest also to non-CLDR‑users.
Itʼs about some main functionalities of keyboards intended for many locales,
not about specific details of a particular locale
On 17/02/18 13:43, Christoph Päper via Unicode wrote:
[…]
> Stuff like typography or emoji can improve the effectiveness and efficiency
> of textual communication a lot. (And if used badly or maliciously they can
> deter it as well.)
>
Since poor typography can deteriorate our communication as w
On 17/02/18 21:01, Doug Ewell via Unicode wrote:
[…]
>
> I've linked Manish's post on FB as a reply to one of those mainstream
> articles that repeatedly calls the conjunct a "single character,"
> written by a staffer who couldn't be bothered to find out how a writing
> system used by 78 millio
On Sun, 18 Feb 2018 20:06:42 +, Richard Wordingham via Unicode wrote:
[…]
> Unicode also avoids text that is 'wrong' but still comprehensible.
>
Unicode should then legalize the use of preformatted superscripts in Latin
script.
This convention appears to root back in medieval Latin, for whi
On Mon, 5 Mar 2018 20:19:47 +0100, Philippe Verdy via Unicode wrote:
> There's been significant efforts to "translate" or more precisely "adapt"
> significant parts of the standard with good presentations in Wikipedia and
> various sites for scoped topics. So there are alternate charts, and ins
On Mon, 5 Mar 2018 20:19:47 +0100, Philippe Verdy via Unicode wrote:
[…]
> * the core text of the standard (section 3 about conformance and requirements
> is the first thing to adapt).
> There's absolutely no need however to do that as a pure translation, it can
> be rewritten and presented
> wit
On Thu, 8 Mar 2018 09:03:28 +, Richard Wordingham via Unicode wrote:
>
> > Yes the biggest issue over time, as Ken wrote, is to *maintain* a
> > translation, be it only the Nameslist.
>
> For which accurately determined change bars can work wonders. An
> alternative would be paragraph identif
On Thu, 08 Mar 2018 04:25:53 -0500, Elsebeth Flarup via Unicode wrote:
>
> For a number of reasons I think translating the standard is a really bad idea.
>
[…]
>
> There are other reasons to not do this.
I assume that the reasons you are thinking of, are congruent with those that
Ken already e
On 08/03/18 19:33, Arthur Reutenauer wrote:
>
> On Thu, Mar 08, 2018 at 07:05:06PM +0100, Marcel Schneider via Unicode wrote:
> > https://www.amazon.fr/Unicode-5-0-pratique-Patrick-Andries/dp/2100511408/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1206989878&sr=8-1
>
> You’
On Fri, 9 Mar 2018 08:41:35 -0800, Ken Whistler wrote:
>
>
> On 3/9/2018 6:58 AM, Marcel Schneider via Unicode wrote:
> > As of translating the Core spec as a whole, why did two recent attempts
> > crash even
> > before the maintenance stage, while the 3.1 project
On 11/03/18 21:05, Arthur Reutenauer wrote:
>
> On Sun, Mar 11, 2018 at 07:35:11PM +0100, Marcel Schneider via Unicode wrote:
> > I fail to understand why increasing complexity decreases the need to be
> > widely understood.
>
> I’m pretty sure that everybody will agre
On Fri, 9 Mar 2018 08:41:35 -0800, Ken Whistler wrote:
>
>
> On 3/9/2018 6:58 AM, Marcel Schneider via Unicode wrote:
> > As of translating the Core spec as a whole, why did two recent attempts
> > crash even
> > before the maintenance stage, while the 3.1 project
On Mon, 12 Mar 2018 07:39:53 +, Alastair Houghton wrote:
>
> On 11 Mar 2018, at 21:14, Marcel Schneider via Unicode wrote:
> >
> > Indeed, to be fair. And for implementers, documenting themselves in English
> > may scarcely ever have much of a problem, no
On Mon, 12 Mar 2018 10:00:16 +, Andrew West wrote:
>
> On 12 March 2018 at 07:59, Marcel Schneider via Unicode
> wrote:
> >
> > Likewise ISO/IEC 10646 is available in a French version
>
> No it is not, and never has been.
>
> Why don't you che
On Mon, 12 Mar 2018 14:55:28 +, Michel Suignard wrote:
>
> Time to correct some facts.
> The French version of ISO/IEC 10646 (2003 version) were done in a separate
> effort by Canada and France NBs and not within SC2 proper.
> National bodies are always welcome to try to transpose and transl
, but
they then pick up a new designation, e.g. ANSI for US or DIN for German or EN
for European Norm.
A./
2018-03-13 19:38 GMT+01:00 Asmus Freytag via Unicode :
On 3/13/2018 11:20 AM, Marcel Schneider via Unicode wrote:
On Mon, 12 Mar 2018 14:55:28 +, Michel Suignard wrote:
Time to
William,
On 29/03/18 17:03 William_J_G Overington via Unicode wrote:
>
> I have been thinking about issues around the proposal.
> http://www.unicode.org/L2/L2018/18080-accessibility-emoji.pdf
> There is a sentence in that document that starts as follows.
>
> > Emoji are a universal language and
We need to get more scripts into Unicode, not more emoji.
That is — somewhat inflated — the core message of a NYT article published six
months ago,
and never shared here (no more than so many articles about Unicode, scripts,
and emoji).
Some 100 scripts are missing in the Standard, affecting as
On Sat, 14 Apr 2018 20:29:40 -0700, Markus Scherer wrote:
>
> On Sat, Apr 14, 2018 at 5:50 PM, Marcel Schneider via Unicode wrote:
> >
> > We need to get more scripts into Unicode, not more emoji.
> >
> > That is — somewhat inflated — the core message of a NYT art
In the wake of the new release, may we discuss the reason why UTC persisted in
recommending that 3 pairs of mathematical symbols featuring tildes are mirrored
in low-end support by glyph-exchange bidi-mirroring, with the result that
legibility
of tildes is challenged, as demonstrated for “Remed
On Thu, 17 May 2018 09:43:28 -0700, Asmus Freytag via Unicode wrote:
>
> On 5/17/2018 8:08 AM, Martinho Fernandes via Unicode wrote:
> > Hello,
> >
> > There are several mentions of synchronization with related standards in
> > unicode.org, e.g. in https://www.unicode.org/versions/index.html, and
On Thu, 7 Jun 2018 15:20:29 +0200, Mark Davis ☕️ via Unicode wrote:
>
> A few facts.
>
> > ... Consortium refused till now to synchronize UCA and ISO/IEC 14651.
>
> ISO/IEC 14651 and Unicode have longstanding cooperation. Ken Whistler could
> speak to the
> synchronization level in more detail,
On Thu, 17 May 2018 22:26:15 +, Peter Constable via Unicode wrote:
[…]
> Hence, from an ISO perspective, ISO 10646 is the only standard for which
> on-going
> synchronization with Unicode is needed or relevant.
This point of view is fueled by the Unicode Standard being traditionally
thought
On Thu, 7 Jun 2018 22:46:12 +0300, Erkki I. Kolehmainen via Unicode wrote:
>
> I cannot but fully agree with Mark and Michael.
>
> Sincerely
>
Thank you for confirming. All witnesses concur to invalidate the statement
about
uniqueness of ISO/IEC 10646 ‐ Unicode synchrony. — After being invent
On Fri, 8 Jun 2018 00:43:04 +0200, Philippe Verdy via Unicode wrote:
[cited mail]
>
> The "normative names" are in fact normative only as a forward reference
> to the ISO/IEC repertoire becaus it insists that these names are essential
> part
> of the stable encoding policy which was then integrate
time,
> or am not willing to upfront the low, low fee of $10K, I might "ignore" the
> email, or "not respond" to it.
> Or I might "decline" it with a no-thanks or not-interested response. But none
> of that is to "refuse" it.
Thanks, I got it (the
On Fri, 8 Jun 2018 08:50:28 -0400, Tom Gewecke via Unicode wrote:
>
>
> > On Jun 7, 2018, at 11:32 PM, Marcel Schneider via Unicode wrote:
> >
> > What bothered me ... is that the registration of the French locale in CLDR
> > is
> > still surprisingly
On Fri, 8 Jun 2018 13:33:20 -0700, Asmus Freytag via Unicode wrote:
>
[…]
> There's no value added in creating "mirrors" of something that is
> successfully being developed and maintained under a different umbrella.
Wouldn’t the same be true for ISO/IEC 10646? It has no value added neither, and
On Fri, 8 Jun 2018 16:54:20 -0400, Tom Gewecke via Unicode wrote:
>
> > On Jun 8, 2018, at 9:52 AM, Marcel Schneider via Unicode wrote:
> >
> > People relevant to projects for French locale do trace the borderline of
> > applicability wider
> > than do thos
On Fri, 8 Jun 2018 09:20:09 -0700, Steven R. Loomis via Unicode wrote:
[…]
> But, it sounds like the CLDR process was successful in this case. Thank you
>for contributing.
You are welcome, but thanks are due to the actual corporate contributors.
[…]
> Actually, I think the particular data item
On Sat, 9 Jun 2018 09:47:01 +0100, Richard Wordingham via Unicode wrote:
>
> On Sat, 9 Jun 2018 08:23:33 +0200 (CEST)
> Marcel Schneider via Unicode wrote:
>
> > > Where there is opportunity for productive sync and merging with is
> > > glibc. We have had some dis
018 7:49 PM
> To: Marcel Schneider
> Cc: UnicodeMailingList
> Subject: Re: The Unicode Standard and ISO
2018-06-09 17:22 GMT+02:00 Marcel Schneider via Unicode :
On Sat, 9 Jun 2018 09:47:01 +0100, Richard Wordingham via Unicode wrote:
> >
> > On Sat, 9 Jun 2018 0
On Sat, 9 Jun 2018 12:56:28 -0700, Asmus Freytag via Unicode wrote:
>
> On 6/9/2018 12:01 PM, Marcel Schneider via Unicode wrote:
> > Still a computer should be understandable off-line, so CLDR providing a
> > standard library of error messages could be
> > appreciated
On Sat, 9 Jun 2018 12:56:28 -0700, Asmus Freytag via Unicode wrote:
[…]
> It's pushing this kind of impractical scheme that gives standardizers a bad
> name.
>
> Especially if it is immediately tied to governmental procurement, forcing
> people to adopt it (or live with it)
> whether it provide
nk you for letting us know.
Best regards,
Marcel
> Regards,
> Steven
>
On Sat, Jun 9, 2018 at 3:41 PM Marcel Schneider via Unicode wrote:
>
> On Sat, 9 Jun 2018 12:56:28 -0700, Asmus Freytag via Unicode wrote:
> >
> > On 6/9/2018 12:01 PM, Marcel Schneider via Uni
On Sun, 10 Jun 2018 15:11:48 +, Peter Constable via Unicode wrote:
>
> > ... For another part it [sync with ISO/IEC 15897] failed because the
> > Consortium refused to cooperate, despite of
> > repeated proposals for a merger of both instances.
>
> First, ISO/IEC 15897 is built on a data-for
> > From the outset, Unicode and the US national body tried repeatedly to
> > engage with SC35 and SC35/WG5,
[…]
> As a reminder: The actual SC35 is in total disconnect from the same SC35 as
> it was from the mid-eighties to mid-nineties and beyond.
Edit: ISO/IEC JTC1 SC35 was founded in 1999. (
On Mon, 11 Jun 2018 16:32:45 +0100 (BST), William_J_G Overington via Unicode
wrote:
[…]
> Asmus Freytag wrote:
>
> > If you tried to standardize all error messages even in one language you
> > would never arrive at something that would be universally useful.
>
> Well that is a big "If". One can
William,
On 12/06/18 12:26, William_J_G Overington wrote:
>
> Hi Marcel
>
> > I don’t fully disagree with Asmus, as I suggested to make available
> > localizable (and effectively localized) libraries of message components,
> > rather than of entire messages.
>
> Could you possibly give some
On Tue, 12 Jun 2018 15:58:09 +0100, Michael Everson via Unicode wrote:
>
> Marcel,
>
> You have put words into my mouth. Please don’t. Your description of what I
> said is NOT accurate.
>
> > On 12 Jun 2018, at 03:53, Marcel Schneider via Unicode wrote:
> >
&
On Tue, 12 Jun 2018 19:49:10 +0200, Mark Davis ☕️ via Unicode wrote:
[…]
> People interested in this topic should
> (a) start up their own project somewhere else,
> (b) take discussion of it off this list,
> (c) never bring it up again on this list.
Thank you for letting us know. I apologize for
> Message du 13/06/18 22:25
> De : "via Unicode"
> A : charupd...@orange.fr
> Copie à :
> Objet : Your message to Unicode awaits moderator approval
>
> Your mail to 'Unicode' with the subject
>
> Re: The Unicode Standard and ISO
>
> Is being held until the list moderator can review it for appr
My last e-mail with subject “re: Your message to Unicode awaits moderator
approval”
was mistakenly sent to the Mailing List, for forgetting remove address in
cc-field (end hidden).
Please disregard.
My apologies.
Marcel
We do have this already, in combining marks extended:
@@ 1AB0 Combining Diacritical Marks Extended 1AFF
@ Used for German dialectology
[…]
1ABB COMBINING PARENTHESES ABOVE
* intended to surround a diacritic above
1ABC COMBINING DOUBLE PARENTHESES ABOVE
1ABD COMBINING PARENTHESES BELOW
* intended
Indeed when target use is general, dialectological diacritics are visibly not
an option, as
despite being in Unicode since v7.0 (2014), they are still unsupported by
mainstream.
Writing “der Arzt oder die Ärztin” or, depending on context, “einen Arzt oder
eine Ärztin”,
which I remember being c
On 29/08/18 07:55, Janusz S. Bień via Unicode wrote:
>
> On Tue, Aug 28 2018 at 9:43 -0700, unicode@unicode.org writes:
> > On August 23, 2011, Asmus Freytag wrote:
> >
> >> On 8/23/2011 7:22 AM, Doug Ewell wrote:
> >>> Of all applications, a word processor or DTP application would want
> >>> to k
Thank you for looking into this. First, I’m unable to retrieve the publication
you are citing,
but a February thread had nearly the same subject, referring to Vol. 50. How
did you
compute these figures? Is that a code phrase to say: “The same questions over
and
over again; let’s settle this o
he XML. Asking for changes to existing UCD file formats is kind of a
non-starter, given these two alternatives.
>
>
>
--
Doug Ewell | Thornton, CO, US | ewellic.org
>
Original message
Message: 3
Date: Thu, 30 Aug 2018 02:27:33 +0200 (CEST)
> From: Marcel S
On 31/08/18 07:27 Janusz S. Bień via Unicode wrote:
[…]
> > Given NamesList.txt / Code Charts comments are kept minimal by design,
> > one couldn’t simply pop them into XML or whatever, as the result would be
> > disappointing and call for completion in the aftermath. Yet another task
> > compet
On 31/08/18 19:59 Ken Whistler via Unicode wrote:
[…]
> Second, one of the main obligations of a standards organization is
> *stability*. People may well object to the ad hoc nature of the UCD data
> files that have been added over the years -- but it is a *stable*
> ad-hockery. The worst thing
s I do use XML for lookup in
the text editor, but I’m afraid that there is no advantage over CSV with
respect to file size.
Regards,
Marcel
>
> Regards,
>
> Marius Spix
>
>
> On Fri, 31 Aug 2018 06:58:37 +0200 (CEST) Marcel Schneider via Unicode
> wrote:
>
[…]
Thank you Marius for the example. Indeed I now see that YAML is a powerful means
for a file to have an intuitive readability while drastically reducing file
size.
BTW what I conjectured about the role of line breaks is true for CSV too, and
any file
downloaded from UCD on a semicolon separator b
On 31/08/18 10:47 Manuel Strehl via Unicode wrote:
>
> To handle the UCD XML file a streaming parser like Expat is necessary.
Thanks for the tip. However for my needs, Expat looks like overkill, and I’m
looking out for a much simpler standalone tool, just converting XML to CSV.
>
> For codepoi
I’m not responding without thinking, as I was blamed of when I did,
but it is painful for me to dig into what Ken explained about how
we should be consuming UCD data. I’ll now try to get some more clarity
into the topic.
> On 31/08/18 19:59 Ken Whistler via Unicode wrote:
> […]
> >
> > Third, pl
ntime I rediscovered Locale Explorer
>
> http://demo.icu-project.org/icu-bin/locexp
>
> which I used some time ago.
Nice. Actually based on CLDR v31.0.1.
>
> On Fri, Aug 31 2018 at 12:17 +0200, Marcel Schneider via Unicode wrote:
> > On 31/08/18 07:27 Janusz S. Bień
Sorry for not noticing that this thread belongs to CLDR-users, not to Unicode
Public.
Hence I’m taking it off this list, welcoming participants to follow up there:
https://unicode.org/pipermail/cldr-users/2018-September/000833.html
On 07/09/18 02:32 Shriramana Sharma via Unicode wrote:
>
> Hello. This may be slightly OT for this list but I'm asking it here as it
> concerns computer usage with multiple scripts and i18n:
It actually belongs on CLDR-users list. But coming from you, it shall remain
here while I’m posting a qu
On 06/09/18 19:09 Doug Ewell via Unicode wrote:
>
> Marcel Schneider wrote:
>
> > BTW what I conjectured about the role of line breaks is true for CSV
> > too, and any file downloaded from UCD on a semicolon separator basis
> > becomes unusable when displayed straight in the built-in text editor
On 07/09/18 22:07 Eli Zaretskii via Unicode wrote:
>
> > Date: Fri, 7 Sep 2018 12:47:44 -0700
> > Cc: d3c...@gmail.com, Doug Ewell ,
> > unicode
> > From: Rebecca Bettencourt via Unicode
> >
> > On Fri, Sep 7, 2018 at 11:20 AM Philippe Verdy via Unicode wrote:
> >
> > That version has been an
Hello,
I’ve followed up on CLDR-users:
https://unicode.org/pipermail/cldr-users/2018-September/000837.html
As a sidenote — It might be hard to get a selection of discussions
actually happen on CLDR-users instead of Unicode Public mail list,
as long as subscribers of this list don’t necessarily
On 15/09/18 15:36, Philippe Verdy wrote:
[…]
> So yes all control keys are potentially localisable to work best with the
> base layout anre remaining mnemonic;
> but the physical key position may be very different.
An additional level of complexity is induced by ergonomics. so that most
non-Lati
On 17/09/18 05:38 Martin J. Dürst wrote:
[quote]
>
> From my personal experience: A few years ago, installing a Dvorak
> keyboard (which is what I use every day for typing) didn't remap the
> control keys, so that Ctrl-C was still on the bottom row of the left
> hand, and so on. For me, it was
For people monitoring this list but not CLDR-users:
To be cost-effective, the migration from the wrong U+00A0 to the correct U+202F
as group separator
should be synched across all locales using space instead of comma or period. SI
is international and
specifies narrow fixed-width no-break spac
On 29/10/18 20:29, Doug Ewell via Unicode wrote:
[…]
> ObMagister: I agree that trying to reflect every decorative nuance of
> handwriting is not what plain text is all about.
Agreed.
> (I also disagree with
> those who insist that superscripted abbreviations are required for
> correct spelling i
Rather than a dozen individual e-mails, I’m sending this omnibus reply
for the record, because even if here and in CLDR (SurveyTool forum and
Trac) everything has already been discussed and fixed, there is still
a need to stay acknowledging, so as not to fail following up, with
respect to the o
On 30/10/18 17:01 I wrote:
> A Unicode-conformant way to represent
> such abbreviations would IMO use U+1D49 followed by U+0301: ,ᵉ́,.
Works actually fine in my browser.
My apologies to font designers and foundries, already supporting the
combining diacritics with superscript Latin letters. Onl
On 30/10/2018 at 18:59, Doug Ewell via Unicode wrote:
>
> Marcel Schneider wrote:
>
> > This use case is different from the use case that led to submit
> > the L2/18-206 proposal, cited by Dr Ewell on 29/10/2018 at 20:29:
>
> I guess this is intended as a compliment.
Right.
> While many of the
On 30/10/2018 at 21:34, Khaled Hosny via Unicode wrote:
>
> On Tue, Oct 30, 2018 at 04:52:47PM +0100, Marcel Schneider via Unicode wrote:
> > E.g. in Arabic script, superscript is considered worth
> > encoding and using without any caveat, whereas when Latin script is on,
&g
Thank you for your feedback.
On 30/10/2018 at 22:52, Khaled Hosny wrote:
> > First, ARABIC LETTER SUPERSCRIPT ALEPH U+0671.
> > But it is a vowel sign. Many letters put above are called superscript
> > when explaining in English.
>
> As you say, this is a vowel sign not a superscript letter,
On 31/10/2018 at 11:21, Asmus Freytag via Unicode wrote:
>
> On 10/31/2018 2:38 AM, Julian Bradfield via Unicode wrote:
>
> > You could use the various hacks
> > you've discussed, with modifier letters; but that is not "encoding",
> > that is "abusing Unicode to do markup". At least, that's the vie
On 31/10/2018 at 17:03, Khaled Hosny wrote:
>
> A while I was localizing some application to Arabic and the developer
> “helpfully” used m² for square meter, but that does not work for Arabic
> because there is no superscript ٢ in Unicode, so I had to contact the
> developer and ask for markup to b
On 31/10/2018 at 17:27, Julian Bradfield via Unicode wrote:
>
> On 2018-10-31, Marcel Schneider via Unicode wrote:
>
> > Preformatted Unicode superscript small letters are meeting the French
> > superscript
> > requirement, that is found in:
> > http://www.a
On 31/10/18 at 23:05, Asmus Freytag via Unicode wrote:
[…]
> > Sad that Arabic ² and ³ are still missing.
>
> How about all the other sets of native digits?
The missing ones are hopefully already on the roadmap.
Or do you refer to the missing ² and ³ in all other native digits?
Obviously they need
On 31/10/2018 19:42, Asmus Freytag via Unicode wrote:
>
> On 10/31/2018 11:10 AM, Marcel Schneider via Unicode wrote:
> >
> > > which, if my understanding of "convient" is correct, carefully does
> > > [not] quite say that it is *wrong* not to superscrip
On 01/11/2018 at 00:41, Martin J. Dürst wrote:
>
> On 2018/11/01 03:10, Marcel Schneider via Unicode wrote:
> > On 31/10/2018 at 17:27, Julian Bradfield via Unicode wrote:
>
> >> When one does question the Académie about the fact, this is their
> >> reply:
> &
On 01/11/2018 01:21, Asmus Freytag via Unicode wrote:
On 10/31/2018 3:37 PM, Marcel Schneider via Unicode wrote:
On 31/10/2018 19:42, Asmus Freytag via Unicode wrote:
[…]
It is a fallacy that all text output on a computer should match the convention
of "fine typography".
Much that
On 01/11/2018 22:56, Richard Wordingham via Unicode wrote:
On Thu, 01 Nov 2018 18:23:05 +0100
"Janusz S. Bień via Unicode" wrote:
On Thu, Nov 01 2018 at 8:43 -0700, Asmus Freytag via Unicode wrote:
I don't think it's a joke to recognize that there is a continuum
As a sidenote: I remember
On 01/11/2018 16:43, Asmus Freytag via Unicode wrote:
[quoted mail]
I don't think it's a joke to recognize that there is a continuum here and that
there is no line that can be drawn which is based on straightforward
principles.
[…]
In this case, there is no such framework that could help esta
On 31/10/2018 at 19:34, Asmus Freytag via Unicode wrote:
On 10/31/2018 10:32 AM, Janusz S. Bień via Unicode wrote:
>
> Let me remind what plain text is according to the Unicode glossary:
>
> Computer-encoded text that consists only of a sequence of code
> points from a given standard,
On 02/11/2018 17:20, Janusz S. Bień via Unicode wrote:
On Fri, Nov 02 2018 at 5:09 -0700, Asmus Freytag via Unicode wrote:
[...]
To transcribe the postcard would mean selecting the characters
appropriate for the printed equivalent of the text.
You seem to make implicit assumptions which are
On 02/11/2018 17:45, Philippe Verdy via Unicode wrote:
[quoted mail]
Using variation selectors is only appropriate for these existing
(preencoded) superscript letters ª and º so that they display the
appropriate (underlined or not underlined) glyph.
And it is for forcing the display of DIGIT
1 - 100 of 137 matches
Mail list logo
