Query regarding CFF font handling

--00000000000087dacf0641b9a09f
Content-Type: text/plain; charset="UTF-8"

Hello Freetype Development

We use Freetype in our software to handle fonts.
We have noticed a difference in behaviour between versions 2.13.3 and
2.14.1.
Specifically we have example pdf files which contain embedded fonts.
In this case the font type we are interested in are type1 fonts stored in
the compact font format (CFF).

The problem is in the Freetype function cff_get_advances (file
src\cff\cffdrivr.c).
In the 2.14.1 code there is the following check at the start of the
function which now fails
    if ( !FT_IS_SFNT( face ) )
      return FT_THROW( Unimplemented_Feature );

When we load in a font we see that the face->flag is set to 2577 (0x0a11)
And the FT_IS_SFNT call fails because we don't have the following set in
the face->flag
FT_FACE_FLAG_SFNT = 0x08

Now previously in version 2.13.3 we still had a  FT_IS_SFNT check but this
didn't result in an error.
There was code at the end of the cff_get_advances  function which generated
valid metric data.

  Missing_Table:
    flags |= (FT_UInt32)FT_LOAD_ADVANCE_ONLY;

    for ( nn = 0; nn < count; nn++ )
    {
      error = cff_glyph_load( slot, face->size, start + nn, flags );
      if ( error )
        break;

      advances[nn] = ( flags & FT_LOAD_VERTICAL_LAYOUT )
                     ? slot->linearVertAdvance
                     : slot->linearHoriAdvance;
    }

Looking through the ChangeLog I think this was the change, as it is the
only mention of  cff_get_advances in the ChangeLog.

2025-01-08  Alexei Podtelezhnikov  <[email protected]>

* src/cff/cffdrivr.c (cff_get_advances): Do only fast advances.

Otherwise, let TT_Get_Advances fall back on cff_load_glyph to do
slow advances. This avoids unchecked access to cff_load_glyph and
 this is how tt_get_advances is implemented.


Given that the new code no longer returns advances for some fonts that
previously worked under 2.13.3, should this 2.13.3 behaviour be reinstated?


Regards Tony Smith

-- 
This e-mail message has been scanned and cleared by Google Message Security 
and the UNICOM Global security systems. This message is for the named 
person's use only. If you receive this message in error, please delete it 
and notify the sender. 

--00000000000087dacf0641b9a09f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hello Freetype Development<br><br>We use Freetype in =
our software to handle fonts.<br>We have noticed a difference in behaviour =
between versions 2.13.3 and 2.14.1.<br>Specifically we have example pdf fil=
es which contain embedded fonts.<br>In this case the font type we are inter=
ested in are type1 fonts stored in the compact font format (CFF).<br><br>Th=
e problem is in the Freetype function cff_get_advances (file src\cff\cffdri=
vr.c).<br>In the 2.14.1 code there is the following check at the start of t=
he function which now fails<br>=C2=A0 =C2=A0 if ( !FT_IS_SFNT( face ) )<br>=
=C2=A0 =C2=A0 =C2=A0 return FT_THROW( Unimplemented_Feature );<br><br>When =
we load in a font we see that the face-&gt;flag is set to 2577 (0x0a11)<br>=
And the FT_IS_SFNT call fails because we don&#39;t have the following set i=
n the face-&gt;flag<br>FT_FACE_FLAG_SFNT =3D 0x08<br><br>Now previously in =
version 2.13.3 we still had a =C2=A0FT_IS_SFNT check but this didn&#39;t re=
sult in an error.<br>There was code at the end of the cff_get_advances =C2=
=A0function which generated valid metric data.<br><br>=C2=A0 Missing_Table:=
<br>=C2=A0 =C2=A0 flags |=3D (FT_UInt32)FT_LOAD_ADVANCE_ONLY;<br><br>=C2=A0=
 =C2=A0 for ( nn =3D 0; nn &lt; count; nn++ )<br>=C2=A0 =C2=A0 {<br>=C2=A0 =
=C2=A0 =C2=A0 error =3D cff_glyph_load( slot, face-&gt;size, start + nn, fl=
ags );<br>=C2=A0 =C2=A0 =C2=A0 if ( error )<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
break;<br><br>=C2=A0 =C2=A0 =C2=A0 advances[nn] =3D ( flags &amp; FT_LOAD_V=
ERTICAL_LAYOUT )<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0? slot-&gt;linearVertAdvance<br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: slot-&gt;linearHor=
iAdvance;<br>=C2=A0 =C2=A0 }<br><br>Looking through the ChangeLog I think t=
his was the change, as it is the only mention of =C2=A0cff_get_advances in =
the ChangeLog.<br><br>2025-01-08 =C2=A0Alexei Podtelezhnikov =C2=A0&lt;<a h=
ref=3D"mailto:[email protected]">[email protected]</a>&gt;<br><br>* src/c=
ff/cffdrivr.c (cff_get_advances): Do only fast advances.<br><br>Otherwise, =
let TT_Get_Advances fall back on cff_load_glyph to do<br>slow advances. Thi=
s avoids unchecked access to cff_load_glyph and<br>=C2=A0this is how tt_get=
_advances is implemented.<br><br><br>Given that the new code no longer retu=
rns advances for some fonts that previously worked under 2.13.3, should thi=
s 2.13.3 behaviour be reinstated?<br><br><br>Regards Tony Smith</div><div><=
br></div><div><br></div></div>

<br>
<font size=3D"1">This e-mail message has been scanned and cleared by Google=
 Message Security and the UNICOM Global security systems. This message is f=
or the named person&#39;s use only. If you receive this message in error, p=
lease delete it and notify the sender. </font><br>
--00000000000087dacf0641b9a09f--