OpenType feature "tnum" problem in InDesign

andyclymer's picture

Greetings,

I'm currently developing an OpenType font that contains two sets of figures -- Lining Proportional figures as the default and Lining Tabular figures activated with the "tnum" feature.

The Lining Tabular glyphs are named in Adam Twardoch's suggested form of "number.lnum_tnum" and are in the class "@FIG_TAB_LINING", the Lining Proportional figures are in the class "@FIG_FIT_LINING" but the problem also occurs without using classes.

The problem is that InDesign labels the glyphs in the tnum feature as being both tnum and onum even though there is no onum feature in this font. This is to say that in the Glyph palette rolling over the Tabular glyphs shows that they are "Tabular Figures (tnum) + Oldstyle Figures (onum)", and the OpenType submenu of the character palette gives the option to select "Tabular Oldstyle".

I understand that the pnum and tnum features are modifiers for lnum and onum (applying tnum could change lnum_pnum and onum_pnum to their tabular counterparts), so I'm not sure if there's a way that I can or should specify that the glyphs in the tnum feature are *only* lining, and never oldstyle.

To fix this problem I've tried adding an onum feature with a different set of glyphs in from font with the idea that it might draw InDesign's attention away from thinking the tnum group could contain oldstyle figures. I've also switched to using the tabular figures as the default and creating a pnum feature instead, but this ends in the same result of InDesign thinking that the glyphs are both proportional lining and oldstyle.

I've been able to reproduce this in more than one font and I'm using FontLab 4.6 on the Macintosh.

Has anyone else see this? Any thoughts would be much appreciated!

Thanks,
Andy Clymer

.'s picture

Well, I just wrote a whole lot, which got eaten by the site. :-(

Your Default Figures (DF) being Lining Proportional (LP) might be confusing InDesign, as most fonts have Lining Tabular (LT) as default.

Here's what you need to have as your feature:

feature tnum { # Tabular Figures
# Latin
sub @classDF by @classLT;
} tnum;

And this should be in your classes:

@classDF = [zero one two three four five six seven eight nine];
@classLT = [zero.LT one.LT two.LT three.LT four.LT five.LT six.LT seven.LT eight.LT nine.LT];

.'s picture

Okay. This is crazy. My reply got cut off. Sigh...

What I had written after the above was that you should name your LT glyphs as above: zero.LT one.LT etc. This scheme allows the Glyph Panel to see the "children" glyphs and offer them under the pulldowns for the "parent" glyphs.

andyclymer's picture

Chester, thanks for the response. Looks like I'm doing the same thing (just the basic substitution of one class for another):

feature tnum {
sub @FIG_FIT_LINING by @FIG_TAB_LINING;
} tnum;

The problem also occurs when I'm not using classes ("sub one by one.lnum_tnum;", etc through the entire set)

andyclymer's picture

Chester, I'll give the ".LT" naming a try right now, thanks.

.'s picture

Yeah, that .lnum_tnum gives me the willies...

In the interest of full disclosure, here's what my full set of numeral subs looks like, with DF being Scotch (M. Carter's "Georgia") -style 3/4-height numerals...

feature onum { # Old Style Numerals
# Latin
sub @class1XDF by @class1XOP;
sub @class4XXL by @class4XXO;
} onum;

feature lnum { # Lining Figures
# Latin
sub @class1XDF by @class1XLT;
sub @class1XOP by @class1XLT;
} lnum;

feature pnum { # Proportional Figures
# Latin
sub @class1XDF by @class1XLP;
sub @class1XOT by @class1XOP;
} pnum;

.'s picture

feature tnum { # Tabular Figures
# Latin
sub @class1XDF by @class1XLT;
sub @class1XLP by @class1XLT;
sub @class1XOP by @class1XOT;
} tnum;

.'s picture

feature numr { # Numerators
# Latin
sub @class1XDF by @class1Xnum;
sub @class1XOP by @class1Xnum;
sub @class1XLP by @class1Xnum;
sub @class1XLT by @class1Xnum;
sub @class1XOT by @class1Xnum;
} numr;

feature dnom { # Denominators
# Latin
sub @class1XDF by @class1Xdnom;
sub @class1XOP by @class1Xdnom;
sub @class1XLP by @class1Xdnom;
sub @class1XLT by @class1Xdnom;
sub @class1XOT by @class1Xdnom;
} dnom;

