Hi,
In this email I intend to list the features we require from an SVG
rendering library for use in OT-SVG project. Some of these were
discussed in the list earlier. But, to report some new findings as
well as to put everything in one place, I am listing everything here.
1. The library must provide the values of the following attributes
on the root `svg' node:
- `viewbox'
- `width'
- `height'
It must also tell us about which ones of these are absent.* In
case none of these are present, the library should still accept
it as a valid document.
2. The library must work with a sophisticated graphics backend
e.g. `cairo' or `skia' which should support `scale' and `translate'
transforms. In case the library doesn't rely on any graphics
backend (I have no idea if there are such libraries out there), it
must provide us ways to modify (or insert) `viewbox', `width' and
`height' attributes in the SVG document. Essentially, this will
achieve the same thing as `scale' and `translate' transforms.
3. Ability to render the whole SVG document (obviously) and
render any particular element with an `ID'. The rendering
should be done with the `viewbox' attribute taken into account.
The latter isn't necessary as long as (1) is true, however, this is
highly preferable.
4. The library must tell us the size of the output pixel buffer that
it needs, before actually rendering it, since this is allocated on
FreeType side.
5. It's preferable that the output buffer that the library emits has
the format ARGB32 and the pixels are stored in exactly the same
layout as FreeType does. In case this isn't the case, the rendering
port must do the job of conversion between the two.
6. A method to give us the bounding box of the whole document
or a particular element. Whether this is necessary or not, I am
still not sure. ATM, I don't think it should be, and none of my
ports use such methods.
---------------------------------------------------------------------------------------
* Most of the stuff here is present in the major three libraries
under our radar, however (1) is not. I'll firstly explain why (1) is
needed and then its status in the major three libraries.
If, an SVG document has none of these attributes specified, its
EM square in the SVG coordinates must have the same number
of units as `units_per_EM' in CFF/TTF coordinates. If the font
authors want to use some other scale in the SVG coordinates,
they use the (`width' & `height') or the `viewbox width & height'
to indicate this. In most of the fonts I have seen, the font
designers use an EM square of 128 units. The viewbox is also
used if the font designers want to consider some line other than
y = 0 as the baseline. They indicate this by modifying `y' of the
viewbox.
`svgnative' doesn't let us access most of these at the moment,
but it's easy to write support for that, as long as the author
agrees. It's quite easy too.
`resvg' provides most of the attributes. However, if an SVG
doc has none of those attributes, it doesn't even consider it
a valid document. Its documentation claims that such a doc
isn't a valid SVG. Please enlighten me here if anyone knows
better.
`librsvg' recently got a new function added namely,
`rsvg_handle_get_intrinsic_dimensions' which meets (1)
completely. However, it's too recent and the newest version
available from most distros don't have this function. It also
has `rsvg_handle_get_dimensions' and `*_get_position'
which can be used for the same thing, though, if all
attributes are absent, it'll instead return the bounding box,
which is not what we want. There is one font that I have
found so far with all of the attributes absent, namely,
Moazin