From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Sun Jul 15 2007 - 02:59:30 CDT
Christopher Fynn wrote:
> Right now if I have a lookup in an OpenType font to place an isolated mark
> on the dotted circle Uniscribe also inserts dotted circle and I end up
> getting two doted circles the second with the combining mark attached
> - rather than one dotted circle with combining mark.
So why not instead fixing the OpenType engine so that it will NOT select,
position and render the dotted circle glyph, if:
* the font contains a glyph mapped for the dotted circle
* the font already includes a GPOS entry for positioning the diacritic on
top of this glyph
This way, the font contains an explicit positioning and glyph selection for
the dotted circle. All the OpenType engine has to do is to use it by
inserting the dotted circle code point in the string to render, and the font
will map it and draw it according to its glyphs. The OpenType engine will
not draw the circle on top of it.
For inserting other base characters, the application could indicate a
rendering preference (hint?) for the appropriate character to insert; the
OpenType engine will work with it as with the current default dotted circle,
and will optionally perform an additional lookup if theisbase character has
no mapping in the font (avoiding the rendering of the "missing glyph").
But the application will rarely specify such hint,notably if the language is
not known to it, so instead, the document will provide an explicit character
within the text encoded. The problem is that the document authors don't know
really if that explicit base character will exist in the font used by the
renderer, so it could cause a "missing glyph" to be displayed (and not even
positioned correctly according to the combining character, even when this
c.c; does exist and is rendered with an appropriate glyph).
What document authors want is:
* to know which base character they can use safely in their encoded
documents
* to know that font designers will support the combination because it is
considered part of the normal support of the script.
This just means documentation (or at least a good public interation between
well known font designers about what they have done). Such thing could be
documented as part of Unicode's script description chapters, or in some data
of the UCD, or even within the public documentation of OpenType specs (out
of Unicode itself, because this does not change anything in the existing
Unicode standard).
Having it documented somewhere will incite the best foundries to include
this support in the fonts they produce and support, including at least
MonoType, Microsoft and Apple (the other foundries will adopt it only by
seeing that the feature is support by them, or by looking at the public
document, but the public document is there so that the most important
foundries will not forget it). The designers of open-source fonts will just
update their existing font without problem, if they just see that the
feature is used in many documents that were initially created assuming one
font of these foundries.
This archive was generated by hypermail 2.1.5 : Sun Jul 15 2007 - 03:05:00 CDT