Clarification of some aspect of opentype SVG spec

Hi,

I think a call for addendum of the 2015 spec is up soon; in any case I'd like to mention a few things about SVG in opentype that I thought about, while adding SVG functions to Microsoft Font Validator in the past few weeks.

- compression: The wording in the OT spec is a bit vague - SVG itself supports gzip and deflate delivery and the OT spec says only gzip is required for compliant implementation. I think bare deflate stream is a bad idea in OT - can we be a bit more explicit about avoiding it?

- encoding: I added support to UTF16/UTF32 both endian and utf8. But I imagine one day somebody will want random favorite encodings of theirs for their XML, just because it isn't disallowed. Can something be said about that? Actually supporting UTF32 already seems overkill, since presumably most want to optimize for data size, so utf8 would be the best choice.

- alignment, order and re-use of svgDoc: all the ones I have seen so far are contiguous (i.e. The next svgDoc starts exactly where the last one finishes), in order (svgDoc's are stored exactly in the order as listed in the index), and no re-use. I don't see a reason for re-use, but some drafts and earlier proposals mentions that. Also, the rest of OT specs tend to align to 4-byte for any sizeable structure so I was a bit surprised when I looked at the first font for clarifying this in actual use. A few words can be added about alignment, order and re-use.

Hin-Tak

Received on Friday, 29 January 2016 18:18:24 UTC