SVG table

[Peter Constable]

I’m preparing version 1.8.3 of the OpenType spec. Most of it is minor corrections and various editorial improvements that are reflected in the FDIS for OFF 4th Edition. But there is one part that will have some significant technical changes: the chapter on the SVG table.

The SVG table was originally added to the 3rd edition of OFF (then incorporated into OpenType 1.7) based on a US proposal originating jointly from Adobe and Mozilla. This was around five or six years ago (2012 or 2013). For the first few years, the only implementation (as far as I know) was in the Firefox browser.

Something notable about a browser implementation is that browsers (even in 2012) independently already have support for SVG, as well as rich support for CSS and other Web-centric technologies that can interact with SVG. That’s all stuff that wouldn’t likely be found in general, non-browser text-layout/font engines, and isn’t a natural fit for those environments. That was a factor in initially-slow adoption of the SVG table.

In 2016, Adobe and Microsoft began working on implementations to support the SVG table in non-Web environments. In 2016, Microsoft shipped the Windows 10 Anniversary Update with support in the DirectWrite and Direct2D platform components; in 2017, Adobe supported the SVG table in releases of Illustrator and Photoshop, and in a technology preview of InDesign. Adobe and Microsoft worked in partnership on these implementations, particularly to sort out open issues in how to support the SVG table in non-Web environments. Choices needed to be made as to which parts of SVG were more or less valuable, were more or less feasible, or even do or don’t make sense for general text environments. A corollary of this was to start to define a set of functionality that could be used in OT-SVG fonts with some level of expectation of interoperable application support. But nothing was changed in the OpenType spec or in OFF to reflect interoperability in fonts and software that implement the SVG table.

The latest development for the SVG table is that Apple has recently released beta versions of their OS platforms with support for the SVG table in their Core Text platform.

As Apple began work on this, they approached Adobe and Microsoft requesting that the SVG chapter of the OT spec be updated to provide a more-concrete specification for interoperable implementation. As a result, Adobe, Apple and Microsoft (along with other participants and observers) worked on and off over the past year to come up with a revised spec that clearly defines what features should be required, optional or prohibited.

This revision will be incorporated into OpenType 1.8.3. In this revision, some capabilities are prohibited since they make no sense for use within OT/OFF fonts; for example, <font> and <foreignObject> elements, or external stylesheets. Some capabilities are prohibited because the spec limits capabilities to SVG 1.1 and the capabilities in question are candidates proposed in drafts for a newer (yet to be completed) SVG version; for example, context-* property values and rgba() color specifications. Several capabilities are listed as optional, but with a caveat that they should be avoided in fonts intended for widespread distribution; in general, these are capabilities that have significant performance issues or that provide limited additional benefit but would be costly to implement, particularly for general text-layout platforms; examples of optional capabilities include <filter> elements and animations.

At some point in the month or so, I will be submitting a doc proposing changes to clause 5.5 of OFF (the SVG table) for Amendment 1 of the 4th edition, to synchronize with the changes in OT 1.8.3. In the meantime, if anyone is interested in seeing the draft revision for OT1.8.3, feel free to contact me privately.



Peter Constable
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20180721/20b2a6d4/attachment.html>