>
> In practical terms, we need the bounding box to initialize the
> top_left and the bitmap size. These values might be needed even if the
> actual memory allocation and rendering is postponed indefinitely. One
> should *not* expect immediate allocation of memory and rendering. For
> this purpose
Quick intro: https://youtu.be/d3NuqFckEoU
Hi folks,
A quick brief/update on what I have implemented till now
and features which are supposed to be implemented still.
GUI related programs:
* ftview + ftstring combined and implemented
* Implemented remaining ftgrid features in ftinspect
* Implemen
>> In other words, 'ft_glyphslot_preset_bitmap' should be looping through
>> appropriate renderers calling 'get_glyph_bbox'. This is how it is
>> supposed to work.
> Currently, in `ft_glyphslot_preset_bitmap', after getting the cbox, some math
> is done on it and ultimately top-left and sizing is
Got it. Will do soon. :)
On Tue, Aug 6, 2019 at 6:28 PM Alexei Podtelezhnikov
wrote:
> >> In other words, 'ft_glyphslot_preset_bitmap' should be looping through
> >> appropriate renderers calling 'get_glyph_bbox'. This is how it is
> >> supposed to work.
>
> > Currently, in `ft_glyphslot_preset_
Forwarding the following message I received regarding a fuzzer find.
I'm not sure what to do about it.
-- Weitergeleitete Nachricht --
Von: kkal… via monorail
Betreff: Issue 977845 in chromium: pdf_font_fuzzer: Integer-overflow in
compute_glyph_metrics
Datum: Wed, 10 Jul 2019
Thanks for sending that in -- looks harmless but is worth fixing; if for
nothing else but avoiding these kinds of reports in apps that fuzz FreeType ;)
I'll happily look into it later and provide a fix.
Armin
-Original Message-
From: Freetype-devel On
Behalf Of Nikolaus Waxweiler
Sen
Thanks for looking into it. FWIW, my commit merely re-enabled an older
code path.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
