Re: [ft-devel] BDF and FT_Set_Pixel_Sizes

[Chia-I Wu]

On Wed, Dec 07, 2005 at 03:26:12PM +0100, Werner LEMBERG wrote:
> > > How do you come to this conclusion?  The original BDF
> > > specification (found in the X11 distribution) says that both
> > > FONT_ASCENT and FONT_DESCENT are *logical* values.  They don't
> > > guarantee that all bitmap glyphs are within this range.
> >
> > Still, then we should set y_scale to 8 / (face->ascender +
> > face->descender) in, for example, Set_Pixel_Sizes in ttdriver.c,
> > shouldn't we?
> 
> I'm not sure -- and too lazy to really think about it :-) Do you
> encounter problems with bitmap sizes?
I have two fonts, Chicago.12.bdf and Chicago.bin.  The former has
FONT_ASCENT 12 and FONT_DESCENT 3 and the latter is scalable.  

When I `ftview' Chicago.bin, at size 12, it looks almost the same as
Chicago.12.bdf, while at size 15, it is obviously larger.  This
inconsistency comes from the fact that for BDF font, FT_Set_Pixel_Sizes
selects the real dimensions, while for scalable font, it selects the
nominal size.  With the scaling I mentioned in the last mail, then we
have the consistency back (assuming real dimensions mean ascent +
descent, see below).

<ignore_me>
Actually, I think fixed sizes should be selected by its index in
face->available_sizes, not by FT_Set_{Char,Pixel}_Sizes.  Since font
drivers have enumerated all sizes in face->available_sizes, clients can
choose the one best match their desire directly.
</ignore_me>
> > I found docs/CHANGES mentions this change and it says
> > FT_Set_Pixel_Size is used to select actual font dimensions (the
> > `strike'), not the nominal size.  Maybe my question is what "actual
> > font dimensions" mean?
> 
> Well, if the font contains an 8x16 bitmap, the parameters are `8' and
> `16'.  This is to get a unified interface to all bitmap formats,
> including Windows FNT.  Note that the ppem values in WinFNT files are
> normally incorrect.
`16' means ascent + descent?  I thought 8x16 is the size of the canvas,
which is equal to or larger than the glyph bounding box.
> BTW, your latest changes to the SFNT driver broke FNT files with
> multiple faces (this is, if they contain more than a single bitmap
> font).  Reason is that the check for `face_index' in the SFNT driver
> is done before validation of the font format -- the driver incorrectly
> returns SFNT_Err_Bad_Argument instead of the correct
> SFNT_Err_Unknown_File_Format.  I've fixed that now.
Thank you.

-- 
Regards,
olv