[hb-view] SVG output could include richer information

[n8willis]

Currently, SVG output from hb-view applies an id element with values like "glyph0-1" to each glyph.

It would be useful to me, for subsequent image-processing, to have some richer information embedded.

For instance, if each glyph's element got an id corresponding to its GID from the font, it would be easier to locate the individual contours in an editor like Inkscape or in a script.

It would be nice to get even richer than that, such as to use input Unicode codepoint as an embedded value, but obviously that starts to get more complicated with GSUB and with what SVG attribute it should go to.

Possibly the "original" Unicode codepoint could get included as a class attribute. Then you could trace a little bit of behavior.

For visualization purposes like I was thinking of, that would let downstream tools do things like apply different CSS styles, and automatically highlight a particular element.

I also think it could be useful in debugging; one of the nice things about SVG is that you can examine the results of shaping up close and personal, but with a little more info embedded that could go a long way further.

I'm sure there's complexities and fallback scenarios I haven't thought of here, as well as a long tail of possible info that could overload things (cluster ids! fontnames! script tags! etc etc). But if HB has to generate the id element anyway, I don't think it would hurt to add a more meaningful id value when it does so.

And I don't think that including a few other bits, if they're reliable, as class (or whatever it should be) elements adds significant weight to the SVG files themselves; the paths dominate the file size there.

[khaledhosny]

The SVG output is generated by Cairo, so we don’t have much flexibility here. At this point, it might be better to roll your own solution in Python, using uharfbuzz or even better blackrenderer.

[n8willis]

Well, I know it's not trivial, I just want to propose that it's worth some consideration, given that it could be useful.

Right now the calling down to cairo is pretty direct; possibly going through something like librsvg that also talks cairo would add some knobs without altering the results. Or some other approach; there are some graph-theory libraries that do various levels of this sort of metadata embedding by plonking-in their own XML directly.

But yes, I concur that there are alternatives elsewhere which are a more rapid solution for the immediate future. Allsorts-tools already does the id thing (although not additional information). I just want to see hb-view get fancier too.

[behdad]

If we were to do that we have to generate the SVG ourselves from hb_draw output. I thought of it as possibly a separate tool called hb-draw.

[n8willis]

Yeah, that does make sense. hb-view is showing "final output" (within limitations), and this use-case is a bit different in intent.

[behdad]

I don't see this happening unless someone volunteers.

[yisibl]

The SVG output is generated by Cairo, so we don’t have much flexibility here. At this point, it might be better to roll your own solution in Python, using uharfbuzz or even better blackrenderer.

@khaledhosny @behdad Can this be done by integrating resvg?

[behdad]

The SVG output is generated by Cairo, so we don’t have much flexibility here. At this point, it might be better to roll your own solution in Python, using uharfbuzz or even better blackrenderer.

@khaledhosny @behdad Can this be done by integrating resvg?

I don't think that's something we want.