Re: rendering limits in ft_glyphslot_preset_bitmap

Hi Alexei,

I see the patch in git - thanks for taking care of that.

> BTW, my iPhone vertically truncates the signature glyph too.

Interesting... I see some weird behavior there, too. Seems to be
resolution-dependent (or something).

- Derek


On Fri, 26 Jun 2026 15:49:15 -0400
Alexei Podtelezhnikov <[email protected]> wrote:

> Derek,
>=20
> 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.
>=20
> A typical font utilizes from 1000 to 2048 upem as short integers. I
> can probably justify 16 ppem as a limit.
>=20
> BTW, my iPhone vertically truncates the signature glyph too.
>=20
> Alexei
>=20
> 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:
> > =20
> > > Bumping the limit by 10% to 11 ppem is totally fine.
> > > Alexei
> > > =20
> > > > 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
> > > =20
> > =20
>=20
>=20