freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] FT_Get_BDF_Property() function does not satisfy LSB stand


From: Werner LEMBERG
Subject: Re: [ft-devel] FT_Get_BDF_Property() function does not satisfy LSB standard
Date: Sun, 11 Jan 2009 12:29:41 +0100 (CET)

> 1) The freetype2 API reference implies that if a given face is from
> a BDF or PCF font and if the 'prop_name' is "RESOLUTION_X", the
> function FT_Get_BDF_Property() will return 'aproperty' with its type
> is 'BDF_PROPERTY_TYPE_CARDINAL' and its 'u.cardinal' has correct
> value.
>
> So when FT_Get_BDF_Property() is called with 'prop_name' is
> "RESOLUTION_X" and a given face from PCF font, the function should
> return 'aproperty' with its type equal to
> 'BDF_PROPERTY_TYPE_CARDINAL'.
>
> However, the function returns 'BDF_PROPERTY_TYPE_INTEGER' instead.

This is correct behaviour but not documented.  First of all, there is
no specification for the PCF format; you have to read it from the X11
sources directly.  However, George Williams extracted the data to
document the format:

  http://fontforge.sourceforge.net/pcf-format.html

There you can see that PCF properties are stored like this:

  struct props {
    int32 name_offset; /* Offset into the following string table */
    int8 isStringProp;
    int32 value;       /* The value for integer props,
                          the offset for string props */
  } props[nprops];

In other words, PCF doesn't make a distinction between signed and
unsigned integers; the value is always stored (and read using the
`atoi' function) as signed.

> 2) The freetype2 API reference also implies that if the given face
>    is from a BDF or PCF font and if the 'prop_name' is "FONT", then
>    if this "FONT" field exists in the given face, the function
>    FT_Get_BDF_Property() will return 'aproperty' with its type equal
>    to 'BDF_PROPERTY_TYPE_ATOM' and its 'u.atom' has the correct
>    value as read from the font file using the FontForge utility.

This is not correct in this particular case.  `FONT' is not a BDF
property in this font!  It's not within the STARTPROPERTIES
... ENDPROPERTIES block and can thus not be extracted with
FT_Get_BDF_Property (the function returns an error).  However, it
might be useful to handle all global key-value pairs within a BDF as
if they were `properties'.  If you think that such a feature is useful
please file a bug report at

  https://savannah.nongnu.org/bugs/?group=freetype

so that this request won't get lost.

I'll document both items.


    Werner




reply via email to

[Prev in Thread] Current Thread [Next in Thread]