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