Re: rendering limits in ft_glyphslot_preset_bitmap
Alexei Podtelezhnikov <[email protected]> Fri, 26 Jun 2026 15:49:15 -0400
| Newsgroups | gmane.comp.fonts.freetype.devel |
|---|---|
| Message-ID | <CAJU=AjVK2kfNW1oQeScPP-B2hXrNFgHsLpY6e9Jbu7CD9ro-LQ@mail.gmail.com> |
Derek, These limits are introduced to deal with 60 second timeouts in fuzzing. Those fuzzing fonts are valid too but can be used maliciously in DOS attacks. One could imagine limiting the perimeter but that is actually less robust with fancy fonts in mind. A typical font utilizes from 1000 to 2048 upem as short integers. I can probably justify 16 ppem as a limit. BTW, my iPhone vertically truncates the signature glyph too. Alexei On Fri, Jun 26, 2026 at 1:36=E2=80=AFPM Derek B. Noonburg <[email protected]> wrote: > > I'm just wondering if there's any better approach. My experience with > similar problems in the PDF space is that hard limits like that > invariably get exceeded by some strange-but-valid PDF file, sooner or > later. > > But yeah, increasing the limit to 11*ppem will fix the immediate > problem. > > In case you're interested, I got permission to share the PDF file. I'm > attaching that, along with the extracted font. The problematic glyph is > gid 119. > > Thanks for looking at this. > > - Derek > > > On Thu, 25 Jun 2026 21:07:02 -0400 > Alexei Podtelezhnikov <[email protected]> wrote: > > > Bumping the limit by 10% to 11 ppem is totally fine. > > Alexei > > > > > On Jun 25, 2026, at 16:36, Derek B. Noonburg > > > <[email protected]> wrote: > > > > > > =EF=BB=BFI've run into a font that exceeds the limits in > > > ft_glyphslot_preset_bitmap. Specifically, I'm getting: > > > > > > [objs:3] ft_glyphslot_preset_bitmap: [-29 -10 505 202] > > > > > > with ppem =3D 50, i.e., 534 > 10 * 50. > > > > > > 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. > > > > > > 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): > > > > > > --- 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 ) > > > ) ); > > > > > > if ( ret ) > > > FT_TRACE3(( "ft_glyphslot_preset_bitmap: [%ld %ld %ld %ld]\n", > > > > > > I'll see if I can get permission from my customer to share the PDF > > > file and font, if that would be useful. > > > > > > I'm not sure if it would make sense to increase those limits (to > > > what?), or if maybe there's some other approach? > > > > > > - Derek > > > > > > --=20 Alexei A. Podtelezhnikov, PhD