On Wed, 22 Jan 1997 mike wrote:
> With a single byte font, one must use floating (non-spacing) characters for
> dependent vowels, diacritics and so on because there is only room for about
> 220 characters in the font. Using floating characters can compromise the
> typographical quality because the floating characters must be measured to
> position well for all possible character combinations. This usually means
> including several copies of the same floating character, each positioned a
> little differently. This can especially be a problem if one is trying to
> support several typefaces with the same logic because different typefaces
> can have different positioning requirements for the floating characters. At
> least that is the case for Hebrew, and I expect for most any script.
There is a way out of this, somewhat, but I am not sure whether it
works with all font technologies (any information about this is
very wellcome!). The idea is to have glyphs in the font that are
responsible for spacing only. To take a simlpe example, immagine
rendering a A-Umlaut from its components, with the two dots glyph
designed so that it matches lower case. To position it on an
upper case letter, the following sequence of glyphs would be rendered:
<A><spacing up><two dots><spacing down>
For the rendering system, this requires that glyphs can have vertical
offsets in addition to horizontal ones. Alternatively, such glyphs
are simulated by moving the writing position externally.
The whole thing may be a little more complicated, for example one
may have to consider horizontal displacement also. The important
point is that spacing and the glyphs themselves, or different
aspects of spacing, can be orthogonally separated, and that this
allows a rather high quality of rendering with a small font.
> However, with dual byte fonts one can include a much larger number of
> glyphs, so one could pre-compose a larger number of Tibetan stacks which
> include the dependent vowels and other diacritics, and reduce, maybe
> eliminate the use of floating characters. I believe the end result of this
> would be a higher quality of typography.
>
> I've probably been about as clear as mud on this, yes?
Quite to the contrary. It's a very well-known aspect of font technology
especially in an international setting.
> Microsoft I believe is working on their True Type Open technology which
> among other things addresses the issue of positioning diacritics on base
> characters. The font will know how to render itself regarding this, and
> will not rely upon logic from outside the font. I think this type of
> approach will greatly improve things.
Saying "the font will know how to render itself" is overly optimistic.
It is more correct to say "the font contains data (tables) that allows
a program to figure out how to do things". It will improve things, but
to have actual functionality (instructions or so) instead of tables
would be even better. Ideally, fonts would come with Java-like methods
for this that could run on any hardware.
Regards, Martin.
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:33 EDT