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 been extended to cover cursive Latin for contextual shaping, but it
is not non-sense (IMHO) to think about such extension (using the same
"isol", "init", "medi", "fina" features required by Arabic, but optional in
Latin ?)

As well Fraktur Latin or medieval Latin styles are also challenging, and
not correctly covered by the Basic ("standard") profile (
https://docs.microsoft.com/fr-fr/typography/script-development/standard).

Look at the issues listed in the "Other encoding issues" sections of the
specs. As OpenType is a project comanaged by Microsoft and Adobe, with
additional consultations made with Apple, Unicode, Linux developers, I
think it should be brought to a more separate subcomity, and its
documentation moved to its own website/repository, outside Microsoft
website itself, even if Microsoft can still control its publication and
modifications (under agreeements with other OpenType participants in its
adhoc subcomity). Given that these companies are also full Unicode members
(and Linux developers are also represented by companies creating and
supporting Linux distributions, including or Google, Oracle), this OpenType
initiative should become officially a subcomity in the Unicode consortium
(just like when IBM transfered its CLDR project to Unicode as a subcomity)

But this does not mean that the Unicode needs to host and manage the
documentation itself and some reference implementation (GitHub looks great
for that), or links to existing implementations of OpenType core algorithms
on popular development platforms (shaping, vectorization, hinting,
rasterization, variable font shapes, colororimetry for colored emojis,
device capability profiles, programmatic transforms of shapes for generated
styles or animated shapes, or for 3D/OpenGL/DirectX with the addition of
rotations and non-linear projections like perspective...), and of some
conformance test tools.

In my opinon the "shaper" part of OpenType rendering is the most important
part where the Unicode Consortium and TUS must be synchronized (and
stabilized: we see that lack of stability is a severe security problem,
this Apple Bug is a big precedent showing that this specification must be
studied more seriously by an open comity).

2018-02-18 20:47 GMT+01:00 Philippe Verdy <verdy_p_at_wanadoo.fr>:

>
>
> 2018-02-18 20:38 GMT+01:00 Richard Wordingham via Unicode <
> unicode_at_unicode.org>:
>
>> On Sun, 18 Feb 2018 14:13:22 +0100
>> Philippe Verdy via Unicode <unicode_at_unicode.org> 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 its
>> > own USE engine (for now it does not) because it would also require a
>> > glyphs buffer to allow correct reordering of glyphs (according to
>> > their properties, notably for "beforebase", or for special placement
>> > of some diacritics such as the cedilla that moves from "belowbase" to
>> > "abovebase" when the base is the letter "g").
>>
>> The examples accompanying the OpenType specification assume a font may
>> insert spacing glyphs for punctuation in French, so there's no need to
>> consider anything complicated.
>>
>
> I've not told at all about the possible additional spacing of punctuation
> in French, it is simple to handle and does not involve the shaper, it's
> just a matter of alternate glyph selection per language defined in the font
> which can have different mappings, with different metrics or different
> GPOS, even if they share the same vector definition, with a simple affine
> transform.
>
Received on Sun Feb 18 2018 - 14:22:53 CST