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
Hans Hagen pra...@wxs.nl skribis:
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
Barry Schwartz wrote:
Hans Hagen pra...@wxs.nl 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
Barry Schwartz wrote:
Hans Hagen pra...@wxs.nl 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
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
Derek CORDEIRO wrote:
\usemodule[simplefonts]
Question for wolfgang ... do you enable node mode?
in basemode, it might be that ligatures are loaded after smallcaps (and
base mode is static) and then it's the order of features in the font
that determines what happens,
if so, then maybe we
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] [oldstyke] [mode=node]
Hans
Barry Schwartz wrote:
Hans Hagen pra...@wxs.nl 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
On Fri, Sep 18, 2009 at 11:31 PM, Hans Hagen pra...@wxs.nl 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]
Hans Hagen pra...@wxs.nl skribis:
Barry Schwartz wrote:
Hans Hagen pra...@wxs.nl 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
Am 18.09.2009 um 19:57 schrieb Hans Hagen:
Question for wolfgang ... do you enable node mode?
No.
Wolfgang
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist :
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
Hans Hagen pra...@wxs.nl 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
Hans Hagen pra...@wxs.nl 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
14 matches
Mail list logo
