On Fri, Sep 18, 2009 at 6:44 PM, Hans Hagen wrote:

Mika Ritola wrote:

...

Hello all,

For some reason, the snippet below outputs 'ThOMAS' instead of 'THOMAS.' This seems to be font dependent; at least Adobe Jenson Pro and Adobe Garamond Pro produce 'Th,' while the other fonts that I've tried produce 'TH', as expected. I don't know whether the bug exists in the fonts themselves or in the way they are handled by ConTeXt or the Simplefonts module, or possibly some other part of the system. In any case, could you suggest a work-around, please?

I'm using ConText version 2009.09.16 20:07 and Simplefonts version 2009.09.15.

\usemodule[simplefonts] \setmainfont[Adobe Jenson Pro]

\starttext {\sc Thomas} \stoptext

That does not work for me at all. The following does work with generating the same ThOMAS \usemodule[simplefonts] \setmainfont[A Jenson Pro Regular] \starttext {\sc Thomas} \stoptext

could it be a bug in the font? i.e. a Th ligature showing up in smallcaps? if so, then simplefonts should disable ligatures in smallcaps

I doubt it is a font bug as the following plain luatex works. \font\body=file:AJensonPro-Regular:mode=node;script=latn;language=dflt;+liga;+dlig;+smcp at 12pt \body Thomas \bye

On Fri, Sep 18, 2009 at 11:24 PM, Hans Hagen wrote:

Derek CORDEIRO wrote:

That does not work for me at all. The following does work with generating

...

the same ThOMAS

can you try ..

\definefontfeature[smallcaps][smallcaps][liga=no]

\usemodule[simplefonts]

\setmainfont[A Jenson Pro Regular]

\starttext {\sc Thomas} \stoptext

if that works, then the font is bugged

Yes it does work, I guess the font has bugs after all. Regards, Derek

Barry Schwartz wrote:

If base mode uses the traditional TeX mechanism for ligatures, I don't see any way the font can be blamed.

sure Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

Barry Schwartz wrote:

Hans Hagen skribis:

...

Barry Schwartz wrote:

...

If base mode uses the traditional TeX mechanism for ligatures, I don't see any way the font can be blamed.

Ant does the same thing, I believe, using the OT tables and heuristics to run the TeX processor. That's okay, as long as the results aren't blamed on the font. :)

well, that's alway sa bit hard to determine, maybe not in this case but there definitely are dubious cases and heuristics that works in one case migh tfail in another; also, as context base mode is mostly meant for simple cases (and as said, it might be wise in the case of snallcaps to not enable ligatures) and therefore suits most cases, but as reference (and for more advanced work) node mode has to be used ... actually, when users report bugs with fonts i kind of assume node mode in the perspective of the oriental tex project (related to luatex/mkiv) a complex font is being made and quite some time goes into figuring out what exactly the common ground in ot is (we've decided to settle for uniscribe/volt for final decisions as that's the most advanced machinery) for instance there are more combinations possible on otf than the font generating programs can handle and some combinations are only handled by some renderers. of course the mkiv machinery can be blamed for much, but so can the specification itself, the font generating tools as wel as fonts the best we can do is to try to deal with all but eventually i think that i'll end up with a couple of extra features / checks / etc; there's also already a patch mechanism in place having more advanced fonts is nice, but unfortunately (for commercial reasons, or for stability reasons or ...) font vendors have no real bug fix and upgrade policy but at least i can fix my own bugs -) btw, in most cases it helps to nail down problems when we have the font, which not always is the case, so in such cases we might need to gamble where the problem sits Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

Am 18.09.2009 um 19:57 schrieb Hans Hagen:

Question for wolfgang ... do you enable node mode?

No. Wolfgang

On Fri, Sep 18, 2009 at 11:31 PM, Hans Hagen wrote:

Derek CORDEIRO wrote:

That does not work for me at all. The following does work with generating

...

the same ThOMAS

another test:

\definefontfeature[default] [default] [mode=node] \definefontfeature[smallcaps][smallcaps][mode=node] \definefontfeature[oldstyle] [oldstyle] [mode=node]

This works well too. Regards, Derek

