Werner LEMBERG: >> The GSUB/GPOS tables describe (amongst others) contructs called >> "lookup tables". [...] > > GSUB and GPOS are a nice example of overengineering, originally > targeting a very narrow set of capabilites. Meanwhile, almost 20 > years later, we know better how to handle such issues, using a *much* > larger number of scripts that have to be supported, but we are stuck > with those tables and its support (which is often buggy and > incomplete) in various applications.
I haven't heard about such complaints, yet. Especially when taking into account these mechanisms aren't really meant to do font-independent text processing that might be associated with scripts. > Recently, MS introduced `USE', the Universal Shaping Engine, which > is a *huge* improvement compared to the previously used stuff. > https://www.microsoft.com/typography/OpenTypeDev/USE/intro.htm > However, for backwards compatibility reasons, the old script-specific > shaping engines must still be supported. > Honestly, I'm very glad that I don't have to handle this mess Me too. >> Since this topic has now been open for so many years, giving a more >> complete specifiation would mean to introduce new requirements on >> existing implementations, of course something that the spec-editors >> intend to avoid. > I think this should become better with the next revision of OpenType. > Peter Constable does a good job in improving the text IMHO, adding > clarifications reported to him. So *please* contact him if you still > find problems in the specification! But it's always difficult to decide wether things are intentionally left open... it all looks a bit like it's just them that had this giant idea of rendering text. >> Very many fonts that have GSUB/GPOS built in are able to define >> positions for unicode combining marks on a base glyph. These unicode >> combining marks have some attachment type (iike "above/below base >> glyph"). The font defined processing often even allows to correctly >> position mutliple marks. But this typically works if and only if >> the incoming text string lists the combining marks sorted by >> attachment type. > Oh yes, proper support for combining marks is a special nightmare... Ok, but the point was, that latin fonts seem to avoid to make full use of all the gsub/gpos functionality. It shouldn't be too commplicated to define gsub/gpos tables in a compact way, that solves this little sorting issue. Gruss Jan Bruns _______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
