Re: [Devel] Fonts with glyphs containing zero contours

[Detlef Würkner]

address@hidden (Keith Packard) wrote:

> Around 22 o'clock on Feb 7, =?ISO-8859-1?Q?Detlef_W=FCrkner?= wrote:
> 
> > Maybe this font is broken. I have a msmincho.ttc (~9MB) and a
> > msmincho.ttf (~5MB) with MS copyright that contain many embedded sfnt
> > bitmaps, your version (~3MB) might be generated by a converter that
> > stripped the copyright notice and the bitmaps without correcting the
> > charmap if no outline was there?
> 
> That's more than possible; I don't know frankly recall where this font
> came from.  I was under the impression that msmincho.ttf was supposed to
> hold bitmaps, but clearly the one I have doesn't.  If it did, would the
> system advertise the font as scalable?

Yes.

> And would there be glyphs that were
> only available as bitmaps and not outlines?

Hmm... when using fttimer.c from the 2.0.5 demos linked with 2.0.7,
with/without FT_LOAD_NO_BITMAP (no FT_LOAD_ONLY_BITMAP there) I get
strange results. msmincho.ttf has 13104 glyphs, when specifying
FT_LOAD_NO_BITMAP all 13104 can be rendered, so the answer to your
question is no.

Without specifying FT_LOAD_NO_BITMAP 7887 glyphs fail to render at size
16 (pixels), at size 30 (pixels) 0 glyphs fail. The following bitmap
sizes are available:
   0: height 12, width 12
   1: height 13, width 13
   2: height 14, width 14
   3: height 15, width 15
   4: height 16, width 16
   5: height 17, width 17
   6: height 18, width 18
   7: height 19, width 19
   8: height 20, width 20
   9: height 21, width 21
   10: height 22, width 22

Looks like 16 pixels are too small to display 12 pixels per EM?
No, at 11 pixels and at 23 pixels 0 glyphs fail, at 12 pixels and
at 22 pixels 7887 glyphs fail. So the width and height are the
values to be used for FT_Set_Pixel_Sizes(), but for some reason
the rendering of the bitmaps fails.

Ah, found it, calling FT_Glyph_To_Bitmap() when glyph->format is already
ft_glyph_format_bitmap is wrong. Will download the latest demo archive
and look if it must be patched.

> > While answering to you, can you confirm that the two versions of accelerator
> > tables saved in a PCF file never contain *compressed* metrics?
> 
> Yes, my recollection is that the accelerator tables never use compressed
> metrics.  Reading the X pcf code, I find:
[...]

Thanks! I'll make a patch tomorrow.

> > And have you read that the AVERAGE_WIDTH property in some XFree86 BDF fonts
> > is a string, not an integer ("144" not 144)?
> 
> That's vaguely possible, in any case you should ignore AVERAGE_WIDTH.  It's
> an escapement value, not a bounding box value.  For constant escapement
> fonts (monospace), the metrics should give you the correct escapement.

IMHO setting face->bbox to the accelerator metrics (bounding box in
pixels) and face->units_per_EM to 1 (as in the html docs) would be ok.

Before changing the width/height calculation again (would suggest to
use the accelerator metrics after accelerator loading is fixed and
nothing else) I want to wait for feedback whether to use pixels or
points for width/height.

Ciao, Detlef
-- 
_ // address@hidden
\X/  Detlef Wuerkner, Langgoens/Germany