[Fontconfig] strange behavior for font with partial bitmap embedding

[mpsuzuki at hiroshima-u.ac.jp]

Hi,

Either I know little about fontconfig, but saying a few
can be better than nothing.

On Sun, 15 Jul 2007 17:11:43 -0400
Qianqian Fang <fangq at nmr.mgh.harvard.edu> wrote:
>I know little about fontconfig, just curious if this behavior
>is by design or a potential bug of fontconfig.

Although fontconfig can store the information to switch
anti-aliasing and subpixel rendering, the rasterization
itself is executed out of fontconfig. The fontconfig has
no responsibility how to these control switches are used
in font rasterization. Just fontconfig replies the defined
value for boolean anti-aliasing and RGB ordering for
subpixel rendering, per the query for each face.

It must be noted that fontconfig can store single value
per face, for these control switches. In the other words,
fontconfig cannot control these values per glyph. I think,
you want the rasterizer to work as following strategy:

1. If the face includes bitmap glyph at requested pixel
   size, the rasterizer should use it to display the glyph.

2. If the face doesn't include bitmap glyph at requested
   pixel size, the rasterizer should make anti-aliased
   (and subpixel-rendered) image from vector data.

But these strategy is out of the control which fontconfig
can. I think, the 1st behaviour you mentioned should be
checked by Xft (I guess OpenOffice.org uses fontconfig but
does not use Xft, so the rendering behaviour is different
from most GNOME applications, as you found). Yet I don't
have good idea for the simplest test.

The lost of glyph is big impact (and not expected), I'm not
sure the 2nd behaviour is the bug /or not. I guess hinting
switch on GNOME font panel just changes the autohinting
of FreeType2, so the exist of TrueType native bytecode hinting 
is not critical parameter.

Regards,
mpsuzuki