[Fontconfig] strange behavior for font with partial bitmap embedding

[Qianqian Fang]

(I cc-ed a copy to freetype2 mailing list of this discussion, my 
original question
was posted at 
http://lists.freedesktop.org/archives/fontconfig/2007-July/002639.html )

thank you mpsuzuki for explaining this to me. I had a hard time to isolate
the problem and it is always confusing for me that the font rendering in 
Linux
is related to multiple modules, freetype2,fontconfig, pango, Xft etc. I 
send
my question to this list in the hope that some font experts may hear my 
question
and direct me to the right direction.

Indeed, I had suspected that fontconfig does not manipulate font 
information
down to the glyph level, maybe <blank> is the only exception. However I was
curious on the accuracy/legitimacy of the returned font information for 
this
situation where font has partial coverage of bitmaps at specific sizes. 
In another word,
because fontconfig does not have the granularity to describe the details 
of a
font (it perhaps was not designed for this), will the returned 
incomplete info mislead
the rendering engine?

For example, when a program want to draw a 10pt 'A' and request fontconfig
to provide a list of fonts and font properties (such as embeddedbitmap), 
and
this partially embedded font happen to be the top of the list. Will 
fontconfig tell
the program that this font has embedded bitmaps if it sees an embedded 
bitmap at10pt 'A'?
or it sees more than one embedded bitmaps at 10pt? or it sees more than 
one embedded
glyph in the whole font? or if it set embeddedbitmap to true based on the
percentage of the bitmap coverage? or not telling the program about this 
at all?

A more complex situation is when the program want to draw a bold 10pt 'A'
and 'A' only has medium face outline data, while 'B'-'z' has embedded 
bitmap for 10pt. what
would fontconfig do in this situation? anything that can potentially mislead
the rendering afterward?

again, I am not familiar with either fontconfig and freetype2, just 
hoping this is
something that I can learn, even the rough idea, about the rendering and 
help
me to pinpoint the problem next time.

thank you for your further input.

Qianqian



mpsuzuki at hiroshima-u.ac.jp wrote:
> 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
>
>
>
>