freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ft-devel] SVG Rendering Library


From: Moazin Khatri
Subject: [ft-devel] SVG Rendering Library
Date: Thu, 13 Jun 2019 18:25:45 +0500

Hi,

I wanted to briefly discuss about the SVG Rendering Library. It's necessary to do this before we can move on to discuss the callback hooks design. This email doesn't have any questions. It is just to inform you guys about my recent findings and also take feedback and get my mistakes and misconceptions corrected. 

As I see it, ultimately, FreeType is expected to render an SVG glyph outputting the following things:
1. Pixel Data (in slot->bitmap)
2. bitmap_left
3. bitmap_top
4. advance x and y, we can ignore them because they come from a table, so easy.

If I am correct in assuming that these are the only outputs necessary, we expect to do the following using the external SVG rendering library.

1. Get the pixel data of the whole SVG doc (if it contains only one glyph) or the pixel data of any particular node that has the ID "glyph<id>" (if it contains multiple glyphs). This pixel data must be the tightest bounding box of the whole glyph with no redundant white space. This, I think, is necessary.
2. Get the bounding box of the whole doc (or the particular node) in SVG coordinates. This is necessary so that we can figure out `bitmap_left' and `bitmap_top'. It would also be nice to have functions that can give us the `viewbox` as well as the `width` and `height` of the SVG doc (if they exist). 

Resvg can do most of these things except giving the bounding box of the whole SVG. I have been talking to the dev of Resvg about this and he plans to provide this feature soon.

Librsvg's newer versions have functions which would do these things. But the newer version (and its dependencies) aren't available in Ubuntu so it requires a lot of manual compiling to get it to turn. That's gonna take some time for me to test. The older one can also give bounding boxes but only for elements with an ID. Not the whole document.

Once any possible discussion about these things takes place (and I confirm that my thoughts are on the right line) I can move on to discuss ideas about callback hooks design.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]