feature sinf { # Scientific Inferiors
# Latin
sub @class1XDF by @class1Xinf;
sub @class1XOP by @class1Xinf;
sub @class1XLP by @class1Xinf;
sub @class1XLT by @class1Xinf;
sub @class1XOT by @class1Xinf;
} sinf;

And in the classes pane:

@class1XDF = [zero one two three four five six seven eight nine];
@class1XLT = [zero.LT one.LT two.LT three.LT four.LT five.LT six.LT seven.LT eight.LT nine.LT];
@class1XOP = [zero.OP one.OP two.OP three.OP four.OP five.OP six.OP seven.OP eight.OP nine.OP];
@class1XOT = [zero.OT one.OT two.OT three.OT four.OT five.OT six.OT seven.OT eight.OT nine.OT];
@class1XLP = [zero.LP one.LP two.LP three.LP four.LP five.LP six.LP seven.LP eight.LP nine.LP];
@class1Xnum = [uni2070 uni00B9 uni00B2 uni00B3 uni2074 uni2075 uni2076 uni2077 uni2078 uni2079];
@class1Xdnom = [uni2080 uni2081 uni2082 uni2083 uni2084 uni2085 uni2086 uni2087 uni2088 uni2089];
@class1Xinf = [zero.inf one.inf two.inf three.inf four.inf five.inf six.inf seven.inf eight.inf nine.inf];

.'s picture

This works for me. And yes, the order of the features IS important.

[Hey moderators! I had to break my post into chunks, for some reason.]

.'s picture

Ooops! Forgot these:

@class4XXL = [Euro dollar cent sterling florin yen uni20A1 uni20A2 uni20A3 uni20A4 uni20A6 uni20A7 uni20A8 uni20A9 uni20AA uni20AE uni20B1 numbersign percent perthousand];
@class4XXO = [Euro.OP dollar.OP cent.OP sterling.OP florin.OP yen.OP uni20A1.OP uni20A2.OP uni20A3.OP uni20A4.OP uni20A6.OP uni20A7.OP uni20A8.OP uni20A9.OP uni20AA.OP uni20AE.OP uni20B1.OP numbersign.OP percent.OP perthousand.OP];

dezcom's picture

Thanks Chester! One more item for my OpenType feature code notebook!

ChrisL

andyclymer's picture

The ".LT" naming didn't change anything, InDesign still thinks that the glyphs in the "tnum" feature are also in a "onum" feature even though there isn't one in the font -- when I open the OTF back into FontLab the feature set decompiles without any onum feature.

As far as I can tell I'm writing the feature code the same way that you are, for testing I've stripped the font down to just the "tnum" feature that I posted above.

InDesign switches from the default Proportional Lining figures to the Tabular Lining figures without any problems with this code, it's just that it also still thinks that the glyphs that are in the tnum feature are also in an onum feature.

.'s picture

Or several items, thanks to the engine of this site. (Shakes fist in mock anger.)

.'s picture

That's whack, Andy. What does Text Edit see?
Did you know that you can access OT features using Text Edit. Here's how:
Type some text.
Select it.
Hit Command-T for the Font Palette.
Change the font to your OT font.
Click and hold the little "Tool" cog icon button in the bottom left corner of the Font Palette.
Select Typography...
A new palette will pop up which gives you access to your font's features. (Even SSes!)

andyclymer's picture

Maybe the problems are a bit deeper because when I do that the Typography window says "No typographic features in this font." It's an OpenType CFF and FontLab doesn't register any errors when compiling the features...

andyclymer's picture

About the ".lnum_tnum" naming, I was following Adam Twardoch's suggestions from this Fontlab Forum thread, he breaks things down pretty well for building a font that's going to take advantage of all four figure substitution possibilities, but that's not a concern with this font.

His explanation is good (and I'll respond to that thread with this question when I've been approved to be added to the FontlabForum) in explaining that "tnum" isn't Lining or Oldstyle specific. I'm sure that InDesign just sees that a class can be switched from any kind of proportional to any kind of tabular and just assumes that the glyphs within could belong to either or both.

I'm wondering if anyone else has tried to build an OTF with Prop and Tab Lining figures and see what comes up?

Here's what InDesign shows for a glyph that is only in the tnum class and feature:
indesign feature popup image

.'s picture

