Re: Why so much emoji nonsense?

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

Re: metric for block coverage

For Latin, usually looking for the coverage of Vietnamese works quite well... except for African languages that need additional uncommon Latin letters (open o, open e, alpha, some turned/mirrored/stroked letters), in which case you should look also for IPA coverage (but you may missing their

Re: metric for block coverage

The most useful feature for me (Debian user, linguist) would be a search system where I can provide a string, and filter fonts to those who include glyphs for all characters; ideally if I could also combine it with other search criteria, like OTF features (true small caps, etc.). I often write

Re: metric for block coverage

On Sun, Feb 18, 2018 at 3:42 AM Adam Borowski wrote: > I probably used a bad example: scripts like Cyrillic (not even Supplement) > include both essential letters and those which are historic only or used by > old folks in a language spoken by 1000, who use Russian (or

Re: Unicode of Death 2.0

To be clear, the Opentype application II profile at least (initially defined for Arabic) may also be needed in Latin for correctly rendering cursive Latin styles. For now this Application profile II ( https://docs.microsoft.com/fr-fr/typography/script-development/use#featureapplicationii) has not

Re: Why so much emoji nonsense?

On Sat, 17 Feb 2018 22:31:12 -0800 James Kass via Unicode wrote: > It's true that added features can make for a better presentation. > Removing the special features shouldn't alter the message. I think I've encountered the use of italics in novels for sotto voce or asides.

Re: Unicode of Death 2.0

2018-02-18 20:38 GMT+01:00 Richard Wordingham via Unicode < unicode@unicode.org>: > On Sun, 18 Feb 2018 14:13:22 +0100 > Philippe Verdy via Unicode wrote: > > > But any operation in OpenType that requires reordering requires a > > glyphs buffer. This could even apply to

Re: Unicode of Death 2.0

On Sun, 18 Feb 2018 14:13:22 +0100 Philippe Verdy via Unicode wrote: > But any operation in OpenType that requires reordering requires a > glyphs buffer. This could even apply to Latin if Microsoft really > intends to support normalization (i.e. canonical equivalences) in

Re: metric for block coverage

On Sun, 18 Feb 2018 13:05:29 +0100 Adam Borowski via Unicode wrote: > On Sun, Feb 18, 2018 at 02:14:46AM -0800, James Kass wrote: > > You probably already know that basic script coverage information is > > stored internally in OpenType fonts in the OS/2 table. > > > >

Re: Unicode Digest, Vol 50, Issue 13

On Sun, Feb 18 2018 at 18:03 CET, kilob...@angband.pl writes: > On Sun, Feb 18, 2018 at 02:35:00PM +0100, Janusz S. Bień via Unicode wrote: >> On Sun, Feb 18 2018 at 14:06 CET, unicode@unicode.org writes: >> > Subject: metric for block coverage >> > >> > Hi! >> > As a part of Debian fonts team

Re: Unicode Digest, Vol 50, Issue 13

On Sun, Feb 18, 2018 at 02:35:00PM +0100, Janusz S. Bień via Unicode wrote: > On Sun, Feb 18 2018 at 14:06 CET, unicode@unicode.org writes: > > Subject: metric for block coverage > > > > Hi! > > As a part of Debian fonts team work, we're trying to improve fonts review: > > ways to organize them,

Re: metric for block coverage

On Sun, Feb 18 2018 at 17:33 CET, e...@gnu.org writes: >> Cc: unicode-requ...@unicode.org >> Date: Sun, 18 Feb 2018 14:35:00 +0100 >> From: "Janusz S. Bień via Unicode" >> >> As a Debian user using some rare characters for old Polish >> transliteration I would be happy with

Re: metric for block coverage

> Cc: unicode-requ...@unicode.org > Date: Sun, 18 Feb 2018 14:35:00 +0100 > From: "Janusz S. Bień via Unicode" > > As a Debian user using some rare characters for old Polish > transliteration I would be happy with a tool which scans > available/installed fonts for a specific

Re: metric for block coverage

> +1 if the font has all the glyphs in the range should be > +1 if the font has all the glyphs needed for the range

Re: Unicode Digest, Vol 50, Issue 13

On Sun, Feb 18 2018 at 14:06 CET, unicode@unicode.org writes: [...] > From: Adam Borowski via Unicode > Subject: metric for block coverage > To: unicode@unicode.org > Date: Sat, 17 Feb 2018 23:18:25 +0100 > Reply-To: Adam Borowski > Date: Sat, 17 Feb

Re: metric for block coverage

Adam Borowski wrote, > It's only a single bit without a meaning beyond "range is considered > functional". No "basic coverage" vs "good coverage" vs "full coverage". > ... > These codepoints can then be grouped by block -- but interpreting such lists > is what's unobvious. Compare the number of

Re: Unicode of Death 2.0

20But any operation in OpenType that requires reordering requires a glyphs buffer. This could even apply to Latin if Microsoft really intends to support normalization (i.e. canonical equivalences) in its own USE engine (for now it does not) because it would also require a glyphs buffer to allow

Re: Unicode of Death 2.0

Now what I suspect in Apple's implementation is the following: the OpenType specification details the steps to parse strings, find clusters boundaries, identify the various character types (joining, associativity, decomposable characters...) At first Apple parses the clusters and marks those

Re: metric for block coverage

Adam Borowski wrote, > What I'm thinking, is that a beautiful font that covers Russian, Ukrainian, > Serbian, Kazakh, Mongolian cyr, etc., should be recommended to users before > one whose only grace is including every single codepoint.

Re: metric for block coverage

On Sun, Feb 18, 2018 at 02:14:46AM -0800, James Kass wrote: > Adam Borowski wrote, > > I'm looking for a way to determine a font's coverage of available scripts. > > It's probably reasonable to do this per Unicode block. Also, it's a safe > > assumption that a font which doesn't know a codepoint

Re: Unicode of Death 2.0

Yes, I found other possible crashes all caused by the glyph reordering. It seems really that Apple implemented some unsafe shortcuts by not creating a glyphs buffer in all cases (using lasy instanciation only when needed), but forgot some cases and the code assumes that the glyphs buffer has been

Re: metric for block coverage

On Sun, Feb 18, 2018 at 12:36:22AM +, David Starner wrote: > On Sat, Feb 17, 2018 at 3:30 PM Adam Borowski via Unicode < > unicode@unicode.org> wrote: > > þ or ą count the same as LATIN TURNED CAPITAL > LETTER SAMPI WITH HORNS AND TAIL WITH SMALL LETTER X WITH CARON. > > þ is in Latin-1, and

Re: metric for block coverage

On Sun, Feb 18, 2018 at 02:14:46AM -0800, James Kass via Unicode wrote: > Adam Borowski wrote, > > > I'm looking for a way to determine a font's coverage of available scripts. > > It's probably reasonable to do this per Unicode block. Also, it's a safe > > assumption that a font which doesn't

Re: metric for block coverage

> OpenType fonts also include script coverage information in the > OpenType tables. A font with an OpenType table for a script would be > likely to have at least some complex script shaping abilities for that > script. https://docs.microsoft.com/en-us/typography/opentype/spec/chapter2#slTbl_sRec

Re: metric for block coverage

Adam Borowski wrote, > I'm looking for a way to determine a font's coverage of available scripts. > It's probably reasonable to do this per Unicode block. Also, it's a safe > assumption that a font which doesn't know a codepoint can do no complex > shaping of such a glyph, thus looking at just

Re: Unicode of Death 2.0

Doug Ewell 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 million people works. Linking Manish's

Re: Unicode of Death 2.0

Oh, also vatu. Seems like that ordering algorithm is indeed relevant. -Manish On Sat, Feb 17, 2018 at 11:57 PM, Manish Goregaokar wrote: > Ah, looking at that the OpenType `pstf` feature seems relevant, though I > cannot get it to crash with Gurmukhi (where the consonant

Re: Unicode of Death 2.0

Ah, looking at that the OpenType `pstf` feature seems relevant, though I cannot get it to crash with Gurmukhi (where the consonant ya is a postform) -Manish On Sat, Feb 17, 2018 at 4:40 PM, Philippe Verdy wrote: > An interesting read: > >