Coding osf fractions

Frode Bo Helland's picture

Hi. I’m using this OT code for my fractions, but it returns an error message when I add “zerooldstyle oneoldstyle twooldstyle …” to the numbers class. Any ideas why?

Also, I’m having some trouble figuring out how I can change the slash to a osf specific fraction bar when onum is activated.

feature frac {
@numbers = [ zero one two three four five six seven eight nine ] ;
@numerators = [ zero.numr one.numr two.numr three.numr four.numr five.numr six.numr seven.numr eight.numr nine.numr ] ;
@denominators = [ zero.dnom one.dnom two.dnom three.dnom four.dnom five.dnom six.dnom seven.dnom eight.dnom nine.dnom ] ;
@predenominators = [ slash fraction onehalf onequarter threequarters zero.dnom one.dnom two.dnom three.dnom four.dnom five.dnom six.dnom seven.dnom eight.dnom nine.dnom ] ;

sub one' [slash fraction]' two' by onehalf ;
sub one' [slash fraction]' four' by onequarter ;
sub three' [slash fraction]' four' by threequarters ;

sub @numbers by @numerators ;
sub @predenominators @numerators' by @denominators ;
sub slash by fraction ;
} frac;

Mark Simonson's picture

You could place your onum feature after your frac feature. Then all you have to do is substitute the figures and fraction bar with their onum versions.

Frode Bo Helland's picture

Didn’t even know you could sort them in a different order. Thanks Mark!

Mark Simonson's picture

The order makes a difference, and you can use it to your advantage (or at least need to be aware of the implications). You can change the order (in FontLab) by dragging the features up and down in the list on the left side of the OpenType Panel.

BTW, when you add a new feature, it gets placed just before (above) the currently selected feature. If you know where you want it to go in the list, you can use this to save the step of moving it. Note: You need to hit the "compile" button to get it to stay in this initial spot, otherwise it will get moved to the end when you save. I have no idea why, but that's how it works.

Arno Enslin's picture

@ frode frank

I think, it is a bad idea to substitute "numr fraction dnom" by prebuilt fractions, because the user can’t change the kerning to the fraction anymore.

My code:

@lnum=[zero.fitted one.fitted two.fitted three.fitted four.fitted five.fitted six.fitted seven.fitted eight.fitted nine.fitted];
@onum=[zero one two three four five six seven eight nine];
@t_onum=[zero.taboldstyle one.taboldstyle two.taboldstyle three.taboldstyle four.taboldstyle five.taboldstyle six.taboldstyle seven.taboldstyle eight.taboldstyle nine.taboldstyle];

@numr=[zero.numerator one.numerator two.numerator three.numerator four.numerator five.numerator six.numerator seven.numerator eight.numerator nine.numerator];
@dnom=[zero.denominator one.denominator two.denominator three.denominator four.denominator five.denominator six.denominator seven.denominator eight.denominator nine.denominator];

@prebuilt_frac = [onequarter onehalf threequarters];

feature numr {#G_S_U_B-Tag
lookup NUMR {
sub @onum by @numr;
sub @lnum by @numr;
sub @t_onum by @numr;
sub @t_lnum by @numr;
} numr;

feature dnom {#G_S_U_B-Tag
lookup DNOM {
sub @onum by @dnom;
sub @lnum by @dnom;
sub @t_onum by @dnom;
sub @t_lnum by @dnom;
} dnom;

feature frac {#G_S_U_B-Tag
lookup NUMR;
sub slash by fraction;
#Alternatively to sub slash by fraction
#ignore sub [one.numerator two.numerator three.numerator four.numerator five.numerator six.numerator seven.numerator eight.numerator nine.numerator] slash' zero.numerator;
#sub slash' by fraction;
#sub slash zero.numerator' by question;
sub zero.numerator fraction zero.numerator zero.numerator by perthousand;
sub zero.numerator fraction zero.numerator by percent;
sub [fraction @dnom @prebuilt_frac] @numr' by @dnom;
} frac;

Mark Simonson's picture

Frode, I think your frac code is fine. You can safely leave out the section that forces pre-built fractions to be used if you think users might want to manually kern them.

Mark Simonson's picture

BTW, Tal Lemming has an interesting post about improving the on the usual coding of the frac feature:

Frode Bo Helland's picture

The code isn’t mine. I found it in a discussion on fractions on Typophile (I also found and read Tal’s article via the same thread). It does make sense to not force the pre built fractions. Thank you, Mark and Arno.

If anyone know why I can’t add to the classes, I would be very grateful. I’ll never learn Opentype if I just copy someones code everytime I run into a problem.

eliason's picture

By adding glyphs to the classes are you making it so that the classes that are being substituted have different numbers of glyphs in them? That will cause an error.

Mark Simonson's picture

Right, but what I was saying in my first reply is that you can avoid the whole problem with adding figure variants to the fraction code by putting the frac feature before features like onum, etc. That way, the frac feature only has to deal with the default figures. Adding all the different figure styles to the frac feature would add some unnecessary complexity to the feature code (unless maybe you have fractions with old style figures or something, which I don't think is the case, right?).

Frode Bo Helland's picture

I understood your solution, Mark. I’m just saying this is how I go about learning stuff: Asking “why”. I do have fractions with hybrid figures, but there’s no reason I can’t change them the same way I’m changing the lining figures.

Thanks Craig, that was it.

Syndicate content Syndicate content