All I can say is that fonts built with the code I included above work correctly in CS1 and CS2 apps. If there is one thing I have learned about OT feature coding, it is this: "If it works, don't touch it even a little. Don't try to improve it. Move away fromt he keyboard..."

Mark Simonson's picture

Andy, have you built a kern feature yet for the font? I seem to recall that the absence of a kern feature can cause the font's other features not to be recognized. Or maybe I'm thinking of something else. Just a hunch. Edit: Never mind. I must be thinking of something else.

FWIW, I built Proxima Nova with proportional lining figures as the default without a problem. I did not give them any special names, just one, two, three, etc. For the other three variants, I used .tnum for tabular lining, .onum for proportional old style and .tonum for tabular old style. I don't thing the naming of the variants matters, but the naming of the default figures probably does.

twardoch's picture

Chester,

As for the glyph name suffixes, they are fully arbitrary. You can call your lining tabular one "one.LT", "one.lftf", "one.ltf, "one.lnum_tnum", "one.liningtabular", "one.mylefteyebrow" etc. What is important is the use of the period and the suffixes.

At Fontlab Ltd., we recommend using four-letter suffix parts that are derived from OpenType feature names due to consistency. The glyph name suffixes are not standardized in any way but the OpenType Layout feature tags are (lnum, onum, smcp). The only way you can have industry-wide consistency is to use consistent suffixes, and the only way to do it is to use suffixes based on standardized strings -- that being the OpenType Layout feature tags. So a small-caps A should be "A.smcp", but it can also be "A.sc" or "A.small" or whatever, but not "Asmall" (since there is no period and no suffix).

Whenever there is a suffix where a glyph is accessed through a combination of features (like onum+tnum), we recommend sorting the suffix parts alphabetically and concatenating the suffix parts using underscore (e.g. "one.pnum_smcp" and "one.smcp_tnum").

But really, the only advantage of this approach is that it's systematic. If you don't care for being systematic, you can use any glyph suffixes you want.

Andy,

something is probably wrong with your OpenType Layout feature code. The glyph naming doesn't really matter so much. Contact Fontlab Ltd. support at http://www.fontlab.com/problem/ for that and we'll take a look.

Regards,
Adam

andyclymer's picture

Mark,
The OpenType export options are set to generate a kern feature, I've noticed the same feature funnyness if the OTF is built without the kern feature.

Chester,
The help is much appreciated, thanks for the time and suggestions

Adam,
I'll contact FontLab support as you suggest.

Thanks
-- Andy

.'s picture

I defer to Adam in many matters, and am glad to hear that his comments pretty much mesh with my workflow.

Andy, I would be happy to poke through your file for wonkiness, if that is something you're interested in. (I spend half of my life in other people's files, getting them ready for publication, etc.) chester [at] vllg.com

Thomas Phinney's picture

On the TextEdit thing, note that OS X OpenType feature support requires OS X 10.4 or later. I'll bet Andy is using an older version of OS X.

As for InDesign and the features, this is essentially a limitation of the way InDesign's UI is set up to access the figure styles in pairs: one of [lining, oldstyle] and one of [tabular, proportional]. If you have even one of the two features in the pair, InDesign will give people the option of turning on both features. The reasons for this have to do with InDesign not knowing what your default figure type is, and the fact that you might have one but not both features of one of the pairs, even though you are in fact supporting the desired result.

One option would be for InDesign to go to a model where you set oldstyle vs. lining with one toggle and tabular vs. proportional with another. But for most cases that would mean two trips to the menu where today one gets by with one. So it's not an attractive option with the current UI. If some day InDesign gets a palette approach like Illustrator, it might be a little easier to go down that path.

Regards,

T

dezcom's picture

"If some day InDesign gets a palette approach like Illustrator, it might be a little easier to go down that path."

A series of check boxes would do the trick.

ChrisL

k.l.'s picture

Mr Clymer,

> I’m currently developing an OpenType font that
> contains two sets of figures — Lining Proportional
> figures as the default and Lining Tabular figures
> activated with the “tnum” feature.

So, your figures are all lining, and the distinction
is tabular vs proportional only.
Which means, you decide which set of figures shall
be the standard figures (say, tabular ones) and name
them zero one two three ... plus according class.
The other ones will be proportional, with appendix
.pnum (or whatever else, I confess my appendices
are quite arbitrary too) plus according class.

