[mpeg-OTspec] Re: [OpenType] More than 20 Stylistic Sets!

[Thomas Phinney]

Back at the time, Adobe (represented in the discussions by me and David
Lemon) was in favor of doing ss01-99, and Microsoft objected—for much the
reasons John suggests.

Of course, that was 15 years ago, and thinking may have evolved. I remain
in favor of allowing up to 99. If not all apps can expose them all, that
would be too bad, but I would rather have them in the spec, and apps
encouraged to evolve their interfaces, rather than not.

Trivia: I believe you can tell that this feature was at least partly
created by non-programmers, because the numbering starts at 01 instead of
00.  ;)


On Wed, Mar 20, 2019 at 3:07 PM John Hudson john at tiro.ca [mpeg-OTspec] <
mpeg-OTspec-noreply at yahoogroups.com> wrote:

>
>
> On 20032019 12:40 pm, Ken Lunde lunde at adobe.com [mpeg-OTspec] wrote:
> > At this point, based on the discussions thus far, I doubt that anyone
> > can provide a convincing argument against registering 'ss21' through
> > 'ss99' as additional Stylistic Set features.
>
> Well...
>
> The original intention of the Stylistic Set features was to provide
> access for coordinated sets of design variants of complete or
> significant portions of a character subset, e.g. all lowercase letters,
> grouped by shared style. The initial use case was the OpenType-ification
> of the Poetica and Zapfino families, in which the stylistic sets had
> been shipped as separate fonts in their pre-OT incarnations. The
> decision to limit the number of Stylistic Set features to twenty was
> influenced by a couple of factors: one was that the number of stylistic
> sets in Poetica and Zapfino was four, so twenty seemed like quite a lot,
> and the other was that a smaller number was more likely to get buy-in
> from applications needing to give some kind of UI real-estate to the
> features, possibly à la InDesign with a menu listing (I'll leave aside
> the whole other topic of poor UI design for OpenType Layout).
>
> What began to happen fairly soon after the Stylistic Set features were
> registered and began to show up in applications is that font makers
> began using them to provide access to variants of individual characters
> instead of sets of characters, e.g. multiple variants of an ampersand,
> each mapped to a different Stylistic Set feature. And used in this way
> the features very quickly get used up and people start asking why there
> aren't more.
>
> Meanwhile, SIL registered the 0–99 Character Variant features, which not
> only, by design, provide access to variants of individual glyphs, but
> also recommend doing so using GSUB one-to-one-of-many lookups, rather
> than one variant per feature. [It is technically possible, of course, to
> build Stylistic Set feature using such lookups, but application UI for
> these features tends only to expose the first enumerated variant.]
>
> The Character Variant features — including enumerated variants — are
> supported in CSS, but not in common desktop applications, and so font
> makers have continued to use Stylistic Set features to access individual
> character variants, and continued to complain that twenty isn't enough
> to accommodate this use.
>
> I don't know if this is a 'convincing argument', but it seems to me that
> if one is going to have to ask application makers to add support for 80
> new Stylistic Set features, why not ask them to support the existing 100
> Character Variant features instead?
>
> JH
>
> --
>
> John Hudson
> Tiro Typeworks Ltd www.tiro.com
> Salish Sea, BC tiro at tiro.com
>
> NOTE: In the interests of productivity, I am currently
> dealing with email on only two days per week, usually
> Monday and Thursday unless this schedule is disrupted
> by travel. If you need to contact me urgently, please
> use some other method of communication. Thank you.
>
> 
>


-- 
“If I don’t use fancy words, you won’t know I’m an expert.”
—Marcel Matley, document examiner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20190320/0fa8d435/attachment.html>