Re: [NTG-context] Ligatures in EB Garamond
Hi Jan, hi Hans,
This is the developer of EB Garamond. I’m only now and then reading this
list so I only learnt about your troubles now.
The way the ligatures are composed simplifies the creation of more
ligatures after the same scheme while not blowing up the font by having
to create one glyph per ligature combination but only one per component.
In fact, it’s not just kerning, like Hans said, but one-by-one glyph
substitutions. It might be seen as inconsistency that one feature can be
executed in different ways. I know of that problem but it’s not that
inconsistent at user level if you use the methods intended by unicode
and opentype to deal with breaking up ligatures. The symbol ZWNJ (zero
width non joiner) is exactly meant to do this so if you insert it, you
should get what you want. What’s more, by inserting ZWNJ you should also
be able to benefit from kerning between the non ligated f and the
following letter or from contextual alternate forms that fit better than
the long bowed f, if you want that. With EB Garamond, this should be
true for both, engines that handle ZWNJ correctly or not.
By the way, the newly standardized German keyboard layout even has the
ZWNJ on it and the norm recommends its use to prevent ligation.
Best regards
Georg Duffner
Am 18.01.2016 um 11:09 schrieb Hans Hagen:
> On 1/18/2016 10:16 AM, Jan U. Hasecke wrote:
>> Am 17.01.2016 um 20:05 schrieb Hans Hagen:
>>> On 1/16/2016 3:58 PM, Jan U. Hasecke wrote:
>>>> Am 16.01.2016 um 13:31 schrieb Schmitz Thomas A.:
>>>>>
>>>>> Please provide a minimal example of your problem. It’s impossible to
>>>>> help when we have no clue what you’re doing.
>>>>
>>>> Sorry, of course.
>>>>
>>>> After setting up a mwe I found that it is a font related issue.
>>>>
>>>> When I don't specify a font, it works. --> example.tex
>>>>
>>>> When I choose EB Garamond, it does not work. -- example-Garamond.tex
>>>>
>>>> I confirmed this behaviour in my real setup.
>>>
>>> don't assume that ligatures are always real ligatures ... in that font
>>> it's just kerning .. this kind of works okay:
>>>
>>> \replaceword[sellig][auflösen][auf{-}{}{\zwnj}lösen]
>>
>> I am confused as the specimen of EB Garamond mentions (real) ligatures.
>> They are listed as glyphs.
>>
>> https://github.com/georgd/EB-Garamond/blob/master/specimen/Specimen.pdf
>
> maybe the archaic st ligature is a precomposed but f f l i aren't done
> that way but by either kerning or replacement of individual glyphs +
> kerning (there are many methods for this) ... also, 'liga' might mean
> ligature but in practice is used for all kind of things ... in opentype
> 'ligature substitution' is just a many-to-one replacement but that
> doesn't mean that 'liga' uses that ... welcome to the inconsistent open
> type mess
>
Mh, yes. :-(
Two additional questions. Shall I file a bugreport for this issue? What
would be the right words: please provide real ligature glyphs instead of
composed ones?
EB Garamond is a free font also in the sense free of charge. But what
can I expect when I buy a commercial font? I would be quite annoyed when
I buy a font which does not provide the features in a way that I can use
them in ConTeXt.
Is there a font quality page on the Wiki with a feature comparison?
juh
--
EB Garamond: http://www.georgduffner.at/ebgaramond
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
[NTG-context] Bug with complex contextual opentype feature
Hello All,
I’ve recently been experimenting with contextual features in EB Garamond
and LuaTeX’s output is puzzling. As a showcase, I tried to implement the
famous TeX logos with opentype. This is realized in a feature xtex
with GSUB and GPOS lookup tables for substituting some glyphs and for
positioning them horizontally and vertically:
# OT feature code for TeX logos
lookup xtex_sub1 {
sub X e' T e X by e.xtex2; # e.xtex2 is a reversed copy of E
sub X e' L a T e X by e.xtex2;
sub L a' T e X by a.sc;
sub T e' X by e.xtex1; # e.xtex1 is a copy of E
sub L a.sc T e.xtex1 X [two two.lnum two.taboldstyle two.tablining]
e' by e.xtex3; # e.xtex3 is a copy of epsilon
} xtex_sub1;
lookup xtex_pos1 {
pos X e.xtex2' -130 -180 -320 0 T;
pos X e.xtex2' -130 -180 -200 0 L;
pos X [two two.lnum two.taboldstyle two.tablining] e.xtex3' 0 -180
0 0;
pos L a.sc' -330 210 -490 0 T e.xtex1 X;
pos T e.xtex1' -180 -180 -280 0 X;
}xtex_pos1;
feature xtex {
lookup xtex_sub1;
lookup xtex_pos1;
} xtex;
#
LuaTeX only processes the sequence XeTeX where it substitutes the
first e by e.xtex1 instead of e.xtex2. Then it positions it with
respect to X but not to T. All the other parts of the lookups are
ignored as well. The font file can be downloaded from
http://www.georgduffner.at/ebgaramond/fonts/EBGaramond12-Regular.otf.
The expected output can be seen at the bottom of this page:
http://www.georgduffner.at/ebgaramond/design.html with Firefox and
Chrome/Chromium and in the attached screenshot (from SortsmillEditor).
Like the browsers, XeLaTeX’s output is correct. My LuaTeX and ConTeXt
versions are:
This is LuaTeX, Version beta-0.79.1 (TeX Live 2014/dev) (rev 4972)
ConTeXt ver: 2014.07.17 13:24 MKIV beta fmt: 2014.7.17 int:
english/english
% ConTeXt test
\definefontfeature[xtex] [default][xtex=yes]
\definefontsynonym[ebg][file:EBGaramond12-Regular.otf]
\def\sample{XeTeX LuaLaTeX XeLaTeX TeX LaTeX2e}
\definefontfeature
[experiment]
[default]
[xtex=yes]
\usemodule[fnt-20]
\usemodule[art-01]
\setupbodyfont[dejavu]
\starttext
\startTEXpage
\hbox{{\definedfont[ebg*defaultat 12pt]\sample}
{\definedfont[ebg*default at 12pt]\sample}}\par
\hbox{{\definedfont[ebg*xtex at 12pt]\sample}
{\definedfont[ebg*default at 12pt]\feature[+][xtex]\sample}}\par
\stopTEXpage
\def\sample{XeTeX LuaLaTeX XeLaTeX TeX LaTeX2e}
\setvariables
[otftracker]
[font=file:EBGaramond12-Regular.otf,
size=24pt,
features=experiment,
title=Feature Check,
sample=\sample]
\stoptext
%
Best regards,
Georg
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
Re: [NTG-context] Auto selecting optical sizes for a font
Am 2013-06-24 10:27, schrieb Keith J. Schultz: as such ConTexT should support the use of the size table in its font handling, but as Hans has mentioned design sizes a very special and few actually know what that information means and put it to a useful purpose. Question would be in far this font feature should be rudimentarily supported. IMO, they should be fully supported. There are not so many fonts with that property and even less in the free software world, so one can assume that somebody possessing such font knows what that means and probably expects its support. I think, context should by default use the appropriate font for each font-size corresponding to the design range defined in the font’s table, while providing an interface to override that automatism. Best regards, Georg ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] Auto selecting optical sizes for a font
Am 22.06.2013 16:57, schrieb Hans Hagen: We have no feature 'size' (or I must have forgotten about it). As there is no consistency in designsizes and there is always some esthetic choice involved no automatic mechanism is (and will be) build in. Hi, There is a 'size' table in opentype fonts which contains informations about the design size, the design range and a style-ID and -name. Fonts that come with different optical sizes do in fact use that table exactly for the purpose desired by Andrés. Latin Modern does so, Adobe fonts do so and EB Garamond happens to use that table too. XeLaTeX and LuaLaTeX interpret it correctly (by means of fontspec, IIRC). So perhaps it’s worth reconsidering this. Best regards, Georg ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] font trickery
Am 15.05.2013 00:51, schrieb Idris Samawi Hamid ادريس سماوي حامد: Hi Hans, On Tue, 14 May 2013 12:01:36 -0600, Hans Hagen pra...@wxs.nl wrote: I'm on-and-off working on the more technical font manual and in the process also check some old code i've laying around (deciding on what to include and not). I'm also revising the tracer styles. Which makes me wonder: are there specific additional features that one would like to see in context (mkiv only of course) with respect to font support? This may be beyond the scope of your current plans, but worth considering: It would be nice to have a mechanism where we can override/add opentype gsub and gpos features. Early on in the history of luatex we once had a mechanism that did this using FontForge's version of Adobe Feature Files. From what I understand, the AFF syntax is finally mature and supports all lookup types: http://www.adobe.com/devnet/opentype/afdko/topic_feature_file_syntax.html Or maybe we have our own syntax in lua, goodies etc. Anyway, a way to control/override opentype gsub and gpos behavior would be interesting. Even if a total controller is too ambitious/unwieldy, just being able to do a few basic gsub/gpos tricks may be useful for, e.g., bugs in the font. Anyway, something to think about. Best wishes Idris Hi Idris and Hans, this is a great idea. Is this not available any longer in current luatex? The fontspec (xelatex+lualatex) manual lists this as a luatex only feature (I’ve used it once some time ago). I know a lot of fonts and other problems that could be fixed this way. I’d prefer to stay with the AFF syntax which is well established. Best regards, Georg ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] LuaTeX has troubles with contextual kern
Hi,
Am 2013-04-24 12:46, schrieb Hans Hagen:
On 4/24/2013 11:07 AM, Georg Duffner wrote:
Hi,
in EB Garamond I have some contextual lookups in the kern feature with
which LuaTeX in context standalone (updated today in the morning) seems
to have problems (the issue is not new, I’ve already reported it in
january but perhaps that was a bit too confusing).
The test document is:
\definefontfeature[default][default][mode=base]
you want node mode, so mode=node
I'm sorry, I forgot to mention it, I’ve already tested with mode=node,
the result is exactly the same.
\definefontsynonym[ebg][file:EBGaramond12-Regular.otf]
\definefontfeature[ss20][ss20=yes]
\definefontfeature[iota1][cv81=1]
\definefontfeature[iota2][cv81=2]
\definefontfeature[altcirc][cv80=1]
\define\test{Tì αᾟα\par}
\starttext
\definedfont[ebg*default at 12pt]\test
\addfeature{ss20}\test
\addfeature{iota1}\test
\addfeature{iota2}\test
\addfeature{altcirc}\test
\stoptext
The font is at
http://www.georgduffner.at/ebgaramond/fonts/EBGaramond12-Regular.otf
The corresponding lookups in the kern.fea roughly contain
pos T' 145 i.dotless gravecomb;
which increases the right sidebearing of T by 145 before i.dotless
followed by gravecomb
maybe you also need to enable lfbd and rtbd?
lfbd and rtbd don’t make sense here, they are meant to by activated by
opbd and only should affect left and right line-ends. They are the
Opentype equivalents to protrusion settings. This is about simple
kerning in the text (btw, there are experimental lfbd and rtbd settings
in the font). This example is a standard kerning lookup (cf.
http://www.adobe.com/devnet/opentype/afdko/topic_feature_file_syntax.html#6.a
http://www.adobe.com/devnet/opentype/afdko/topic_feature_file_syntax.html#6.h
and http://glyphsapp.com/blog/contextual-kerning/ )
and
pos Eta' 218 0 218 0 uni0345.cap @grk_tlAcc2;
pos Eta' 218 0 418 0 uni0345.cap1 @grk_tlAcc2;
pos Eta' 218 0 558 0 uni0345.cap2 @grk_tlAcc2;
where @grk_tlAcc2 contains the accents attached at the top left of the
glyph and which means that Eta is positioned at 218 inside its bounding
box and the bounding box is expanded by the third value between , on
the condition that it’s followed by uni0345.cap* and the said accents.
ok, so that is effectively changing the advance width
Yes.
ss20 does a full decomposition of all composed glyphs so I can replace
any component by an alternate glyph. Their order corresponds to
canonical decomposition.
Attached you find the pdf output and a pdf from a parallel xelatex test
which shows the desired result:
\documentclass[12pt]{minimal}
\usepackage{fontspec}
\setmainfont{EB Garamond}
\newcommand{\test}{Tì αᾟα\par}
\begin{document}
\test
\addfontfeature{RawFeature=+ss20}\test
\addfontfeature{CharacterVariant=81:1}\test
\addfontfeature{CharacterVariant=81:2}\test
\addfontfeature{CharacterVariant=80}\test
\end{document}
I don't know what \addfontfeature does in xetex (probably accumulative)
but in context you can best use the \feature command: \feature[+][iota1]
as \addfeature cum suis were somewhat experimental features related to
oriental tex.
I’m a bit confused. As I don’t use context yet (this time I did for
reporting a bug upon which I stumbled when using lualatex) I looked up
the necessary commands in the newly presented Fonts out of ConTeXt
where on p. 41 the commands \addfeature and \subtractfeature are used.
In xelatex, \addfontfeature is defined by the package fontspec and does
indeed accumulate features (much like I thought, \addfeature does in
context) but without the need to be defined in the preamble and without
the advantage to define feature sets.
Best regards,
Georg
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
[NTG-context] LuaTeX has troubles with contextual kern
Hi,
in EB Garamond I have some contextual lookups in the kern feature with
which LuaTeX in context standalone (updated today in the morning) seems
to have problems (the issue is not new, I’ve already reported it in
january but perhaps that was a bit too confusing).
The test document is:
\definefontfeature[default][default][mode=base]
\definefontsynonym[ebg][file:EBGaramond12-Regular.otf]
\definefontfeature[ss20][ss20=yes]
\definefontfeature[iota1][cv81=1]
\definefontfeature[iota2][cv81=2]
\definefontfeature[altcirc][cv80=1]
\define\test{Tì αᾟα\par}
\starttext
\definedfont[ebg*default at 12pt]\test
\addfeature{ss20}\test
\addfeature{iota1}\test
\addfeature{iota2}\test
\addfeature{altcirc}\test
\stoptext
The font is at
http://www.georgduffner.at/ebgaramond/fonts/EBGaramond12-Regular.otf
The corresponding lookups in the kern.fea roughly contain
pos T' 145 i.dotless gravecomb;
which increases the right sidebearing of T by 145 before i.dotless
followed by gravecomb
and
pos Eta' 218 0 218 0 uni0345.cap @grk_tlAcc2;
pos Eta' 218 0 418 0 uni0345.cap1 @grk_tlAcc2;
pos Eta' 218 0 558 0 uni0345.cap2 @grk_tlAcc2;
where @grk_tlAcc2 contains the accents attached at the top left of the
glyph and which means that Eta is positioned at 218 inside its bounding
box and the bounding box is expanded by the third value between , on
the condition that it’s followed by uni0345.cap* and the said accents.
ss20 does a full decomposition of all composed glyphs so I can replace
any component by an alternate glyph. Their order corresponds to
canonical decomposition.
Attached you find the pdf output and a pdf from a parallel xelatex test
which shows the desired result:
\documentclass[12pt]{minimal}
\usepackage{fontspec}
\setmainfont{EB Garamond}
\newcommand{\test}{Tì αᾟα\par}
\begin{document}
\test
\addfontfeature{RawFeature=+ss20}\test
\addfontfeature{CharacterVariant=81:1}\test
\addfontfeature{CharacterVariant=81:2}\test
\addfontfeature{CharacterVariant=80}\test
\end{document}
Best regards,
Georg
contextual_kerning.pdf
Description: Adobe PDF document
contextual_kerning_xtx.pdf
Description: Adobe PDF document
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