The tnum feature now substitutes zero.pnum one.pnum
two.pnum three.pnum ... by zero one two three ...
The pnum feature replaces zero one two three ... by
zero.pnum one.pnum two.pnum three.pnum ...

As long as you would not add oldstyle figures, you
don't need lnum (lining) and onum (oldstlye) features
at all.

Chester -- DF/scotch as default is a VERY nice
solution!
(And the I-hate-doing-figures me says, oh dear, one
more set of figures ...)

Mr Phinney --

> One option would be for InDesign to go to a model
> where you set oldstyle vs. lining with one toggle
> and tabular vs. proportional with another.

... which would closer resemble how the features work ...

> But for most cases that would mean two trips to the
> menu where today one gets by with one. So it’s not
> an attractive option with the current UI.

... which is true. And now I am curious:
(1) In which way are figure styles offered in TextEdit/10.4?
(2) And, even more interesting, in what about Windows
Vista applications?

Karsten

twardoch's picture

Chris L writes:
> A series of check boxes would do the trick.

No, it would not. If you have a selection between two options (proportional vs. tabular, old-style vs. lining) or even a selection between four different versions (proportional old-style, proportional lining, tabular old-style, tabular lining), checkboxes are the worst UI implementation you could choose.

Karsten writes:
> (1) In which way are figure styles offered in TextEdit/10.4?

Two groups of radio buttons, one for the proportion (tabular vs. proportional), and the other for alignment (lining vs. old-style).

> (2) And, even more interesting, in what about
> Windows Vista applications?

That depends on how you write your XAML file.

A.

andyclymer's picture

Thomas,

> If you have even one of the two features in the pair, InDesign will give people the option
> of turning on both features. The reasons for this have to do with InDesign not knowing
> what your default figure type is, and the fact that you might have one but not both
> features of one of the pairs, even though you are in fact supporting the desired result.

So there probably isn't a problem with the way I'm building the features for this font, it's just because there's no way to describe to InDesign that in this font the tabular figures are always lining and never oldstyle?

I'm curious though, the only figure related feature in this font is tnum but in the glyph palette when I mouse over a glyph from the tnum feature it says that the glyph is "Tabular Figures (tnum) + Oldstyle Figures (onum)", but why wouldn't it also assume that the glyph could be Tabular and Lining? If there isn't even an onum feature in the font I don't think we should be seeing "Oldstyle Figures (onum)" here, do you agree?

Much appreciated,
-- Andy

Thomas Phinney's picture

Andy,

Yes, agreed on all counts.

I think Adam is right about radio buttons being the theoretical ideal approach, as well.

Cheers,

T

Randy's picture

Side Note:

Andy, we met at typecon in San Francisco before you left to start the KABK program. I recently checked out your thesis project and thought it was great. It is unique to see such an American effort. Nice work and congratulations!

Randy

trine rask's picture

Hi Andy;
What you see in the glyph palette in InDesign is the possible features the glyph could be a part of. I just generated Tabular Lining, Proportional Lining, Proportional Onum and Tab Onum.
I wrote the features:
feature tnum {
sub @linfig by @tablinfig;
sub @onum by @tabonum;
} tnum;

&
feature onum {
sub @linfig by @onum;
} onum;

if I choose Tabular Oldstyle in InDesign I get it, even if I have Proportional Lining Figure.
When I mouse over the glyph palette I see possible actions between existing glyphs with names similar to my features and after adding Old Style figures the choise tab onum is no longer listed by the Lining Fig as you have it. But now I see pnum by proportional oldstyle though its actually in tnum feature and lnum by Lining Figures though its actually in the onum feature. So its the same naming, but not the feature on and off, it's the action.
And then until you have defined that default is lining you can get tabular figures by both tab Oldstyle and tab lining

dezcom's picture

> A series of check boxes would do the trick.

Dumb arse me meant radio buttons to begin with.

ChrisL

andyclymer's picture

Randy, good to talk to you again! I really appreciate the comments. I was made very aware of my Americanness while working at the KABK.

Trine, I think what you've described is the pretty much what I saw when I was testing several different possibilities, but it looks like that's just the way InDesign operates.

Thanks!

hrant's picture

> I was made very aware of my Americanness while working at the KABK.

Elaborate! :-)

hhp

Syndicate content Syndicate content