Joseph Berkovitz:
> I have done some more research on web support for OpenType features, and I am concerned that many of your favored approaches for SMuFL rely on OpenType stylistic alternates. These are not generally supported in HTML today in a consistent fashion and, as usual for the web, it is not easy to know when that date will arrive.
>
> For a reasonable survey of this topic please read:
>
>
https://www.typotheque.com/articles/opentype_features_in_web_browsers>
> I am asking again that this standard take a conservative position, so that it can immediately be used to target runtime environments other than native applications. In particular please do not assume the presence of OpenType-specific features. As other posters have pointed out, the standard will be more durable if it does not require access to a specific proprietary type engine. The assumption that future type engines will preserve the OpenType feature set in a backward-compatible fashion is a fragile one, and such breakage will also break this valuable standard-in-the-making.
I would like to point out, that some kind of "font smartness" is
supported well and will be supported, due to requirements of some
writing systems. Ligatures, contextual alternates and some sophisticated
positioning are required for correct spelling in some languages. In
fact, stylistic alternates or rare ligatures may be not supported. But
it is not a problem, if sans-serif version of a TAB clef will be
replaced with a serif one in a web browser, I guess.
#############################################################
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]>
Locked
