Hi,
I have changed the code to get the bounding box by using a
`cairo_recording_surface' instead of relying on CFF/TFF outline bounding
boxes. The code works great and Bixa Color is being rendered properly too.
I have also changed `ft_glyphslot_preset_bitmap' to work with OT-SVG
glyphs, so now,
> Technically it isn't rendering it to pixel data. A Cairo recording surface
> just records the drawing operations without rendering it to pixels (AFAIK).
> Then it uses those recorded operations to find bounds.
Why is it an issue even with clipping? The clipped bounding box can be
very well
> This hook function (for librsvg) would work in the following manner:
> * create a cairo recording surface
> * render the glyph on that surface (you'll have to check whether to render
> the whole document or a particular element)
This is unacceptable because it defeats the purpose. If the
Technically it isn't rendering it to pixel data. A Cairo recording surface
just records the drawing operations without rendering it to pixels (AFAIK).
Then it uses those recorded operations to find bounds.
On Thu, Aug 8, 2019, 9:54 PM Alexei Podtelezhnikov
wrote:
> > This hook function (for
>
> Why is it an issue even with clipping? [...]
Not a big issue. Such inaccuracies are rare, but when they do pop-up, the
inaccuracy isn't a problem. The same happens with Cbox calculation in
traditional glyphs and we are fine with it too. :) The glyph will still
land up at the right place.
>
Hi Werner,
Thanks for the descriptive feedback and I'll make sure to
fix the issues ASAP.
> * The biggest problem is that glyphs in the `ftview' mode aren't
> displayed with correct vertical positions. This is serious bug and
> must be fixed ASAP – I think I reported this already six weeks
