[smufl-discuss] Re: Glyph Registration and Graphical Metadata

[Joseph Berkovitz]

Thanks for the clarification, Daniel. Happy to have misunderstood :-)

You are right that CSS3 Fonts browser support is rather sketchy right now, and I don't think targeting this API amounts to "aiming low enough" in terms of simplicity. There are lots of advanced web APIs out there that do not yet have traction, which is why I suggested looking at the text-related components of HTML5 SVG and Canvas (which, by the way, resemble earlier platform-independent font/text engines like the one found in Adobe Flash).

In any case, I think the ability for SMuFL fonts to provide a separate file for descriptive data needed at the application level is important. Yes, it could be derived from OpenType via separate tooling, in which case this tooling should perhaps be made available as part of the standard. But to the extent that SMuFL mandates that a packaged font must include this separate file, it makes every SMuFL font immediately consumable by a wider array of applications. That certainly sounds like a worthy goal to me, which I hope you share.

I don't think you have yet addressed the separate (and perhaps more fundamental) question of whether explicitly relying on OpenType itself is a good idea. Obviously it's a solid implementation choice for the present day, but I think the standard will be stronger and more durable if it is expressed in a way that is independent of any particular font technology. It can still be *realized* using OpenType.

…Joe

On May 30, 2013, at 5:26 AM, Daniel Spreadbury <[hidden email]> wrote:
> You are indeed misunderstanding my position a bit!
>
> You're a "web guy," as you say, and I am not, so my knowledge of the true capabilities of the APIs used in SVG and HTML5 Canvas is pretty thin. I did some reading yesterday and was certainly encouraged by the richness of the CSS3 Fonts Module (http://www.w3.org/TR/css3-fonts/) though from what I understand browser support for the proposals in this working draft is currently pretty patchy. This module looks to me as if it will allow browsers good access to most OpenType features, such as stylistic alternates, swashes, ligatures (which is already well-supported, as far as I know), and so on.
>
> I think we are in basic agreement on the important points. My basic proposal is still that we should use OpenType features where they make sense, and to have some kind of distinction in SMuFL between symbols that are truly different or just alternative appearances for the same symbol (analogous to the distinction between lining figures and old style figures in text fonts). But we should not necessarily rely on things like OpenType anchors to determine things like stem connection points etc. if API support for those features isn't there: instead, we should provide some separate data file (perhaps *derived from* OpenType anchors or other OpenType features, expressed initially in the UFO format) that applications can consume directly.
>
> I hope this clarifies my proposals somewhat.


#############################################################
This message is sent to you because you are subscribed to
  the mailing list <[hidden email]>.
To unsubscribe, E-mail to: <[hidden email]>
To switch to the DIGEST mode, E-mail to <[hidden email]>
To switch to the INDEX mode, E-mail to <[hidden email]>
Send administrative queries to  <[hidden email]>