> > AFAIK, the svg spec pretty much allows the whole of the postscript graphic > operations, and more, but in xml syntax. A few things are skipped in > svg-opentype, like animation(?). I think not having viewport nor > width/height are perfectly legal; [...] > Okay, thank you for clarifying that. > [...] and given the range of operations allowed (translate, scale, clip, > etc), it is almost impossible to know the ink-box/bound-box, without > actually rendering the glyph. While the svg-opentype spec I think says > rendering systems which don't understand svg should fall back to ttf/cff, > the ttf/cff glyphs don't have to agree with the svg glyphs in any > dimensions/offsets, perhaps other than advance-width, for obvious reasons. > The advance width likely need to agree for pragmatic reasons - otherwise > document layout would dramatically change. > Okay, I agree it's impossible. What do you think about the side bearings? How should they be obtained? The OT-SVG specs say: As with CFF glyphs, no explicit glyph bounding boxes are recorded. Note > that left side bearing values in the 'hmtx' table, top side bearings in the > 'vmtx' table, and bit 1 in the flags field of the 'head' table are not used > for SVG glyph descriptions. The “ink” bounding box of the rendered SVG > glyph should be used if a bounding box is desired; this box may be > different for animated versus static renderings of the glyph. Should those be obtained from the ink-box, which, just as you said, can only be obtained after rendering the image?
Received on Wednesday, 31 July 2019 08:05:30 UTC