Re: Translating the standard (was: Re: Fonts and font sizes used in the Unicode)

On Thu, 8 Mar 2018 02:27:06 +0100 (CET) Marcel Schneider 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

Re: Translating the standard (was: Re: Fonts and font sizes used in the Unicode)

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 >

Sentence_Break, Semi-colons, and Apparent Miscategorization

Given that the comma and colon are categorized as SContinue, why is the semicolon also not SContinue? Also, why is the Greek Question Mark not categorized with the rest of the question marks? Why aren't the vertical presentation forms categorized with the things they are presenting? Thanks~

Re: metric for block coverage

Hi !    I’ll just add two points to the various points raised in the previous conversation about block coverage : Le 17/02/2018 à 23:18, Adam Borowski via Unicode a écrit : Hi! As a part of Debian fonts team work, we're trying to improve fonts review: ways to organize them, add metadata,

Re: Translating the standard (was: Re: Fonts and font sizes used in the Unicode)

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

Re: Sentence_Break, Semi-colons, and Apparent Miscategorization

>From the first line, I guess you mean that all three questions are having to do with the Sentence_Break property values. Namely: http://www.unicode.org/reports/tr29/proposed.html#Table_Sentence_Break_Property_Values http://www.unicode.org/reports/tr29/proposed.html#SContinue Mark On Thu, Mar

Re: Translating the standard (was: Re: Fonts and font sizes used in the Unicode)

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

Re: metric for block coverage

2018-03-08 15:18 GMT+01:00 Frédéric Grosshans via Unicode < unicode@unicode.org>: > Le 17/02/2018 à 23:18, Adam Borowski via Unicode a écrit : > >> Of course, this measure is only rough. A counter example is in the >> monetary symbol block, where € U+20AC EURO SIGN (in Unicode since 2.1) is >>

Re: Unicode Emoji 11.0 characters now ready for adoption!

On Thu, 08 Mar 2018 09:42:38 +0800 via Unicode wrote: > to the best of my knowledge virtually no new characters used just for > names are under consideration, all the ones that are under > consideration are from before this century. What I was interested in was the rate of

Re: Unicode Emoji 11.0 characters now ready for adoption!

This still leaves the question about how to write personal names ! IDS alone cannot represent them without enabling some "reasonable" ligaturing (they don't have to match the exact strokes variants for optimal placement, or with all possible simplifications). I'm curious to know how China, Taiwan,

Re: Unicode Emoji 11.0 characters now ready for adoption!

As well how Chinese/Japanese post offices handle addresses written with sinograms for personal names ? Is the expanded IDS form acceptable for them, or do they require using Romanized addresses, or phonetic approximations (Bopomofo in China, Kanas in Japan, Hangul in Korea) ? 2018-03-09 2:17

Re: Translating the standard (was: Re: Fonts and font sizes used in the Unicode)

For a number of reasons I think translating the standard is a really bad idea. As long as there are people interested in maintaining the translation, identifying deltas and easily translating just the deltas would NOT be difficult, however. Modern computer aided translation tools all use