Keith Packard wrote:
>
> Around 22 o'clock on Nov 19, Brian Stell wrote:
>
> > Not all apps know which characters will be needed when until after the
> > font is needed/loaded.
>
> That's why I'm trying to create an API that can represent fonts in a
> glyph-set independent fashion.  Do you have any comments on whether my
> list-all-the-fonts method seems reasonable?  Please understand that this
> list is strictly conceptual; the implementation could cull fonts in
> various ways to avoid overwhelming the application with useless fonts.
> That brings up another difficult issue though; I'd like to provide the
> application with as much information as possible in case it wants to try
> and present certain text in the same font.
>
> The obvious mechanism for culling fonts from this list would be to
> eliminate fonts which don't increase the Unicode coverage over the union of
> fonts matching the pattern more closely; this fails to present fonts which
> might contain just the set of glyphs needed for a particular document (or
> paragraph, or whatever unit the upper level software decides is important).

Fonts are always a difficult business since every system has
different fonts and users want the code to use the best fonts
on *their* system. As such, I took a strategy years ago to
have a multilayered fallback. If the 1st choice is not
available, try the 2nd choice. If the 2nd choice is not
available, try the 3rd choice and so on. The best choices are
placed at the beginning and by having a series of fallbacks
the code can degrade as gracefully as possible.

Here is a possible set of choices/fallbacks given a desired
font name and desired font encoding-registry or language group (1).

 1) Name and encoding-registry / TT language group
    Best choice.

 2) Name, encoding-*  (applies to X fonts only)
    Regroup fonts that were split apart from a larger font.

 3) Name, *-* / any language group
    This assumes that fonts of the same name (say Helvetica) but
    different language groups will more nearly match than
    differently named fonts (say Courier). This is not completely
    true for some CJK fonts.

 4) *, encoding-registry / language group
    Try to get a font from the same language group;
    eg: Japanese fonts are more likely to look similar to
    each other than to a Chinese font.

 5) *, encoding-* (X fonts only)
    A little bit looser specification.

 6) *, *
    This is the "pick anything" stage. Honor the font
    path order but otherwise just pick any font that
    has the character.

At each step of the way pick the font with the characteristics 
that most nearly match the desired characteristics; eg: 
bold/italic/thin/etc.

This is approximately the way that the list of fonts is
generated in Mozilla. The list is always the same regardless
of the order characters are found in a document. To avoid
unneeded searching the search only proceeds down the list
far enough to satisfy the characters that have been seen
*so far*. Most font-lists never get to the "pick anything"
stage and typically the font-lists contain many fonts that
have been selected but not actually loaded.

X fonts have an encoding-registry with a well known set of
characters (ignoring  iso10646 fonts for the moment). This
tends to mean once a font of a given registry-encoding is
added to the list there is no point in adding other fonts
with the same encoding-registry. While Mozilla avoids
these "duplicated" fonts at any particular step of the
search I suspect the font-list could have fonts with the
same encoding-registry added at different steps.

> The obvious mechanism for culling fonts from this list
> would be to eliminate fonts which don't increase the
> Unicode coverage over the union of

An interesting idea that would seem most beneficial for
case where the code was at the "pick anything" stage.
Hopefully, however, this will be the very rare
exception not the norm.



Notes:
1: For TrueType language groups see
   http://www.microsoft.com/typography/otspec/os2.htm#ur
2: asterisk '*' means wildcard or "any"

Brian Stell
_______________________________________________
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Reply via email to