RE: [devel] Problems with kerning support for PFR fonts in FreeType2 v.2.1.4.

[Turner David]

Hello,

It seems you've spotted a rather important bug in the PFR implementation.
I have commited a fix yesterday night to the CVS. Could you please check
it now ? I lack the time to do that properly myself...

By the way, the fix does:

  - fixes the "pfr" driver check in src/base/ftpfr.c
  - fixes the kerning table loader, now all pairs are
    (gindex,gindex) instead of (charcode,charcode)

Thanks in advance,

- David Turner
- The FreeType Project  (www.freetype.org)


> -----Original Message-----
> From: address@hidden 
> [mailto:address@hidden Behalf Of Adam Piotrowski
> Sent: Monday, September 08, 2003 12:11 PM
> To: address@hidden
> Subject: [devel] Problems with kerning support for PFR fonts 
> in FreeType2 v.2.1.4.
> 
> 
> Dear All,
> 
> This is my "first time" on any Open Source developer's list,
> so do not hesitate to point out if I did something wrong.
> 
> Company I work for uses FreeType2 in SetTopBox software.
> I have had 3 problems with retrieving kerning data out of PFR 
> font file,
> after applying solutions described below I have got sensible 
> kerning pairs
> from the PFR file.
> 
> 1. function FT_Get_PFR_Kerning() always returns error code = 132.
>     I think the reason of the problem is in the file 
> src/base/ftpfr.c, line
> 38 -
>     This is the place were the function ft_pfr_check() looks 
> for the string
> "pfr",
>     but the index were the terminating null is looked for is 4.
>     After changing index to 3 the string "pfr" is matched correctly.
> 
> 2. Kerning pair data are processed incorrectly, due to the 
> type definition
> in:
>     src\pfr\pfrtypes.h, line 282.
>     The type defines flags in the extraItem carrying kerning 
> pair data;
> these flags
>     indicates if charcter codes or kerning adjustment, 
> respectively, are
> encoded on 1 or 2 bytes.
>     Values of this enum type are applied as bit masks to the 
> byte with flags
> in order
>     to extract each flag. In my opinion enum values are swapped which
> resulted in
>     2-byte codes being interpreted as single-byte, and single-byte
> adjustment as 2-byte long,
>     this lead to a total mess in retrieved kerning data - I 
> could retrieve
> only
>     2 corrupted pairs instead of 950 present in the font file.
>     (see the description of PFR format:
>     http://www.davic.org/Download/Spec1_4_1/141_part09.pdf - 
> Information
> Representation.
>     Annex A - Coding of the Outline Fonts, par. A.10 Kerning data)
> 
>     The type is defined as follows:
> 
>   typedef enum PFR_KernFlags_
>   {
>     PFR_KERN_2BYTE_ADJ      = 0x01,
>     PFR_KERN_2BYTE_CHAR  = 0x02
>   } PFR_KernFlags;
> 
>   I have changed it to the following:
> 
>   typedef enum PFR_KernFlags_
>   {
>     PFR_KERN_2BYTE_CHAR  = 0x01,
>     PFR_KERN_2BYTE_ADJ      = 0x02
>   } PFR_KernFlags;
> 
> 3. In the PFR font kerning pairs consist of unicode codes 
> instead of glyph
> indices.
>     Right now I supply FT_Get_PFR_Kerning() with unicode codes of the
> characters,
>     (this is contrary to the FreeType Reference Manual, which 
> says that the
> function should accept glyph indices)
>     but for maybe consistency it would be better to supply
> FT_Get_PFR_Kerning()
>     with glyph indices and do some mapping of indices to 
> unicode somewhere
> in the font driver.
>     I know too little about internals of FreeType to propose 
> some sensible
> solution,
>     probably someone more experienced could comment on this?
> 
> Best Regards.
> 
> Adam
> 
> 
> _______________________________________________
> Devel mailing list
> address@hidden
> http://www.freetype.org/mailman/listinfo/devel
> 

--
This message and any attachments (the "message") is intended solely for the
addressees and is confidential. If you receive this message in error, please
delete it and immediately notify the sender.
Any use not in accordance with its purpose, any dissemination or disclosure,
either whole or partial, is prohibited except formal approval.
The E-Mail transmission can not guarantee the integrity of this message.
CANAL+TECHNOLOGIES will not therefore be liable for the message if modified.