For example, the InDesign interface for Stylistic Sets may not be the best, but is it too much to ask for ss01... ss20 to be supplemented by the descriptive name?
>Sets may not be the best, but is it too much to ask for ss01... ss20 to be supplemented by the descriptive name?
From where? It's been on the agenda to add them to the OT spec since last century. 'till then, you got XXXX for a name.
This may be a little premature after 20 years of OT, but I think in general — presenting the nuts and bolts of typography (as features do), rather than a series of bundled options with readable names... is a dismal failure.
I suppose language localization issues might offer a reason to hesitate. Why not a little popup window that previews the substitutions in the code (akin to a font menu that shows a thumbnail preview of each font)?
I would be happy just to see it in whatever language the designer chooses, I can make do better than just ss01. Apparently, Adobe could care less about descriptive names.
From where? It's been on the agenda to add them to the OT spec since last century. 'till then, you got XXXX for a name.
David, the architecture for descriptive names for both Sylistic Set and Character Variant features has been included in the OT/OFF specs for some time now. Feature names are stored in the name table (where they can be localised, Craig) and are referenced in the FeatureParams field of the specific layout features.
I'm aware of a couple of tool options for adding feature naming to fonts. DTL OTMaster can do this, and SIL FontUtils include 'ttffeatparms' for this purpose. The latter can be run on a font after the GSUB and GPOS tables have been compiled, which means that you can add names to OTL features that have been developed in another tool.
Obviously, being able to add names directly in a tool like FontLab or RoboFont etc. would be nice.
It's a bit of a chicken-egg situation, with regard to application support. There are relatively few fonts containing this information, so not a lot of compelling reason for software developers to spend resources on this. This is compounded by the fact that a lot of developers really don't like handing over their UI to arbitrary third-party content, and not only because Joe Hip Type Designer might call his {ss01} feature 'Da Fucking Bomb'.
Obviously, being able to add names directly in a tool like FontLab or RoboFont etc. would be nice.
Glyphs.app has simple support by adding "Name: descriptive-name" in the Notes section of a feature, though I don't believe you're able to add multiple translations of the description, yet.
RoboFont just has you writing the feature file format, so one could just add the featureNames { name "descriptive text"; } section within feature ssXX { … } for the default of English. Described in the Descriptive names for Stylistic Set ('ss01 - ss20') features section of the OpenType Feature File Specification.
In many cases, a separate font would be a better idea. For instance, if you are offering /a and /g alternates, add a font named “Fubar Schoolbook”. Also, separate fonts don’t get buried several levels lower in layout apps.
John: "David, the architecture for descriptive names..."
Wow five years already. It's not working.
Why Joe Hip Type Designer might call his {ss01} feature 'Da Fucking Bomb' is beyond me, but the example shows the depth of the problem to be zero. Joe's Da Fucking Bomb-carrying-font can be called BuggerApple-Regularly, show up in all app's just like features, that's been true for 30 years, and I pointed this out 10 years ago when app developers whined about it then. Joe Hip also has to sell "Da Fucking Bomb" feature as named, and so is taking on the naming credit before it gets to being an app's fault. I know it's not your excuse, but if you believe that kind of excuse, someone is wasting your time.
Nick: "In many cases, a separate font would be a better idea."
I think in any cases where a separate font would be a better deployment, the user should not need to know about it.
James: "...more profitable."
If you need dirty feature money I feel bad, but we try really hard not to accept fonts like that on our sites.
I know it's not your excuse, but if you believe that kind of excuse, someone is wasting your time.
Oh, I think it's a truly lame excuse, but the process of persuading software developers to add support for features, especially ones that involve 'UI real estate', doesn't seem to be an entirely rational one.
I was bemused recently by an online comment that my Gabriola font had been developed to showcase Office 2010's new support for stylistic sets. In fact, the opposite is true: we made the font and then used it to push for that application support.
Sure, there are money issues involved with making a separate font rather than a stylistic set. But why wouldn't you just include it for free? The goodwill involved in that honest decision would be worth more than whatever extra cost you might attribute.
Chris, there are no kerning issues, because each stylistic set that would be a separate font would have all the other features anyway.
However, this thread is about naming, and if you want the user to see the name of the glyph-set, then, even if stylistic sets are named in the OT menu, it’s still better to make a separate font, because the name is not buried several layers deep in the GUI.
What I did in Pratt was to make each of two stylistic sets a separate font, but also include them as stylistic sets, flipped, if you get what I mean. That caters to whatever work method the user prefers, if they don't get too confused!
Application developers are looking for excuses to avoid spending time in development for stylistic sets. Profanity is just an easy blow off. Stylistic sets don't get used because app developers make it down right ridiculous to use them. Since they then don't get used, the developers say, "Hey, no body uses them so why bother!" catch 22.
In many cases, a separate font would be a better idea.
So if you've got five stylistic sets, you need five alternative versions of each font? And if someone wants, say, both the alternative /g and the discretionary ligatures, they have to toggle between fonts in a single sentence, as they did in the Expert Set days? I'm sorry if I'm missing something obvious, but how is this better?
Five alternate versions may be too many, if you have a lot of styles in the family.
And perhaps five stylistic sets is too many, like you couldn’t make your mind up what the typeface should look like.
And who is going to refer to a PDF manual or web site to discover which of five ‘ss’s does what?
And if someone wants, say, both the alternative /g and the discretionary ligatures, they have to toggle between fonts in a single sentence, as they did in the Expert Set days?
No, because each of the alternate fonts has all the other features.
And perhaps five stylistic sets is too many, like you couldn’t make your mind up what the typeface should look like.
Well, I can certainly see that point of view. But I also talk to a lot of designers who really like being able to choose from an array of alternative glyphs. It seems to be what the market wants these days.
Nick - I am the guy/designer who will read the PDF or website to find out what SS05 does... I do it often. I think separate fonts is harder to typeset.
Glyphs.app has simple support by adding "Name: descriptive-name" in the Notes section of a feature, though I don't believe you're able to add multiple translations of the description, yet.
Yes, you are. Instead of the simplified ‘Name: …’ syntax, you can also add the complete, raw featureNames, AFDKO-style, with all the languages you want to add.
Aside: this thread started in June 2013. There are no shipping results yet, but there is some evidence that Adobe is listening to type UI complaints at the highest levels of app development. See the newly created board that met a few weeks ago with Adobe app managers: http://blog.typekit.com/2014/12/18/a-fresh-collaboration-for-better-type-ui/
At least one participant in this thread is on the board. Nudge, nudge, Hudsy.
Yes, I'm apparently on the Adobe advisory board, but was added after the initial consultation, and so far as I know there hasn't been another one since the beginning of the year. Unless I'm not getting the emails.
Adrien, with regard to AFDKO, I believe the same mechanism used for assigning names to Stylistic Sets should also work for Character Variants, but I've never tried this. If not, you could use DTL OTMaster.
Comments
From where? It's been on the agenda to add them to the OT spec since last century. 'till then, you got XXXX for a name.
This may be a little premature after 20 years of OT, but I think in general — presenting the nuts and bolts of typography (as features do), rather than a series of bundled options with readable names... is a dismal failure.
See the current published specs for the Stylistic Set and Character Variant features.
I'm aware of a couple of tool options for adding feature naming to fonts. DTL OTMaster can do this, and SIL FontUtils include 'ttffeatparms' for this purpose. The latter can be run on a font after the GSUB and GPOS tables have been compiled, which means that you can add names to OTL features that have been developed in another tool.
Obviously, being able to add names directly in a tool like FontLab or RoboFont etc. would be nice.
It's a bit of a chicken-egg situation, with regard to application support. There are relatively few fonts containing this information, so not a lot of compelling reason for software developers to spend resources on this. This is compounded by the fact that a lot of developers really don't like handing over their UI to arbitrary third-party content, and not only because Joe Hip Type Designer might call his {ss01} feature 'Da Fucking Bomb'.
RoboFont just has you writing the feature file format, so one could just add the
featureNames { name "descriptive text"; }
section withinfeature ssXX { … }
for the default of English. Described in the Descriptive names for Stylistic Set ('ss01 - ss20') features section of the OpenType Feature File Specification.For instance, if you are offering /a and /g alternates, add a font named “Fubar Schoolbook”.
Also, separate fonts don’t get buried several levels lower in layout apps.
Wow five years already. It's not working.
Why Joe Hip Type Designer might call his {ss01} feature 'Da Fucking Bomb' is beyond me, but the example shows the depth of the problem to be zero. Joe's Da Fucking Bomb-carrying-font can be called BuggerApple-Regularly, show up in all app's just like features, that's been true for 30 years, and I pointed this out 10 years ago when app developers whined about it then. Joe Hip also has to sell "Da Fucking Bomb" feature as named, and so is taking on the naming credit before it gets to being an app's fault. I know it's not your excuse, but if you believe that kind of excuse, someone is wasting your time.
Nick: "In many cases, a separate font would be a better idea."
I think in any cases where a separate font would be a better deployment, the user should not need to know about it.
James: "...more profitable."
If you need dirty feature money I feel bad, but we try really hard not to accept fonts like that on our sites.
I was bemused recently by an online comment that my Gabriola font had been developed to showcase Office 2010's new support for stylistic sets. In fact, the opposite is true: we made the font and then used it to push for that application support.
Chris, there are no kerning issues, because each stylistic set that would be a separate font would have all the other features anyway.
However, this thread is about naming, and if you want the user to see the name of the glyph-set, then, even if stylistic sets are named in the OT menu, it’s still better to make a separate font, because the name is not buried several layers deep in the GUI.
What I did in Pratt was to make each of two stylistic sets a separate font, but also include them as stylistic sets, flipped, if you get what I mean. That caters to whatever work method the user prefers, if they don't get too confused!
Yeah, it's gone.
And perhaps five stylistic sets is too many, like you couldn’t make your mind up what the typeface should look like.
And who is going to refer to a PDF manual or web site to discover which of five ‘ss’s does what?
And if someone wants, say, both the alternative /g and the discretionary ligatures, they have to toggle between fonts in a single sentence, as they did in the Expert Set days?
No, because each of the alternate fonts has all the other features.
featureNames
, AFDKO-style, with all the languages you want to add.At least one participant in this thread is on the board. Nudge, nudge, Hudsy.
Adrien, with regard to AFDKO, I believe the same mechanism used for assigning names to Stylistic Sets should also work for Character Variants, but I've never tried this. If not, you could use DTL OTMaster.
https://www.youtube.com/watch?v=RrqQljBIFPs (skip to about 2 minutes into the video)
There was no OpenType support whatsoever in CorelDraw until version x6.