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 <verd...@wanadoo.fr>: > > > 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 <unicode@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. >