Re: [ft-devel] Fwd: Issue 977845 in chromium: pdf_font_fuzzer: Integer-overflow in compute_glyph_metrics
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
Re: [ft-devel] Fwd: Issue 977845 in chromium: pdf_font_fuzzer: Integer-overflow in compute_glyph_metrics
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
Sent: 06 August 2019 20:08
To: freetype-devel
Subject: [ft-devel] Fwd: Issue 977845 in chromium: pdf_font_fuzzer:
Integer-overflow in compute_glyph_metrics
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 00:34:24 -0700
An: madig...@gmail.com
{ "@context": "http://schema.org;, "@type": "EmailMessage",
"potentialAction": { "@type": "ViewAction", "name": "View Issue",
"url": "https://bugs.chromium.org/p/chromium/issues/detail?id=977845;
}, "description": "" }
Updates:
Labels: M-76 Test-Predator-Wrong
Comment #5 on issue 977845 by kkal...@chromium.org: pdf_font_fuzzer:
Integer-overflow in compute_glyph_metrics
https://bugs.chromium.org/p/chromium/issues/detail?id=977845#c5
Unable to provide possible suspect using Predator, CL and Code Search.
Could someone please look into the issue.
Thank You...
--
You received this message because:
1. You were specifically CC'd on the issue
You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings
Reply to this email to add a comment.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Fwd: Issue 977845 in chromium: pdf_font_fuzzer: Integer-overflow in compute_glyph_metrics
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 00:34:24 -0700
An: madig...@gmail.com
{ "@context": "http://schema.org;, "@type": "EmailMessage",
"potentialAction": { "@type": "ViewAction", "name": "View Issue",
"url": "https://bugs.chromium.org/p/chromium/issues/detail?id=977845;
}, "description": "" }
Updates:
Labels: M-76 Test-Predator-Wrong
Comment #5 on issue 977845 by kkal...@chromium.org: pdf_font_fuzzer:
Integer-overflow in compute_glyph_metrics
https://bugs.chromium.org/p/chromium/issues/detail?id=977845#c5
Unable to provide possible suspect using Predator, CL and Code Search.
Could someone please look into the issue.
Thank You...
--
You received this message because:
1. You were specifically CC'd on the issue
You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings
Reply to this email to add a comment.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] GSoC: OT-SVG: Update on the whole bounding box issue
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_bitmap', after getting the cbox, some > math is done on it and ultimately top-left and sizing is set. > > ft_glyphslot_preset_bitmap is by no means perfect and should be split > between the native renderers. I am just asking to detach bbox > calculation (or rather bitmap size and pixel position) from rendering. > There are applications that need the size and position well before the > bitmap is allocated and rendered. Do not assume otherwise. > ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] GSoC: OT-SVG: Update on the whole bounding box issue
>> 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 set. ft_glyphslot_preset_bitmap is by no means perfect and should be split between the native renderers. I am just asking to detach bbox calculation (or rather bitmap size and pixel position) from rendering. There are applications that need the size and position well before the bitmap is allocated and rendered. Do not assume otherwise. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] [GSoC'19] ftinspect update
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 * Implemented ftdiff comparator CLI Utilities: * Implemented ftvalid * Implemented ftlint * Implemented ftdump Although all the major options/parameters for each of the demo programs had been implemented but some minor parameters still remains to be added and GUI also requires some final touch-ups. Below are some of the features to be implemented: ftview + ftstring * String rotation parameter * Option to display dynamic string * Embedded bitmaps option * Color palette option ftdiff/ Comparator * Layout mode parameter * Custom LCD filter weight CLI utilities are finished to completion. Apart from CLI utilities, the GUI needs minor changes and final touchups for nicer output and display of glyphs (Needs to be aligned on base line). Note: Remaining features would be implemented within a day or two. Thanks -- Veeki ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] GSoC: OT-SVG: Update on the whole bounding box issue
> > 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 FT_Renderer_Class is equipped with 'get_glyph_bbox', > separate from 'render_glyph'. It is not currently used however and an > outline glyph sets up its top-left and the bitmap size based on the > outline cbox. > > 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. > So, after taking a close look at this function, I have a few concerns. Currently, in `ft_glyphslot_preset_bitmap', after getting the cbox, some math is done on it and ultimately top-left and sizing is set. If we instead set up a loop which will iterate different renderers and get the bbox via `get_glyph_bbox', it'll still work fine for traditional glyphs. But SVG glyphs have their own coordinate system and their bounding box will be in their coordinates, so it will become a mess. One way around this is, I write `get_glyph_bbox' for the `ot-svg' module in such a way that it converts the SVG bounding box to the equivalent bounding box in TTF/CFF coordinate system. But that's too much work and I don't know what would be the advantage of doing it this way. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
