Re: NNBSP

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

Re: NNBSP

On 19/01/2019 01:21, Shawn Steele wrote: *>> *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.

Re: NNBSP

On 19/01/2019 01:55, Asmus Freytag via Unicode wrote: On 1/18/2019 2:05 PM, Marcel Schneider via Unicode wrote: On 18/01/2019 20:09, Asmus Freytag via Unicode wrote: Marcel, about your many detailed *technical* questions about the history of character properties, I am afraid I have

Re: NNBSP

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 applications

Re: NNBSP

On 18/01/2019 22:03, Shawn Steele via Unicode wrote: I've been lurking on this thread a little. This discussion has gone “all over the place”, however I’d like to point out that part of the reason NBSP has been used for thousands separators is because that it exists in all of those legacy

Re: NNBSP

On 18/01/2019 19:20, Asmus Freytag via Unicode wrote: 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 coverage was understood as a necessary

Re: NNBSP

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 industry

Re: NNBSP

this discussion helps sort things out so that we’ll know both what to do wrt Mongolian and what to do wrt French. On Jan 17, 2019, at 11:06, Asmus Freytag via Unicode mailto:unicode@unicode.org>> wrote: On 1/17/2019 9:35 AM, Marcel Schneider via Unicode wrote:  [On 17/01/2019 12:21, Ph

Re: NNBSP (was: A last missing link for interoperable representation)

On 17/01/2019 12:21, Philippe Verdy via Unicode wrote: [quoted mail] But the French "espace fine insécable" was requested long long before Mongolian was discussed for encodinc in the UCS. The problem is that the initial rush for French was made in a period where Unicode and ISO were

Re: NNBSP (was: A last missing link for interoperable representation)

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

Re: NNBSP (was: A last missing link for interoperable representation)

On 17/01/2019 12:21, Philippe Verdy via Unicode wrote: [quoted mail] But the French "espace fine insécable" was requested long long before Mongolian was discussed for encodinc in the UCS. Then we should be able to read its encoding proposal in the UTC document registry, but Google Search

Re: NNBSP

On 17/01/2019 09:58, Richard Wordingham wrote: On Thu, 17 Jan 2019 04:51:57 +0100 Marcel Schneider via Unicode wrote: Also, at least one French typographer was extremely upset about Unicode not gathering feedback from typographers. That blame is partly wrong since at least one typographer

Re: NNBSP (was: A last missing link for interoperable representation)

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

Re: Encoding italic (was: A last missing link)

On 17/01/2019 07:36, David Starner via Unicode wrote: […] On the other hand, most people won't enter anything into a tweet they can't enter from their keyboard, and if they had to, would resort to cut and paste. The only people Unicode italics could help without change are people who already

Re: NNBSP (was: A last missing link for interoperable representation)

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

Re: wws dot org

On 15/01/2019 19:22, Johannes Bergerhausen via Unicode wrote: Dear list, I am happy to report that www.worldswritingsystems.org  is now online. The web site is a joint venture by — Institut Designlabor Gutenberg (IDG), Mainz, Germany, — Atelier National

Re: Encoding italic

On 16/01/2019 06:05, David Starner via Unicode wrote: […] […] There's no one here regards plain text with derision, disdain or contempt. There is one sort of so-called plain text that looks unbearable to me. That is the draft-style plain text full of ASCII fallbacks. Especially those where

Re: Encoding italic

On 16/01/2019 02:15, James Kass via Unicode wrote: Enabling plain-text doesn't make rich-text poor. People who regard plain-text with derision, disdain, or contempt have every right to hold and share opinions about what plain-text is *for* and in which direction it should be heading. Such

Re: A last missing link for interoperable representation

On 15/01/2019 10:24, Philippe Verdy via Unicode wrote: Le lun. 14 janv. 2019 à 20:25, Marcel Schneider via Unicode mailto:unicode@unicode.org>> a écrit : On 14/01/2019 06:08, James Kass via Unicode wrote: > > Marcel Schneider wrote, > >> There is

Re: A last missing link for interoperable representation

On 15/01/2019 03:02, Asmus Freytag via Unicode wrote: On 1/14/2019 5:41 PM, Mark E. Shoulson via Unicode wrote: On 1/14/19 5:08 AM, Tex via Unicode wrote: This thread has gone on for a bit and I question if there is any more light that can be shed. BTW, I admit to liking Asmus definition

Re: A last missing link for interoperable representation

On 15/01/2019 01:17, Asmus Freytag via Unicode wrote: On 1/14/2019 2:08 PM, Tex via Unicode wrote: Asmus, I agree 100%. Asking where is the harm was an actual question intended to surface problems. It wasn’t rhetoric for saying there is no harm. The harm comes when this is imported into

Re: A last missing link for interoperable representation

On 14/01/2019 08:26, Julian Bradfield via Unicode wrote: On 2019-01-13, Marcel Schneider via Unicode wrote: […] These statements make me fear that the font you are using might unsupport the NARROW NO-BREAK SPACE U+202F > <. If you see a question mark between It displays as a space.

Re: A last missing link for interoperable representation

On 14/01/2019 04:00, Martin J. Dürst via Unicode wrote: […] […] As Asmus has shown, one of the best ways to understand what Unicode does with respect to text variants is that style works on spans of characters (words,...), and is rich text, but thinks that work on single characters are handled

Re: A last missing link for interoperable representation

On 13/01/2019 17:52, Julian Bradfield via Unicode wrote: On 2019-01-12, James Kass via Unicode wrote: This is a math formula: a + b = b + a ... where the estimable "mathematician" used Latin letters from ASCII as though they were math alphanumerics variables. Yup, and it's immediately

Re: A last missing link for interoperable representation

On 12/01/2019 00:17, James Kass via Unicode wrote: […] The fact that the math alphanumerics are incomplete may have been part of what prompted Marcel Schneider to start this thread. No, really not at all. I didn’t even dream of having italics in Unicode working out of the box. That would

Re: A last missing link for interoperable representation

On 08/01/2019 06:32, Asmus Freytag via Unicode wrote: On 1/7/2019 7:46 PM, James Kass via Unicode wrote: Making recommendations for the post processing of strings containing the combining low line strikes me as being outside the scope of Unicode, though. Agreed. Those kinds of things are

A last missing link for interoperable representation

Previous discussions have already brought up how Unicode is supporting those languages that despite being old in Unicode still require special attention for their peculiar way of spacing punctuation or indicating abbreviations. Now I wonder whether s̲t̲r̲e̲s̲s̲ can likewise be noted in plain text

Preformatted superscript in ordinary text, paleography and phonetics using Latin script (was: Re: A sign/abbreviation for "magister" - third question summary)

On 06/11/2018 12:04, Janusz S. Bień via Unicode wrote: On Sat, Oct 27 2018 at 14:10 +0200, Janusz S. Bień via Unicode wrote: Hi! On the over 100 years old postcard https://photos.app.goo.gl/GbwNwYbEQMjZaFgE6 you can see 2 occurences of a symbol which is explicitely explained (in Polish) as

Re: Encoding (was: Re: A sign/abbreviation for "magister")

On 05/11/2018 17:46, Doug Ewell via Unicode wrote: Philippe Verdy wrote: Note that I actually propose not just one rendering for the but two possible variants (that would be equally valid withou preference). Actually you're not proposing them. You're talking about them (at length) on

Re: Encoding

On 04/11/2018 20:19, Philippe Verdy via Unicode wrote: […] Even the mere fallback to render the as a dotted circle (total absence of support) will not block completely reading the abbreviation: * you'll see "2e◌" (which is still better than only "2e", with minimal impact) instead of * "2◌"

Re: Encoding (was: Re: A sign/abbreviation for "magister")

Sorry, I didn’t truncate the subject line, it was my mail client. On 04/11/2018 17:45, Philippe Verdy wrote: Note that I actually propose not just one rendering for the but two possible variants (that would be equally valid withou preference). Use it after any base cluster (including with

Re: Encoding

On 04/11/2018 17:45, Philippe Verdy wrote: Note that I actually propose not just one rendering for the but two possible variants (that would be equally valid withou preference). Use it after any base cluster (including with diacritics if needed, like combining underlines). - the first one can

Encoding (was: Re: A sign/abbreviation for "magister")

On 03/11/2018 23:50, James Kass via Unicode wrote: When the topic being discussed no longer matches the thread title, somebody should start a new thread with an appropriate thread title. Yes, that is what also the OP called for, but my last reply though taking me some time to write was sent

Re: A sign/abbreviation for "magister"

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

Re: A sign/abbreviation for "magister"

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,

Re: A sign/abbreviation for "magister"

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

Re: A sign/abbreviation for "magister"

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

Re: A sign/abbreviation for "magister"

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: > &

Re: A sign/abbreviation for "magister"

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

Re: A sign/abbreviation for "magister"

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

Re: A sign/abbreviation for "magister"

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

Re: A sign/abbreviation for "magister"

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

Re: A sign/abbreviation for "magister" (was: Re: second attempt)

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

Re: A sign/abbreviation for "magister"

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,

Re: A sign/abbreviation for "magister"

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,

Re: A sign/abbreviation for "magister"

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

Re: A sign/abbreviation for "magister"

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

Group separator migration from U+00A0 to U+202F

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

Re: Shortcuts question

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

Re: Shortcuts question

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

Re: Shortcuts question (is: Thread transfer info)

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

EOL conventions (was: Re: UCD in XML or in CSV? (is: UCD in YAML))

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

Re: UCD in XML or in CSV? (is: UCD in YAML)

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

Re: Shortcuts question

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

Re: CLDR [terminating]

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

Re: CLDR

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ń

Re: UCD in XML or in CSV? (is: UCD data consumption)

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,

Re: UCD in XML or in CSV? (is: Parsing UCD in XML)

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

Re: UCD in XML or in CSV? (is: UCD in YAML)

CB: CN > WB: XX > SB: XX > CE: N > Comp_Ex: N > NFC_QC: Y > NFD_QC: Y > NFKC_QC: Y > NFKD_QC: Y > XO_NFC: N > XO_NFD: N > XO_NFKC: N > XO_NFKD: N > FC_NFKC: "#" > CI: N > Cased: N > CWCF: N > CWCM: N > CWKCF: N > CWL: N > CWT: N > CWU: N > NFKC_CF: "#" > InSC: Other > InPC: NA > PCM: N > blk: ASCII > isc: "" > > - > cp: 0001 > na1: "START OF HEADING" > name_alias: > - [SOH,abbreviation] > - [START OF HEADING,control] > props: * > > > > > > Regards, > > Marius Spix > > > On Sat, 1 Sep 2018 08:00:02 +0200 (CEST) > schrieb Marcel Schneider wrote: > […]

Re: UCD in XML or in CSV? (was: Re: Unicode Digest, Vol 56, Issue 20)

ML as 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: > […]

Re: UCD in XML or in CSV?

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

Re: CLDR (was: Private Use areas)

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 > >

UCD in XML or in CSV? (was: Re: Unicode Digest, Vol 56, Issue 20)

process that can parse XML can handle unknown stuff like this without misinterpreting the stuff it does know. > That's why the only two reasonable options for getting UCD data are to read all the tab- and semicolon-delimited files, and be ready for new files, or just read the XML. Asking

Re: Unicode Digest, Vol 56, Issue 20

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

Re: Private Use areas

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

Re: Diacritic marks in parentheses

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

Re: Diacritic marks in parentheses

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

Please disregard my mistaken e-mail

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

re: Your message to Unicode awaits moderator approval

> 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

Re: The Unicode Standard and ISO

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

Re: The Unicode Standard and ISO

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: > > &

Re: The Unicode Standard and ISO

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

Re: The Unicode Standard and ISO

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

RE: The Unicode Standard and ISO

> > 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.

RE: The Unicode Standard and ISO

ay be pleased to know that I try to keep helping do our best. Thank you everyone. Best regards, Marcel > > > Peter > > > From: Unicode On Behalf Of Mark Davis ?? via Unicode > Sent: Thursday, June 7, 2018 6:20 AM > To: Marcel Schneider > Cc: UnicodeMailing &

Re: The Unicode Standard and ISO

s 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 Unicode wrote: > &

Re: The Unicode Standard and ISO

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

Re: The Unicode Standard and ISO

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 > > app

RE: The Unicode Standard and ISO

void them. > Using computer translation on programming error messages is no way near to > being useful. >  > Best Regards, >  > Jonathan Rosenne >  > From: Unicode [mailto:unicode-boun...@unicode.org] On Behalf Of Philippe > Verdy via Unicode > Sent: Saturday, June 09, 2

Re: The Unicode Standard and ISO

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 so

Re: The Unicode Standard and ISO

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

Re: The Unicode Standard and ISO

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 t

Re: The Unicode Standard and ISO

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

Re: The Unicode Standard and ISO

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 surprising

Re: The Unicode Standard and ISO

nt 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 point, and the e‐mail). More ser

Re: The Unicode Standard and ISO

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

RE: The Unicode Standard and ISO

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

Re: The Unicode Standard and ISO

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

Re: The Unicode Standard and ISO

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,

Re: The Unicode Standard and ISO

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

Unicode 11.0.0: BidiMirroring.txt

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

Re: More scripts, not more emoji (Re: Accessibility Emoji)

On Sat, 14 Apr 2018 20:29:40 -0700, Markus Scherer <markus@gmail.com> 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

More scripts, not more emoji (Re: Accessibility Emoji)

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

Re: Accessibility Emoji

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

Re: Translating the standard

, 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

RE: Translating the standard

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

Re: Translating the standard

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 check yo

Re: Translating the standard

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

Re: Translating the standard

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

Re: Translating the standard

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

  1   2   3   4   5   >