Re: [Freetype] font catalog

[Antoine Leca]

Pavel Kankovsky wrote:
> 
> On Wed, 8 Aug 2001, Brian Stell wrote:
> 
> > > How common are such fonts? Are we talking about widely
> > > distributed commercial (or commercial quality) fonts?
> >
> > Yes, widely distributed commercial quality fonts.
<snip> 
> > For example, on my Microsoft Windows 95 system I have 197 TTF
> > fonts of which 70 have these non-space characters that are blank.
> 
> The only font from your list having > 1 blank glyph I have handy is Arial
> Black (ARIBLK.TTF) that is supposed to have 10 blank glyphs out of 670.
> 
> Let's have a look at Arial Black: there are:
> - spaces at U0020 and U00a0 (glyphs #3 and #172),

Should have been filtered out by Brian, since these glyphs are well
known to be "spaces" according to Unicode.

> - a blank character at Uf000 (glyph #210, PS name says "Apple"),

TT spec (from Microsoft) says it should be mapped to the .notdef glyph.
OK, once again specs are here to be avoided!  ;-)
Anyway, this is not a problem in practice, since Mozilla does not have
any "private agreement with the other part of the exchange" (here, the
producer of the HTML document), private use characters are not supposed
to be interpreted at all (specificaly when the font is explicitely
requested, IMHO), and so I believe they should have been discarded by
Brian's test (the same can be said with ``characters'' D800-DFFF as well);

> - 9 blank glyphs in Unicode range Uf100-Uf108 (glyphs #305-#313, having
>   funny PS names like "noTheta"),

Probably (I did not check) this is in conformance with some other
"commercial" encoding which were used by Monotype or others, and did
survive the "quality tests" done by Microsoft when they incorporated
the font in their products; or else it might be to avoid drawing the ugly
.notdef box with some software at Microsoft or anywhere else (Windows
is very common of this: instead of fixing the offending software, they
fixe the next release of Windows, in order to avoid press comments
and user pressure about "lack of compatibility".)

> - two other blank glyphs (#1 and #2) not found in the Unicode cmap

This is correct according to TT spec; furthermore, Brian did not check
them, if I understood correctly his test.

As a result, we have 10 characters (same number as Brian), of which...
10 are private use characters.

Brian, is it possible to redo your test, but instead of discarding only
the space characters, you should discard private use characters and
the other undefined characters (like D800-DFFF or FFFE), according to
the following reasonment: if you have such a character that appears
in a document, and if the font displays a "blank" glyph, in any instance
you are not able to replace the font with another one, since:
 - the very fact the glyph is blank might very well be correct;
 - unlike the other Unicode characters, private use characters do not
  have assigned meaning, so the glyph from a different font is not
  generally substitutable.

 
> This is really wierd. It looks like some sort of censorship.

;-)

 
> > Almost half the the cmap is broken. Drawing based on the raw cmap
> > could produce a page with a lot of blank characters.
> >
> > I also would prefer to not use broken fonts but I would have a
> > hard time telling Japanese Mozilla PC users that while IE can use
> > MS Gothic that Mozilla cannot.
> 
> Have you tried to figure out where IE gets replacements for those blank
> glyphs?

The fact here is that IE functions on a different way. As I understand,
it classifies fonts according to the language they support, and the
Japanese font we talk about is to be used to render... Japanese; and
I am quite sure a Japanese text, even if encoded in Unicode, will be 
rendered without any error using this font; however, if you try to render
say Chinese with this font, you might well end with blank glyphs.
What happen is that this font has a OS/2 map, and this map indicates
"Japanese, but not Chinese". As a result, when displaying Chinese,
IE unselects this font and instead, select a replacement font with
all the needed characters.
I am not an expert at the way IE or NN do function internally, so
I might have guessed some points wrong; however, I believe the overall
picture is correct.


Antoine