It's almost certainly not you, but Illustrator. The rendering engine and underlying font engine is shared across all the major Adobe apps, but the text engine is not (though Illustrator and Photoshop do share their text engine), and there's where the problem lies.

We don't have anything like this in-house to test with. If you'd be willing to share the font along with a description of the problem, I can pass it on to the relevant engineers. With any luck we could get this fixed for a future version of the Creative Suite.

Regards,

T

Thanks Thomas for your swift response. It's very easy to reproduce this kind of behaviour without sending you my bunch of code (which I'm willing to send of course). Just put any kind of positioning lookup in the frac feature and it will be ignored by Illustrator.

thanks again
Paul

Are you building this with FontLab, or with VOLT?

T

I build all my fonts with Fontlab. By the way, is it fair to say that the type rendering engine of InDesign is more sophisticated/up-to-date than Illustrator's or is that an oversimplification?

Paul

Paul Dieterman

Please, show the source code of it your feature.

Thanks

I've done the same thing.
I optimized for InDesign.

The problem I have with Illustrator is that in order to position the superior figure, bar(s), and inferior figure on the same vertical axis, I've given my horizontal bar(s) negative sidebearings, and while InDesign recognizes them on both sides, Illustrator appears not to recognize the right-side negative sidebearing -- so I'm contemplating closing up the space between figure and bar by kerning instead.
But perhaps I will not bother, as I don't believe that Illustrator users have any need of fractions.

Quark 7 offers "fraction" in its OpenType menu, but it is not the correct "Fraction" feature: rather, it is a "hack" using the numerator, fraction slash (virgule) and denominator features.

I think it may be possible to achieve consistency across the applications by replacing the angled virgule with a horizontal bar, making superiors and numerators identical, and inferiors and denominators identical, and positioning the fraction elements by kerning -- although the kerning support of OpenType fonts in the beta of Quark 7 is incomplete.

Nick, would you be willing to throw a misbehaving font my way? I'd love to see this fixed in some future version of Illustrator....

T

I don't use any sidebearings within the horizontal bars, I just apply some very hefty kerning to the glyphs, with the following result in InDesign:

In Illustrator (or Photoshop) the result is as follows:

Nick, do you kern the bar under the numerator and use negative sidebearings?

Paul

Wow, looks nice.

What the XPress 7 frac feature does is exactly what the specs say. So literally, this is not "hack" but "the right thing". But nicely indicates that specs are a bit behind real-world development.

... although the kerning support of OpenType fonts in the beta of Quark 7 is incomplete.

There are always applications which don't support things correctly. Making OpenType fonts either means: including the nice things which specs promised, or: making fonts that work in a majority of applications. If anyone knows how to do both, please let me know. :)

More and more I am convinced that trying to get fonts right is one thing. Another one would be to tell application developers explicitly what they shall do with all the information they can find in OpenType fonts! Like, we find the entire history of digital type represented in a collection of font name entries, or three sets of vertical metrics values, or a strange numeric weight value which is even used by apps which otherwise read legacy family/style name (with the nice effect that weight value must be set "wrongly" [specs p.o.v.] so that they work "right" [applications' p.o.v.], or style linking doesn't work) &c ... And there isn't a chance to get rid of some of these information if fonts shall be backward compatible. Which also means that most likely -- because information are there -- even future apps may make use of them.

There's a growing sentiment in much of the OpenType community that all layout features should be free to use all lookup types, as needed.

A lot of this other stuff is indeed arcane and horrible, from a font developer's POV.

T

Contextual kerning would have made my font a lot easier to make...
It's a pity indeed we have to develop fonts with the limitations of the target applications in our minds while the specs promise so much more.

Paul

Thomas, I will send you the font.
Paul, I haven't used kerning within the fraction (i.e. on either side of the horizontal bar).
But I have added a little positive kerning between the full size figures and the superior figures, otherwise the fractions are too close to preceding full-size figures.

When I noticed that Nick Shinn said, "I don’t believe that Illustrator users have any need of fractions.", I wanted to respond with a plea that some of us need all the power for setting mathematical expressions you can give us in both Illustrator and Indesign! Please consider that any mathematical expression an author/scientist might want to write in a figure for a journal article or book needs to be doable in Illustrator so that it looks good when put in InDesign.

As another example, in Indesign I figured out how to insert multiple non-breaking white spaces each with negative kerning to write a Greek word with both a superscript and a subscript that start at the same position. (The text contains 139,000 Greek words, each with a id superscript and a separate id subscript).

From comments I have seen others also are struggling with math expressions in text (InDesign) and figures (Illustrator) even when we buy math plugins.

What the XPress 7 frac feature does is exactly what the specs say.

I think QuarkXPress violates the specification, because it ignores the following rule:

When the full sequence is found in the frac coverage table, the application passes the sequence to the frac table and gets a new GID in return.

Instead of that it directly assumes case two:

When the frac table does not contain an exact match, the application performs two steps. First, it uses the numr feature (see below) to replace figures (as used in the numr coverage table) preceding the slash with numerators, and to replace the typographic slash character (U+002F) with the fraction slash character (U+2044). Second, it uses the dnom feature (see below) to replace all remaining figures (as listed in the dnom coverage table) with denominators.

Maybe the problem can be solved by a hack. (At least the slash can be substituted in the numerator feature. And then it will not be automatically replaced by QuarkXPress.)

At first QuarkXPress seems to check, if a string "figure slash figure" is present in the text for which the fraction feature shall be applied. And then it goes to the numerator feature. If the slash is not substituted there, Quark replaces the slash automatically, before the substitutions embedded in the frac feature can be applied. So "sub slash by fraction.alt" is ignored in the frac feature, because the slash already was replaced by the fraction.

I did make a quick test only. I may be wrong. And in cases, where you have a string of a prebuilt fraction followed by a number, Quark is not replacing anything, because the slash is missing in the string. This problem could maybe solved by integrating a multiple substitution like "sub onequarter by one.numerator slash four.denominator" in the numerator feature. But I did not check that.

.