freetype-devel
[Top][All Lists]
Advanced

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

Re: [devel] Problems with kerning support for PFR fonts in FreeType2 v.2


From: Adam Piotrowski
Subject: Re: [devel] Problems with kerning support for PFR fonts in FreeType2 v.2.1.4.
Date: Wed, 10 Sep 2003 12:42:12 +0200

Hello,

I have downloaded the latest developement version (03.Sept,  11:43)
and extracting kerning data for PFR fonts worked perfectly for me.
Thanks a lot, I didn't expect changing (charcode, charcode) pairs
to (gindex, gindex) to be done so fast.

Best Regards.

Adam


Turner David wrote:
> 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



reply via email to

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