Re: rendering limits in ft_glyphslot_preset_bitmap

Alexei Podtelezhnikov <[email protected]> Thu, 25 Jun 2026 21:07:02 -0400
Newsgroups gmane.comp.fonts.freetype.devel
Message-ID <[email protected]>
Bumping the limit by 10% to 11 ppem is totally fine.
Alexei

> On Jun 25, 2026, at 16:36, Derek B. Noonburg <[email protected]> wrot=
e:
>=20
> =EF=BB=BFI've run into a font that exceeds the limits in
> ft_glyphslot_preset_bitmap. Specifically, I'm getting:
>=20
> [objs:3]      ft_glyphslot_preset_bitmap: [-29 -10 505 202]
>=20
> with ppem =3D 50, i.e., 534 > 10 * 50.
>=20
> This is a completely valid CID CFF font, but it's kind of weird. It's
> from a PDF file that appears to have been created by some sort of OCR
> process that segmented the scanned image into characters and then
> vectorized them (!?). The issue comes up where it converted a
> hand-written signature into a single very wide character.
>=20
> I've checked my analysis by making this change (I'm NOT suggesting
> this as a fix - just a confirmation that my analysis is correct):
>=20
> --- a/src/base/ftobjs.c
> +++ b/src/base/ftobjs.c
> @@ -503,8 +503,8 @@
>                    pbox.xMin < -0x1000000 || pbox.xMax >=3D 0x1000000 ||
>                    pbox.yMin < -0x1000000 || pbox.yMax >=3D 0x1000000 ||
>              ( slot->face                                         &&
> -               ( width  > 10 * slot->face->size->metrics.x_ppem ||
> -                 height > 10 * slot->face->size->metrics.y_ppem ) ) );
> +               ( width  > 11 * slot->face->size->metrics.x_ppem ||
> +                 height > 11 * slot->face->size->metrics.y_ppem ) ) );
>=20
>     if ( ret )
>       FT_TRACE3(( "ft_glyphslot_preset_bitmap: [%ld %ld %ld %ld]\n",
>=20
> I'll see if I can get permission from my customer to share the PDF file
> and font, if that would be useful.
>=20
> I'm not sure if it would make sense to increase those limits (to
> what?), or if maybe there's some other approach?
>=20
> - Derek
>=20