Barry Schwartz wrote:

Hans Hagen skribis:

...

could it be a bug in the font? i.e. a Th ligature showing up in smallcaps? if so, then simplefonts should disable ligatures in smallcaps

I'm looking at AGaramondPro-Regular in fontforge and it has the lookup for small caps well above the lookup for ligatures. The software must be reading the lookup table out of order.

no, it's just that basemode gets two features and replacement and ligatures are both applied due to the definition of the smallcaps featureset, so it's expected behaviour - either adapt the definition of the smallcaps featureset (i'll do that in the next beta) - or switch to nodemode (in your case nodemode applies smallcaps before ligatures) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

Barry Schwartz wrote:

The font is unambiguous about it, though. Are you sure the software isn't performing the feature list in order rather than lookup list? Or is the software performing substitutions in its own ad hoc order?

in basemode we use built in traditional tex methods, so only ligatures and kerning; as a bonus i also support replacements, but in base mode the user really has to know what he/she asks for; in thsi particular case, asking for both ligatures (not contextual btw) and repacements (smsc) one gets them combined so, this is why there is (the somewhat slower but more conforming) node mode as well; in that case (contextual) lookups are taken care of but even then, if a font is not clear about issues, then one can get unwanted side effects (the frac feature for instance is often quite bugged and can only be applied selectively) also, in context mkiv we have variants like dynamic features, user defined features, strategies etc (after all, nothing can stop us from doing a better job)

Now I _make_ opentype fonts with small caps and ligatures and so want the software to do what I tell it (except when it was I who made the error). :)

well, as said ... base mode has some known limitations and if you want the whole lot, you should use node mode (fyi: apart from isolated features we also support mixtures; the open type font format makes no assumptions about tags and gpos/gsub application so for instance the smallcaps feature might use one-to-one subsititutions as well as any other kind and complex fonts (like idris arabic font) does that) (maybe simplefonts should default to node mode) Hans ps. if you run (as i demonstrated at the eurotex/context conference) mtxrun --script server --auto you can access an interactive features tester in your webbrouwser there is also a trace option there where you can see what happens (in node mode) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

Barry Schwartz wrote:

Hans Hagen skribis:

...

but even then, if a font is not clear about issues, then one can get unwanted side effects (the frac feature for instance is often quite bugged and can only be applied selectively)

Yeah, I think trying to be fancy with contextual substitutions is a bit like getting drunk. I'm not even sure why there was a "frac" tag when it was originally intended to be converted to "numr" and "dnom" tags.

(I just looked at http://www.microsoft.com/typography/otspec160/features_fj.htm#frac to see what it says nowadays and now want to go get drunk.)

actually the frac featurs, like most features is a rather generic one and as such it should work out of the box (some of the justitication features use gpos and/or assume specific renderer support, and some of that is rather undefined) so, its not that frac itself is the problem dealing with in the engine, because if so, many features would be a problem, it's just that font makers stick to a couple of simple rules like: (1) replace all <digits> <slash> <digits> by <sup digits> <overlapping frac slash> <sub digits> (1) replace all <digits> <slash> <digits> by <sup digits> <overlapping frac slash> <sub digits> and if they have rule 2, it will mess up things like a/b of course it can be properly dealt with ... just make proper rules now, one reason that metafont kind of design tools never were accepted as basic tool for font design is that designers are no programmers; and one needs programmers (or at least some of the related mindset) to make the more complex ot fonts (or one needs teams) actually, as many fonts do have the sup/sub digits its rather trivial to provide proper frac's in mkiv but till now i had no reason (time, project, etc) for doing it i fear the moment when designers start giving me rules like "use this or that font and turn on those features" assuming dtp like control and tweaking of the text (one reason for spending much time on fonts in mkiv is that it will give me control over bad behaving fonts; think of wrong glyph to unicode mapping and such) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

Barry Schwartz wrote:

Are there fonts that have a or b in the "numr" and "dnom" features but where they do not work in "frac"?

that is unrelated, the replacement rules refer to glyphs an doften they stick to digits so you get a/b with a large a and b and the fractional slash which then gives an ugly overlap Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------