Re: [Devel] Misfeature in .fon font handling?

[Werner LEMBERG]

[Please forward this to Pedro Gimeno.]

>   Further investigation has led me to the following conclusion: the
>   problem is in Freetype. Specifically, the font name happens to be
>   the last resource in a frame and the frame size does not include
>   the trailing \0.

According to the winfnt document I have this must not happen.  The
order is

  WinFont header
  <face name>
  <device name>
  <bitmap data>

So the face name can never be the last resource in a (FreeType) frame,
provided the FON file is following the specification.  An exception is
an empty FON file but I think this is not what you have in mind...

>   In the sample ProFont.fon, at offset 0510h starts the .FON font
>   structure [...]
>
>   Note that the dfSize member in this case equals 0E92h, and exactly
>   at offset (0510h+0E92h) = 13A2h there's the trailing \0 which
>   should end the string.

But 13A2h is outside of the frame which size is given by dfSize!  The
valid range is from 0510h to 13A1h, which gives 0E92h bytes.  This
means that your test font is even invalid since the specs say that the
NULL terminator must included for computing the field size.

>   However looking at freetype-2.1.7/src/winfonts/winfnt.c lines 184
>   and 502 it seems that this trailing \0 is never loaded but the
>   string is used as is. The fact that it works properly under Unix
>   somewhat puzzles me.

As mentioned above, it seems that your test font is not following the
specs, and I probably have never seen such a beast.

>   I have not investigated the streaming functions of Freetype so I
>   can't tell what's a good fix for this problem.

Indeed, it's not easy to find an elegant solution.

>   Of course checking the validity of the font name string can't hurt
>   and is even a healthy practice.

Please send me the offending FON file (ProFont.fon?); I'll try to fix
it.


    Werner