Re: [Freetype] Another bug in the BDF backend

[Juliusz Chroboczek]

WL> I'm in favour of supporting non-square pixels.

>> I too would suggest the ppem interpretation (the PCF and snft backends
>> are correct, the BDF one is wrong), but I have no objection to the
>> other one as long as all backends are consistent.

WL> Probably a misunderstanding.  I suggest that FT reports the real
WL> horizontal and vertical dimensions, so I think the BDF driver does the
WL> right thing.

As I've said, I don't care much about the issue.  But the notion of
dimensions of a font only really makes sense for charcell (terminal)
fonts.

In general, a font only has an em size, and both the sfnt format and
the FreeType API work with the em size.  For scalable fonts, FreeType
and the sfnt format contain em sizes in FUnits.  For bitmap strikes,
the sfnt format contains the em size in pixels -- the only
complication coming from the fact that the data are there twice in
order to cater for non-square pixels -- i.e. the em size is included
both in horizontal and vertical pixels.

FreeType currently does report the same data as the sfnt format
defines for sfnt and PCF bitmap fonts.  It does report something else
for for BDF fonts.  Whence my suggestion that the current behaviour of
the PCF backend is what makes sense within the framework of FreeType.

But it's merely a suggestion; do feel free to implement something else
as long as you tell me how to compute the em size.  Catering for
non-square pixels is not necessary -- we do support EGA, but as far as
I know, we only have one (1) user with EGA hardware.

                                        Juliusz