'kern': TrueType table and GPOS lookup feature

Pablo Rodríguez

30 Nov 2012 30 Nov '12

12:06 a.m.

Hi there, sorry for bothering again with this issue, but I need to be sure in order to properly report to the font developer of FreeSerif. I have the following file: \usemodule[simplefonts][size=25pt] \definefontfeature[latins][default][script=latn] \setmainfont[FreeSerif] \starttext \showfontkerns dadedidodufafefifofufrflftlalelilolutatetitotu\par \addfs{latins} dadedidodufafefifofufrflftlalelilolutatetitotu\par \stoptext The first line has no GPOS kern enabled and the second line has it. In order to report it to the font developer (I have the problem not with ConTeXt, but with my ereader [I used ConTeXt to check the font features), I have the following questions: -In the example above, is the old TrueType kern enabled on the first line? -If not, how can I enable it, without enabling the liga or kern OpenType features? I need this to see the actual kerning form the old TrueType kern table (I suspect it hasn't the same values as the OpenType kern feature). Many thanks for your help, Pablo -- http://www.ousia.tk

Show replies by thread

Hans Hagen

30 Nov 30 Nov

2:13 a.m.

On 11/30/2012 8:06 AM, Pablo Rodríguez wrote:

...

Hi there,

sorry for bothering again with this issue, but I need to be sure in order to properly report to the font developer of FreeSerif.

I have the following file:

\usemodule[simplefonts][size=25pt] \definefontfeature[latins][default][script=latn] \setmainfont[FreeSerif] \starttext \showfontkerns dadedidodufafefifofufrflftlalelilolutatetitotu\par \addfs{latins} dadedidodufafefifofufrflftlalelilolutatetitotu\par \stoptext

The first line has no GPOS kern enabled and the second line has it.

In order to report it to the font developer (I have the problem not with ConTeXt, but with my ereader [I used ConTeXt to check the font features), I have the following questions:

-In the example above, is the old TrueType kern enabled on the first line?

-If not, how can I enable it, without enabling the liga or kern OpenType features?

I need this to see the actual kerning form the old TrueType kern table (I suspect it hasn't the same values as the OpenType kern feature).

We don't really make a distinction. Kerns are either a property of a character (truetype method) or are organized as lookups. Both are driven by 'kern' and it's not possible to choose a specific method as it's font driven. In the first case, enabling the kern feature will also enable the kerns and there is no dependency on language and script. In the second case a language script combination drives the injection of kerns. So, for each combination there can be different kerns (won't happen often). Now, if a font designer decides to group kerns according to languages (makes less sense than for instance grouping ligatures which do have a dependency on languages) he/she has to make sure that it's done in such a way that it doesn't lock out. For instance, you can have kerns (optionally in your font organized in classes) that kerns latin characters and group them in latn/dflt and do something similar for latn/<anylanguage> but then you expect the user to choose the right combination. So, choosing latn/dflt can lock out greek or whatever. This means that when one defines kerns for say devanagari but also wants to have mixed in latin/* scripts supported, one could best also enable latn/* kerns there (just add lookups to the feature specification). As the serif font you use has support for many scripts, extra care has to be taken for mixed usage. Also, normally a dflt/dflt combination is defined (read: no script or language chosen) which should work out okay for most cases. Anyhow, in the serif font (1) a dflt/dflt combination has to be supported (added) and (2) you/someone needs to check if when you choose greek, you still got kerning for latin. Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

Steve White

2:58 a.m.

Hi Hans, Pablo, et al. I'm the admin of GNU FreeFont. I'll respond to some of these points. 1) I have yet to reproduce Pablo's output PDF on either of two systems. As I am unfamiliar with ConTeXt, I can only guess how it was built. I tried the file quoted here as input to the 'context' command, but it chokes on the \showfontkerns line. It would help very much to have a working example with the proper command line to build it. 2) I understood that ConTeXt only uses the old-style TrueType 'kern' table, rather than the OpenType 'kern' GPOS lookup. If that is the case, I would suggest that you consider to change the logic to first use the OpenType lookup, and if it doesn't exist, fall back to the TrueType table. Several applications are already complaining that both exist; the plan is to drop support for the TrueType table in FreeFont. 3) In most applications, the script of a run of text is determined from the Unicode. This is the assumption made in FreeFont. The GNU FreeFont policy starts from its essence as a Unicode font, in which no particular script is default. (Some generic features that are not specific to any script, are in {dflt,dflt}.) There was a suggestion that Latin kerns should be activated by {script,lang}={dflt,dflt}. Let me ask, should Devanagari kerns also be activated by {dflt, dflt}? If not, why? It appears that there maybe some conflict her with TeX implementaions. I don't completely understand this. Maybe we can find a solution. 4) I have written something like Pablo's test using XeTeX and fontspec. Kerning works very well with GNU FreeFont. Find attached. 5) There was also a report that OpenType kerning doesn't work in some E-Book readers (I know this isn't the forum for that, but ...) . My iriver Story kerns very nicely text in FreeSerif. Can I get an example of an E-reader for which kerning fails? (I really don't doubt that they exist!) Cheers! On Fri, Nov 30, 2012 at 10:13 AM, Hans Hagen wrote:

...

On 11/30/2012 8:06 AM, Pablo Rodríguez wrote:

...
Hi there,

sorry for bothering again with this issue, but I need to be sure in order to properly report to the font developer of FreeSerif.

I have the following file:

\usemodule[simplefonts][size=**25pt] \definefontfeature[latins][**default][script=latn] \setmainfont[FreeSerif] \starttext \showfontkerns dadedidodufafefifofufrflftlale**lilolutatetitotu\par \addfs{latins} dadedidodufafefifofufrflftlale**lilolutatetitotu\par \stoptext

The first line has no GPOS kern enabled and the second line has it.

In order to report it to the font developer (I have the problem not with ConTeXt, but with my ereader [I used ConTeXt to check the font features), I have the following questions:

-In the example above, is the old TrueType kern enabled on the first line?

-If not, how can I enable it, without enabling the liga or kern OpenType features?

I need this to see the actual kerning form the old TrueType kern table (I suspect it hasn't the same values as the OpenType kern feature).

We don't really make a distinction. Kerns are either a property of a character (truetype method) or are organized as lookups. Both are driven by 'kern' and it's not possible to choose a specific method as it's font driven. In the first case, enabling the kern feature will also enable the kerns and there is no dependency on language and script. In the second case a language script combination drives the injection of kerns. So, for each combination there can be different kerns (won't happen often).

Now, if a font designer decides to group kerns according to languages (makes less sense than for instance grouping ligatures which do have a dependency on languages) he/she has to make sure that it's done in such a way that it doesn't lock out.

For instance, you can have kerns (optionally in your font organized in classes) that kerns latin characters and group them in latn/dflt and do something similar for latn/<anylanguage> but then you expect the user to choose the right combination. So, choosing latn/dflt can lock out greek or whatever. This means that when one defines kerns for say devanagari but also wants to have mixed in latin/* scripts supported, one could best also enable latn/* kerns there (just add lookups to the feature specification).

As the serif font you use has support for many scripts, extra care has to be taken for mixed usage. Also, normally a dflt/dflt combination is defined (read: no script or language chosen) which should work out okay for most cases. Anyhow, in the serif font (1) a dflt/dflt combination has to be supported (added) and (2) you/someone needs to check if when you choose greek, you still got kerning for latin.

Hans

------------------------------**------------------------------**----- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl ------------------------------**------------------------------**----- ______________________________**______________________________** _______________________ 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 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/http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ______________________________**______________________________** _______________________

luigi scarso

3:18 a.m.

On Fri, Nov 30, 2012 at 10:58 AM, Steve White wrote:

...

Hi Hans, Pablo, et al.

I'm the admin of GNU FreeFont. I'll respond to some of these points.

1) I have yet to reproduce Pablo's output PDF on either of two systems. As I am unfamiliar with ConTeXt, I can only guess how it was built. I tried the file quoted here as input to the 'context' command, but it chokes on the \showfontkerns line. It would help very much to have a working example with the proper command line to build it. it's ok with freefont-ttf-20120503.zip and the latest context. You can install it from http://wiki.contextgarden.net/ConTeXt_Standalone and it's better to put into a separated folder than texlive .

-- luigi

Steve White

4:40 a.m.

Hi Luigi, I am lacking still * a working input (*.tex) file * the command line to build it with ConTeXt There are already two ConTeXt installations on different machines here. The most recent is 2012.05.30 MKIV, on Ubuntu. Are you saying I have to install the latest version of ConTeXt to see the effects being discussed? I see vertical lines in your attached PDF... is this a new complaint? I thought the problem was that sometimes kerning isn't activated. Thanks! On Fri, Nov 30, 2012 at 11:18 AM, luigi scarso wrote:

...

...
Hi Hans, Pablo, et al.

I'm the admin of GNU FreeFont. I'll respond to some of these points.

1) I have yet to reproduce Pablo's output PDF on either of two systems. As I am unfamiliar with ConTeXt, I can only guess how it was built. I tried the file quoted here as input to the 'context' command, but it chokes on

On Fri, Nov 30, 2012 at 10:58 AM, Steve White wrote: the

...
\showfontkerns line. It would help very much to have a working example with the proper command line to build it. it's ok with freefont-ttf-20120503.zip and the latest context. You can install it from http://wiki.contextgarden.net/ConTeXt_Standalone and it's better to put into a separated folder than texlive .

-- luigi

___________________________________________________________________________________ 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

___________________________________________________________________________________

luigi scarso

5:24 a.m.

On Fri, Nov 30, 2012 at 12:40 PM, Steve White wrote:

...

Hi Luigi,

I am lacking still

* a working input (*.tex) file %% test.tex \usemodule[simplefonts][size=25pt] \definefontfeature[latins][default][script=latn] \setmainfont[FreeSerif] \starttext \showfontkerns dadedidodufafefifofufrflftlalelilolutatetitotu\par \addfs{latins} dadedidodufafefifofufrflftlalelilolutatetitotu\par \stoptext

...

* the command line to build it with ConTeXt

$> context test.tex

...

There are already two ConTeXt installations on different machines here. The most recent is 2012.05.30 MKIV, on Ubuntu. Are you saying I have to install the latest version of ConTeXt to see the effects being discussed?

Quick how-to $>## install latest minimals under /opt/luatex/standalone-new $>## and run the test $>mkdir -p /opt/luatex/standalone-new $>cd /opt/luatex/standalone-new $>wget http://minimals.contextgarden.net/setup/first-setup.sh $>bash /first-setup.sh --modules=simplefonts $>## wait a little $>cd tex $>source setuptex $>## ok we shoudl have context mkiv now $>context --version $>cd texmf-project $>mkdir fonts && cd fonts $>wget http://ftp.gnu.org/gnu/freefont/freefont-src-20120503.zip $>unzip freefont-src-20120503.zip $>cd freefont-20120503 $>mv *.ttf ../ $>cd .. $>mtxrun --script font --reload $>## let's see if they are installed $>mtxrun --script fonts --list --all|grep free $>cd .. $>## put the test.tex here $>context test.tex

...

I see vertical lines in your attached PDF... is this a new complaint?

vertical bars are the result of \showkerns

...

I thought the problem was that sometimes kerning isn't activated. could be.

-- luigi

Khaled Hosny

7:13 a.m.

On Fri, Nov 30, 2012 at 10:58:25AM +0100, Steve White wrote:

...

There was a suggestion that Latin kerns should be activated by {script,lang}={dflt,dflt}. Let me ask, should Devanagari kerns also be activated by {dflt, dflt}? If not, why?

My own policy is, unless a feature must be restricted to a specific script/language (e.g. a locale-specific feature), all features should be assigned to *all* scripts in the font, including DFLT/dflt, because there is technical reason for doing otherwise and it would help applications not doing automatic script/language itemisation (both OpenType-enabled TeX engines, for example). Regards, Khaled

Steve White

7:25 a.m.

Hi Luigi, As I said, this example does not produce a PDF file for me. I will attach the output. Undefined control sequence ... ...and it points to \showfontkerns In previous attempts to load a font file directly, I used a command structures something like [file:FreeSerif.otf*default], but these never worked for me either, and you seem to be using some other method. How should one load the file for this example? You didn't answer the question: to investigate this behaviour, must I install a second, newer version of context, or can I use the disro version? What is the reason for installing the latest version of ConTeXt? Is this \showfontkerns only in versions newer than 2012.05.30 11:26 MKIV ? This \showfontkerns may be interesting to me, generally. (So I have a further incentive to get this going!) On Fri, Nov 30, 2012 at 1:24 PM, luigi scarso wrote:

...

On Fri, Nov 30, 2012 at 12:40 PM, Steve White wrote:

...
Hi Luigi,

I am lacking still

* a working input (*.tex) file %% test.tex \usemodule[simplefonts][size=25pt] \definefontfeature[latins][default][script=latn] \setmainfont[FreeSerif] \starttext \showfontkerns dadedidodufafefifofufrflftlalelilolutatetitotu\par \addfs{latins} dadedidodufafefifofufrflftlalelilolutatetitotu\par \stoptext

...
* the command line to build it with ConTeXt

$> context test.tex

...
There are already two ConTeXt installations on different machines here. The most recent is 2012.05.30 MKIV, on Ubuntu. Are you saying I have to install the latest version of ConTeXt to see the effects being discussed?

Quick how-to $>## install latest minimals under /opt/luatex/standalone-new $>## and run the test $>mkdir -p /opt/luatex/standalone-new $>cd /opt/luatex/standalone-new $>wget http://minimals.contextgarden.net/setup/first-setup.sh $>bash /first-setup.sh --modules=simplefonts $>## wait a little $>cd tex $>source setuptex $>## ok we shoudl have context mkiv now $>context --version $>cd texmf-project $>mkdir fonts && cd fonts $>wget http://ftp.gnu.org/gnu/freefont/freefont-src-20120503.zip $>unzip freefont-src-20120503.zip $>cd freefont-20120503 $>mv *.ttf ../ $>cd .. $>mtxrun --script font --reload $>## let's see if they are installed $>mtxrun --script fonts --list --all|grep free $>cd .. $>## put the test.tex here $>context test.tex

...
I see vertical lines in your attached PDF... is this a new complaint?

vertical bars are the result of \showkerns

...
I thought the problem was that sometimes kerning isn't activated. could be.

-- luigi

___________________________________________________________________________________ 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

___________________________________________________________________________________

luigi scarso

8:30 a.m.

On Fri, Nov 30, 2012 at 3:25 PM, Steve White wrote:

...

Hi Luigi,

As I said, this example does not produce a PDF file for me. I will attach the output.

Undefined control sequence ... ...and it points to \showfontkerns

In previous attempts to load a font file directly, I used a command structures something like [file:FreeSerif.otf*default], but these never worked for me either, and you seem to be using some other method. How should one load the file for this example?

You didn't answer the question: to investigate this behaviour, must I install a second, newer version of context, or can I use the disro version? What is the reason for installing the latest version of ConTeXt? Is this \showfontkerns only in versions newer than 2012.05.30 11:26 MKIV ?

...

This \showfontkerns may be interesting to me, generally. (So I have a further incentive to get this going!)

1) install a new version ,as I said in my prev. email under "Quick how-to" 2) save this %% test.tex \usemodule[simplefonts][size=25pt] \definefontfeature[latins][default][script=latn] \setmainfont[FreeSerif] \starttext \showfontkerns dadedidodufafefifofufrflftlalelilolutatetitotu\par \addfs{latins} dadedidodufafefifofufrflftlalelilolutatetitotu\par \stoptext into test.tex, and then see the last lines of "Quick how-to" there are many other details to discover -- luigi

Hans Hagen

8:38 a.m.

On 11/30/2012 4:30 PM, luigi scarso wrote:

...

...
What is the reason for installing the latest version of ConTeXt? Is this \showfontkerns only in versions newer than 2012.05.30 11:26 MKIV ?

in that version it was an add-on module, but in the meantime it's in the core Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

Hans Hagen

8:41 a.m.

On 11/30/2012 3:13 PM, Khaled Hosny wrote:

...

On Fri, Nov 30, 2012 at 10:58:25AM +0100, Steve White wrote:

...
There was a suggestion that Latin kerns should be activated by {script,lang}={dflt,dflt}. Let me ask, should Devanagari kerns also be activated by {dflt, dflt}? If not, why?

My own policy is, unless a feature must be restricted to a specific script/language (e.g. a locale-specific feature), all features should be assigned to *all* scripts in the font, including DFLT/dflt, because there is technical reason for doing otherwise and it would help applications not doing automatic script/language itemisation (both OpenType-enabled TeX engines, for example).

That makes much sense (unless a font has hundreds of different lookups for multiple features which could slow down basic processing). Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

Hans Hagen

8:43 a.m.

On 11/30/2012 12:40 PM, Steve White wrote:

...

I see vertical lines in your attached PDF... is this a new complaint?

that's just the visual debugger in action

...

I thought the problem was that sometimes kerning isn't activated.

indeed (well, it is activated by default but also script/language driven) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

Hans Hagen

9:05 a.m.

On 11/30/2012 10:58 AM, Steve White wrote:

...

2) I understood that ConTeXt only uses the old-style TrueType 'kern' table, rather than the OpenType 'kern' GPOS lookup. If that is the case, I would suggest that you consider to change the logic to first use the OpenType lookup, and if it doesn't exist, fall back to the TrueType table. Several applications are already complaining that both exist; the plan is to drop support for the TrueType table in FreeFont.

I has always supported both but the user does not show the difference.

...

3) In most applications, the script of a run of text is determined from the Unicode. This is the assumption made in FreeFont. The GNU FreeFont policy starts from its essence as a Unicode font, in which no particular script is default. (Some generic features that are not specific to any script, are in {dflt,dflt}.)

There was a suggestion that Latin kerns should be activated by {script,lang}={dflt,dflt}. Let me ask, should Devanagari kerns also be activated by {dflt, dflt}? If not, why?

because one text can contain multiple scripts

...

It appears that there maybe some conflict her with TeX implementaions. I don't completely understand this. Maybe we can find a solution.

If you have context installed and running, you can do this: \usemodule[fnt-20,art-01] \starttext \definefontfeature [freeserif-default] [default] [script=latn] \setvariables [otftracker] [font=file:freeserif.ttf, size=24pt, figure=, features=freeserif-default, title=Feature Check, sample={dadedidodufafefifofufrflftlale}] \setvariables [otftracker] [font=file:freeserif.ttf, size=24pt, figure=, features=freeserif-default, title=Feature Check, sample={lilolutatetitotu}] \stoptext This gives insight in the stepwise processing of features (something that is handy for relatively complex fonts, for instance those dealign with arabic).

...

4) I have written something like Pablo's test using XeTeX and fontspec. Kerning works very well with GNU FreeFont. Find attached.

maybe xetex defaults to latn

...

5) There was also a report that OpenType kerning doesn't work in some E-Book readers (I know this isn't the forum for that, but ...) . My iriver Story kerns very nicely text in FreeSerif. Can I get an example of an E-reader for which kerning fails? (I really don't doubt that they exist!)

Natively I suppose? If a pdf file is viewed on an ebook reader it's not the ereader's issue. Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

Bill Meahan

9:39 a.m.

On 11/30/2012 11:05 AM, Hans Hagen wrote:

...

On 11/30/2012 10:58 AM, Steve White wrote:

...
5) There was also a report that OpenType kerning doesn't work in some E-Book readers (I know this isn't the forum for that, but ...) . My iriver Story kerns very nicely text in FreeSerif. Can I get an example of an E-reader for which kerning fails? (I really don't doubt that they exist!)

Natively I suppose? If a pdf file is viewed on an ebook reader it's not the ereader's issue.

Hans

PDF preserves typography IF the fonts are on the machine or embedded in the document. That includes kerning. EPUB and Kindle are based on XHTML and pay no attention to any typography or kerning set by the creator. The *user* chooses the typeface and line-spacing while the text width is either the width of the screen or the width of the window if run on PC,Mac &al. Any kerning is strictly a function of the E-reader and the particular typeface ("font") chosen by the user. The EPUB3 spec alleviates this somewhat as it allows font embedding. -- Bill Meahan Westland, Michigan USA

Steve White

11:08 a.m.

Hi Hans, Bill, Yes, I'm personally aware of how PDF works. This came from Pablo, who has since told me he was *not* referring to PDF files, but EPUB books. So he is referring to the native font renderer. That's all I know about it, except that kerning works on my own reader. Anyway, this really isn't a question for this forum. On Fri, Nov 30, 2012 at 5:39 PM, Bill Meahan wrote:

...

On 11/30/2012 11:05 AM, Hans Hagen wrote:

...
On 11/30/2012 10:58 AM, Steve White wrote:

5) There was also a report that OpenType kerning doesn't work in some

...
E-Book readers (I know this isn't the forum for that, but ...) . My iriver Story kerns very nicely text in FreeSerif. Can I get an example of an E-reader for which kerning fails? (I really don't doubt that they exist!)

Natively I suppose? If a pdf file is viewed on an ebook reader it's not the ereader's issue.

Hans

PDF preserves typography IF the fonts are on the machine or embedded in the document. That includes kerning.

EPUB and Kindle are based on XHTML and pay no attention to any typography or kerning set by the creator. The *user* chooses the typeface and line-spacing while the text width is either the width of the screen or the width of the window if run on PC,Mac &al. Any kerning is strictly a function of the E-reader and the particular typeface ("font") chosen by the user.

The EPUB3 spec alleviates this somewhat as it allows font embedding.

-- Bill Meahan Westland, Michigan USA

______________________________**______________________________** _______________________ 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 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/http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ______________________________**______________________________** _______________________

Steve White

11:12 a.m.

Hi Hans, On Fri, Nov 30, 2012 at 4:38 PM, Hans Hagen wrote:

...

On 11/30/2012 4:30 PM, luigi scarso wrote:

What is the reason for installing the latest version of ConTeXt? Is this

...
...
\showfontkerns only in versions newer than 2012.05.30 11:26 MKIV ?

in that version it was an add-on module, but in the meantime it's in the core

That would explain part of my problems. If possible, I would like to get the distro version working, before moving to the latest version. Is this add-on module in some Debian package, or must one install it by hand? If the latter, what would be involved? Thanks!

Hans Hagen

11:22 a.m.

On 11/30/2012 7:12 PM, Steve White wrote:

...

Hi Hans,

On Fri, Nov 30, 2012 at 4:38 PM, Hans Hagen mailto:pragma@wxs.nl> wrote:

On 11/30/2012 4:30 PM, luigi scarso wrote:

What is the reason for installing the latest version of ConTeXt? Is this \showfontkerns only in versions newer than 2012.05.30 11:26 MKIV ?

in that version it was an add-on module, but in the meantime it's in the core

That would explain part of my problems.

If possible, I would like to get the distro version working, before moving to the latest version.

Is this add-on module in some Debian package, or must one install it by hand? If the latter, what would be involved?

I think it was part of a set of modules we used for testing (some ended up in the distribution, some didn't) so i fear that you need a recent context; handy anyway, as things might have been improved and I wonder if there are many context users using an old version, given that luatex / mkiv / mplib / gyre fonts are progressing. ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

Steve White

11:34 a.m.

Hi, Hans, Sorry about the accidental post I'm struggling with gmail's new input interface...very hard not to top-post. On Fri, Nov 30, 2012 at 7:15 PM, Steve White wrote:

...

Hi Hans,

On Fri, Nov 30, 2012 at 5:05 PM, Hans Hagen wrote:

...
On 11/30/2012 10:58 AM, Steve White wrote:

3) In most applications, the script of a run of text is determined from

...
the Unicode. This is the assumption made in FreeFont. The GNU FreeFont policy starts from its essence as a Unicode font, in which no particular script is default. (Some generic features that are not specific to any script, are in {dflt,dflt}.)

There was a suggestion that Latin kerns should be activated by {script,lang}={dflt,dflt}. Let me ask, should Devanagari kerns also be activated by {dflt, dflt}? If not, why?

because one text can contain multiple scripts

This is interesting.

There are different notions of text here, depending on point of view. Certainly a sentence could contain a mixture of scripts. When I said "run of text" I meant it from the point of view of how font featues are applied to text. Usually it is a small chunk of text, with chunks separated by white space or other delimiters. In web browsers, etc, if a run of text is, say, from the Armenian Unicode range, the script is judged to be Armenian for the purposes of matching OpenType lookups. (The information of what *language* is meant by the text must be supplied otherwise, in this case, in a 'lang' attribute). Now, you could imgaine applying an OpenType lookup to, say, a Malayalam letter immediately followed by an Arabic letter, but this is .. I think... really pointless. Even in text containing very mixed scripts, at least the words from the different scripts are separated by white space (or other punctuation etc). So the mechanism of determining the "script" of a "run of text" does typically make good sense. That all said: It's not clear to me how this is implemented in ConTeXt. I'll play with it once I have some examples working. My guess is, the author has to explicitly indicate the script each run of text (by specifying the attributes of the font to apply to the run).

Bill Meahan

12:07 p.m.

On 11/30/2012 01:08 PM, Steve White wrote:

...

Hi Hans, Bill,

That's all I know about it, except that kerning works on my own reader.

That's entirely up to the reader. It's nice when the reader does as it's not part of the EPUB2 specification which is what most current systems use. EPUB3 is very new and hasn't been widely implemented yet.

...

Anyway, this really isn't a question for this forum.

Actually, it is. ConTeXt is capable of generating EPUB2 as well as PDF (no conversion program required) so behavior of the entire system is germane. Cheers! -- Bill Meahan Westland, Michigan USA

luigi scarso

12:37 p.m.

On Fri, Nov 30, 2012 at 7:12 PM, Steve White wrote:

...

If possible, I would like to get the distro version working, before moving to the latest version.

...

Is this add-on module in some Debian package, or must one install it by hand? If the latter, what would be involved? no *deb package, as far I know. We usually have the latest context mkiv beta as reference, plus some "current"s. It's quite common that mkiv from texlive is too old (and those ones

hm, hard and useless form the distro too). but it's not a problem because installation is easy. -- luigi

Steve White

2:24 p.m.

Hi On Fri, Nov 30, 2012 at 8:07 PM, Bill Meahan wrote:

...

On 11/30/2012 01:08 PM, Steve White wrote:

...
Hi Hans, Bill,

That's all I know about it, except that kerning works on my own reader.

That's entirely up to the reader. It's nice when the reader does as it's not part of the EPUB2 specification which is what most current systems use. EPUB3 is very new and hasn't been widely implemented yet.

...
Anyway, this really isn't a question for this forum.

Actually, it is. ConTeXt is capable of generating EPUB2 as well as PDF (no conversion program required) so behavior of the entire system is germane

Aha. That throws some light on some things Pablo was saying... I did not know this. I'm interested and want to experiment. I have always made E-Books by hand (well, with vi, and other command-line tools).

Steve White

2:25 p.m.

Luigi, OK, I get it. (I have wasted a couple of hours, it seems.) I'll do as you first recommeded. On Fri, Nov 30, 2012 at 8:37 PM, luigi scarso wrote:

...

On Fri, Nov 30, 2012 at 7:12 PM, Steve White wrote:

...
If possible, I would like to get the distro version working, before

...
to the latest version. hm, hard and useless Is this add-on module in some Debian package, or must one install it by hand? If the latter, what would be involved? no *deb package, as far I know. We usually have the latest context mkiv beta as reference, plus some "current"s. It's quite common that mkiv from texlive is too old (and those ones

moving form the distro too). but it's not a problem because installation is easy.

-- luigi

___________________________________________________________________________________ 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

___________________________________________________________________________________

Hans Hagen

3:02 p.m.

On 11/30/2012 10:25 PM, Steve White wrote:

...

Luigi,

OK, I get it. (I have wasted a couple of hours, it seems.)

I'll do as you first recommeded.

When you have a working context, you can also try the update process: just run the first-setup script again and it will sync. Normally the minimals are synced every 30 minutes (or nowadays maybe 15). Keep in mind that these days Mojca is moving the whole setup to a new server. I've uploaded a beta that supports this: \starttext \enabletrackers[visualizers.fontkern] \setupscripts[features=auto] \definedfont[freeserif*default] \language[en]Whereas recognition of the inherent dignity and of the equal and inalienable rights of all members of the human family is the foundation of freedom, justice and peace in the world. \language[gr]Επειδή η αναγνώριση της αξιοπρέπειας, που είναι σύμφυτη σε όλα τα μέλη της ανθρώπινης οικογένειας, καθώς και των ίσων και αναπαλλοτρίωτων δικαιωμάτων τους αποτελεί το θεμέλιο της ελευθερίας, της δικαιοσύνης και της ειρήνης στον κόσμο. \language[en]Whereas disregard and contempt for human rights have resulted in barbarous acts which have outraged the conscience of mankind, and the advent of a world in which human beings shall enjoy freedom of speech and belief and freedom from fear and want has been proclaimed as the highest aspiration of the common people. \language[gr]Επειδή η παραγνώριση και η περιφρόνηση των δικαιωμάτων του ανθρώπου οδήγησαν σε πράξεις βαρβαρότητας, που εξεγείρουν την ανθρώπινη συνείδηση, και η προοπτική ενός κόσμου όπου οι άνθρωποι θα είναι ελεύθεροι να μιλούν και να πιστεύουν, λυτρωμένοι από τον τρόμο και την αθλιότητα, έχει διακηρυχθεί ως η πιο υψηλή επιδίωξη του ανθρώπου. \stoptext Here \enabletrackers[visualizers.fontkern] is actually the official way to trigger the kern tracker (we keep some \commands around for old times sake) as it's part of more visual debugging features. \setupscripts[features=auto] This one is new and will do an analysis pass and set triggers for the so called dynamic feature handler (already present, so it was not that much work). One has to explicitly enable this trick and one can never depend on such things. Contrary to other tricks it does not obey grouping (could be done but adds overhead.) \definedfont[freeserif*default] This triggers the font. One can comment the \setupscripts line to see kerns go away. I only defined latn and grek: \definefontfeature[latn][script=latn] \definefontfeature[grek][script=grek] so it uses the regular feature definition mechanism. If this is considered useful we can add more and also think about a namespace (i.e. several predefined setups). In that case I will add the code that obeys grouping. But in order to do that we need tests and that's up to users. Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

Pablo Rodríguez

4:57 p.m.

Thanks for all replies Hans, Steve, Bill and Luigi. Sorry for the confusion generated by my questions. I'll try to summarize the whole thing as brief as I can. I happen to have an Sony PRS-T1 reader in which I noticed that the FreeSerif fonts where wrong kerned. I thought it might be something wrong in the fonts and I used ConTeXt to check that. Until this morning I asked whether TrueType kerning was enabled when all OpenType features were disabled, I took for granted that that old TrueType kerning was enabled when the modern OpenType kerning wasn't. Now I know I was wrong. But I reported a bug at https://savannah.gnu.org/projects/freefont/ and posted the PDF output from ConTeXt. ConTeXt is perfectly fine with FreeSerif, FreeSerif has valid kerning and the problem is in the Sony PRS-T1 reader that cannot read the kerning and ligature information. I have even discovered that the Sony PRS-T1 ereader has a bug that prevents the display of the FreeSerif bold font. So, I knew that the ereader had some limitations, but I couldn't imagine it was so buggy. The annoying issue here is that reporting the bug may fix the issue and Adobe might release a new version of the reader. But unless Sony releases a new firmware, those bugs are there to stay. Many thanks for your help and apologies for the confusion, Pablo -- http://www.ousia.tk

Steve White

1 Dec 1 Dec

9:22 a.m.

Hi Luigi, I got ConTeXt installed and running, but the install was very choppy. FYI the script you gave me had several problems, which I'll detail here. 1) Throughout you want freefont-ttf-20120503 rather than freefont-src-20120503 2) This line has a stray backslash character bash /first-setup.sh --modules=simplefonts 3) The command mtxrun --script font --reload searches a bunch of directories for fonts, but not the directory texmf-project/fonts/ My work-around was just to copy the *.ttf files to texmf-fonts/ and then re-do the mtxrun line. 4) You might want to explain that the source /opt/luatex/standalone-new/tex/setuptex has to be done once at the start of each session, or else bad things happen. 5) Generally it would be good to dilineate what should be done as root, and where normal user stuff starts. Thanks! On Fri, Nov 30, 2012 at 10:25 PM, Steve White wrote:

...

Luigi,

OK, I get it. (I have wasted a couple of hours, it seems.)

I'll do as you first recommeded.

On Fri, Nov 30, 2012 at 8:37 PM, luigi scarso wrote:

...
On Fri, Nov 30, 2012 at 7:12 PM, Steve White wrote:

...
If possible, I would like to get the distro version working, before

...
to the latest version. hm, hard and useless Is this add-on module in some Debian package, or must one install it by hand? If the latter, what would be involved? no *deb package, as far I know. We usually have the latest context mkiv beta as reference, plus some "current"s. It's quite common that mkiv from texlive is too old (and those ones

moving form the distro too). but it's not a problem because installation is easy.

-- luigi

___________________________________________________________________________________ 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

___________________________________________________________________________________

luigi scarso

12:22 p.m.

On Sat, Dec 1, 2012 at 5:22 PM, Steve White wrote:

...

Hi Luigi,

I got ConTeXt installed and running, but the install was very choppy.

FYI the script you gave me had several problems, which I'll detail here.

1) Throughout you want freefont-ttf-20120503 rather than freefont-src-20120503 yes, sorry (btw It would be nice to support the sfd format ...)

...

2) This line has a stray backslash character bash /first-setup.sh --modules=simplefonts

yes again sorry -- bash first-setup.sh --modules=simplefonts or bash ./first-setup.sh --modules=simplefonts

...

3) The command mtxrun --script font --reload searches a bunch of directories for fonts, but not the directory texmf-project/fonts/ My work-around was just to copy the *.ttf files to texmf-fonts/ and then re-do the mtxrun line.

Hm, no, this is strange --- are you sure ? If I remove the files from texmf-project/fonts/ and make mtxrun --script font --reload I have mtxrun --script font --list --all|grep Free But when I copy them again in texmf-project/fonts/ and mtxrun --script font --reload then mtxrun --script font --list --all|grep Free then I see freemono freemono FreeMono.ttf freemonobold freemonobold FreeMonoBold.ttf freemonoboldoblique freemonoboldoblique FreeMonoBoldOblique.ttf freemononormal freemonooblique FreeMonoOblique.ttf freemonooblique freemonooblique FreeMonoOblique.ttf freesans freesans FreeSans.ttf freesansbold freesansbold FreeSansBold.ttf freesansboldoblique freesansboldoblique FreeSansBoldOblique.ttf freesansdemi freesansbold FreeSansBold.ttf freesansnormal freesansoblique FreeSansOblique.ttf freesansoblique freesansoblique FreeSansOblique.ttf freeserif freeserif FreeSerif.ttf freeserifbold freeserifbold FreeSerifBold.ttf freeserifbolditalic freeserifbolditalic FreeSerifBoldItalic.ttf freeserifitalic freeserifitalic FreeSerifItalic.ttf freeserifnormal freeserifitalic FreeSerifItalic.ttf I also see fonts | names | scanning /opt/luatex/standalone-mkiv/tex/texmf-project for otf files fonts | names | scanning /opt/luatex/standalone-mkiv/tex/texmf-project for OTF files fonts | names | scanning /opt/luatex/standalone-mkiv/tex/texmf-project for ttf files fonts | names | scanning /opt/luatex/standalone-mkiv/tex/texmf-project for TTF files fonts | names | scanning /opt/luatex/standalone-mkiv/tex/texmf-project for ttc files fonts | names | scanning /opt/luatex/standalone-mkiv/tex/texmf-project for TTC files fonts | names | scanning /opt/luatex/standalone-mkiv/tex/texmf-project for dfont files fonts | names | scanning /opt/luatex/standalone-mkiv/tex/texmf-project for DFONT files fonts | names | scanning /opt/luatex/standalone-mkiv/tex/texmf-project for afm files fonts | names | scanning /opt/luatex/standalone-mkiv/tex/texmf-project for AFM files The problem with texmf-fonts/ is that is keep in sync with the original source, and hence the files can be deleted.

...

4) You might want to explain that the source /opt/luatex/standalone-new/tex/setuptex has to be done once at the start of each session, or else bad things happen.

Hm , nothing bad: you use the default pdftex/xetex/luatex --- nothing of catastrophic, this doesn't touch your mkiv in anyway. Given that mkiv require some experience, the default is to leave the distro to manage the TeX installation and the user to setup the appropriate environment.

...

5) Generally it would be good to dilineate what should be done as root, and where normal user stuff starts. Hm, to be root is not required -- have you found some problem ?

-- luigi

Aditya Mahajan

12:38 p.m.

On Sat, 1 Dec 2012, luigi scarso wrote:

...

...
5) Generally it would be good to dilineate what should be done as root, and where normal user stuff starts. Hm, to be root is not required -- have you found some problem ?

Usually, normal users do not have write permissions in /opt directory. Aditya

luigi scarso

12:46 p.m.

On Sat, Dec 1, 2012 at 8:38 PM, Aditya Mahajan wrote:

...

On Sat, 1 Dec 2012, luigi scarso wrote:

...
...
5) Generally it would be good to dilineate what should be done as root, and where normal user stuff starts.

Hm, to be root is not required -- have you found some problem ?

Usually, normal users do not have write permissions in /opt directory. If we follow strict rules, "normal" user should not install the latest context -- only the admin.

-- luigi

Aditya Mahajan

12:58 p.m.

On Sat, 1 Dec 2012, luigi scarso wrote:

...

On Sat, Dec 1, 2012 at 8:38 PM, Aditya Mahajan wrote:

...
On Sat, 1 Dec 2012, luigi scarso wrote:

...
...
5) Generally it would be good to dilineate what should be done as root, and where normal user stuff starts.

Hm, to be root is not required -- have you found some problem ?

Usually, normal users do not have write permissions in /opt directory. If we follow strict rules, "normal" user should not install the latest context -- only the admin.

And hence Steve's remark that the installation instruction should differentiate between what needs to be dun as root and what as normal user (the user run context --make needs to have write permission in TEXMFCACHE). Aditya

luigi scarso

2:09 p.m.

On Sat, Dec 1, 2012 at 8:58 PM, Aditya Mahajan wrote:

...

On Sat, 1 Dec 2012, luigi scarso wrote:

...
On Sat, Dec 1, 2012 at 8:38 PM, Aditya Mahajan wrote:

...
On Sat, 1 Dec 2012, luigi scarso wrote:

...
...
5) Generally it would be good to dilineate what should be done as root, and where normal user stuff starts.

Hm, to be root is not required -- have you found some problem ?

Usually, normal users do not have write permissions in /opt directory.

If we follow strict rules, "normal" user should not install the latest context -- only the admin.

And hence Steve's remark that the installation instruction should differentiate between what needs to be dun as root and what as normal user (the user run context --make needs to have write permission in TEXMFCACHE).

A normal user cannot even download first-setup.sh and install the files. But if he can then he can install context under his home and mkiv works ok -- no need to be root. This can be useful in a server that run context as service -- create a user that manage the context, a common pattern (apache, mysql, postgres, etc). About /opt , it's a location for add-on, and it's usually unused by standard distro (so one leaves the machine clean.): see http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACK... In this situation the choice between homedir and /opt is of course a personal taste, and I prefer to install general applications (or applications that can be of general utility) under /opt . -- luigi

Steve White

2 Dec 2 Dec

2:58 a.m.

Hi all, I finally got something like Pablo's test working on my system. It doesn't show much new. As had already been established, with the right ConTeXt switches, OpenType features of kerning and ligatures work correctly with FreeSerif. Find attached. If there's a better way to do this, please comment: I may put some of this in the FreeFront usage notes. (Hm... I may tighten the italic y a bit.) A question remains: Why does ConTeXt (like some other TeX derivatives that use OpenType) not determine the OpenType script of runs of text from the Unicode (or other encoding) character range? All other font layout systems I know of do this. (Remember- a run of text in the OpenType sense is not the same as the scope of a TeX environment, it is typically a word, separated by white space or punctuation.) Maybe there is some rationale, but I haven't heard it yet. Let me propose a different interpretation for the existing 'script' setting as used in the \definefontfeature command in the attached tex file: * If it is not present, the engine would revert to using the script indicated by the encoding for each run of text. * If it is present, it would mean "activate only features that match the specified script". It appears to me this would not change the rendering of many documents, if any, but it would alleviate the confusion that gave rise to this thread. Cheers!

Steve White

3:10 a.m.

...

On Sat, Dec 1, 2012 at 5:22 PM, Steve White wrote:

...
3) The command mtxrun --script font --reload searches a bunch of directories for fonts, but not the directory texmf-project/fonts/ My work-around was just to copy the *.ttf files to texmf-fonts/ and then re-do the mtxrun line.

Hm, no, this is strange --- are you sure ? If I remove the files from texmf-project/fonts/ and make mtxrun --script font --reload I have mtxrun --script font --list --all|grep Free But when I copy them again in texmf-project/fonts/ and mtxrun --script font --reload then mtxrun --script font --list --all|grep Free then I see

freemono freemono FreeMono.ttf freemonobold freemonobold FreeMonoBold.ttf freemonoboldoblique freemonoboldoblique FreeMonoBoldOblique.ttf freemononormal freemonooblique FreeMonoOblique.ttf freemonooblique freemonooblique FreeMonoOblique.ttf freesans freesans FreeSans.ttf freesansbold freesansbold FreeSansBold.ttf freesansboldoblique freesansboldoblique FreeSansBoldOblique.ttf freesansdemi freesansbold FreeSansBold.ttf freesansnormal freesansoblique FreeSansOblique.ttf freesansoblique freesansoblique FreeSansOblique.ttf freeserif freeserif FreeSerif.ttf freeserifbold freeserifbold FreeSerifBold.ttf freeserifbolditalic freeserifbolditalic FreeSerifBoldItalic.ttf freeserifitalic freeserifitalic FreeSerifItalic.ttf freeserifnormal freeserifitalic FreeSerifItalic.ttf

I also see

fonts | names | scanning /opt/luatex/standalone-mkiv/tex/texmf-project for otf files fonts | names | scanning /opt/luatex/standalone-mkiv/tex/texmf-project for OTF files fonts | names | scanning /opt/luatex/standalone-mkiv/tex/texmf-project for ttf files fonts | names | scanning /opt/luatex/standalone-mkiv/tex/texmf-project for TTF files fonts | names | scanning /opt/luatex/standalone-mkiv/tex/texmf-project for ttc files fonts | names | scanning /opt/luatex/standalone-mkiv/tex/texmf-project for TTC files fonts | names | scanning /opt/luatex/standalone-mkiv/tex/texmf-project for dfont files fonts | names | scanning /opt/luatex/standalone-mkiv/tex/texmf-project for DFONT files fonts | names | scanning /opt/luatex/standalone-mkiv/tex/texmf-project for afm files fonts | names | scanning /opt/luatex/standalone-mkiv/tex/texmf-project for AFM files

The problem with texmf-fonts/ is that is keep in sync with the original source, and hence the files can be deleted.

I can assure you, this fonts/ directory was not in the list produced by

Hi Luigi, I have something to add to only one of your points: On Sat, Dec 1, 2012 at 8:22 PM, luigi scarso wrote: the mtxrun command on my system. Something is different between your system and mine. This might be worth investigating. (But I won't have time for it!) Perhaps you have a file somewhere that adds this other directory. This is my best guess. It is also possible something was left over on my system from the previous distro installation. However I removed that installation with the dpkg --purge command, which should have removed all settings files. I didn't alter any configuration files myself, I only tried (unsuccessfully) to run context on some tex files. As I had only turned context on a few times, and never done any configuration, it is easy to reproduce my setup: Start with the latest Ubuntu, and install the 'context' package. Then remove it with --purge, and follow your instructions to install the recent 'context' in /opt. Cheers!

luigi scarso

3:24 a.m.

...

I can assure you, this fonts/ directory was not in the list produced by the mtxrun command on my system. yes, but you should see the texmf-project folder; and if you put the ttf files under texmf-project/fonts

On Sun, Dec 2, 2012 at 11:10 AM, Steve White wrote: then context should be able to read them. -- luigi

Wolfgang Schuster

3:43 a.m.

Am 02.12.2012 um 11:24 schrieb luigi scarso :

...

On Sun, Dec 2, 2012 at 11:10 AM, Steve White wrote:

...
I can assure you, this fonts/ directory was not in the list produced by the mtxrun command on my system. yes, but you should see the texmf-project folder; and if you put the ttf files under texmf-project/fonts then context should be able to read them.

New files in the tex tree aren’t found unless you update the database with "mtxrun --generate". Wolfgang

Steve White

4:08 a.m.

Hi Luigi, Perhaps that is what *should* have happened. It did not happen. Context did not read the fonts when they were in the texmf-project/fonts folder, It did read them when I moved them as described. On Sun, Dec 2, 2012 at 11:24 AM, luigi scarso wrote:

...

On Sun, Dec 2, 2012 at 11:10 AM, Steve White wrote:

...
I can assure you, this fonts/ directory was not in the list produced by the mtxrun command on my system. yes, but you should see the texmf-project folder; and if you put the ttf files under texmf-project/fonts then context should be able to read them.

-- luigi

___________________________________________________________________________________ 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

___________________________________________________________________________________

luigi scarso

4:48 a.m.

On Sun, Dec 2, 2012 at 12:08 PM, Steve White wrote:

...

Hi Luigi,

Perhaps that is what *should* have happened.

It did not happen.

Context did not read the fonts when they were in the texmf-project/fonts folder, It did read them when I moved them as described. ok.

Khaled Hosny

6:12 a.m.

On Sun, Dec 02, 2012 at 10:58:56AM +0100, Steve White wrote:

...

Hi all,

I finally got something like Pablo's test working on my system. It doesn't show much new. As had already been established, with the right ConTeXt switches, OpenType features of kerning and ligatures work correctly with FreeSerif.

Find attached. If there's a better way to do this, please comment: I may put some of this in the FreeFront usage notes. (Hm... I may tighten the italic y a bit.)

A question remains: Why does ConTeXt (like some other TeX derivatives that use OpenType) not determine the OpenType script of runs of text from the Unicode (or other encoding) character range? All other font layout systems I know of do this. (Remember- a run of text in the OpenType sense is not the same as the scope of a TeX environment, it is typically a word, separated by white space or punctuation.)

Determining the script of a run of text is not that simple, take "english (ARABIC.)"; to which script should the parenthesis and the period be classified? (they have a "common" script property in Unicode and not assigned to any given script). Unicode annex #24 provides an algorithm for to handle this that an engine should implement: http://www.unicode.org/reports/tr24/ Regards, Khaled

Steve White

7:32 a.m.

Determinig the script from the text is not hard. It has been done in many projects. On Sun, Dec 2, 2012 at 2:12 PM, Khaled Hosny wrote:

...

...
Hi all,

I finally got something like Pablo's test working on my system. It doesn't show much new. As had already been established, with the right ConTeXt switches, OpenType features of kerning and ligatures work correctly with FreeSerif.

Find attached. If there's a better way to do this, please comment: I may put some of this in the FreeFront usage notes. (Hm... I may tighten the italic y a bit.)

A question remains: Why does ConTeXt (like some other TeX derivatives

On Sun, Dec 02, 2012 at 10:58:56AM +0100, Steve White wrote: that

...
use OpenType) not determine the OpenType script of runs of text from the Unicode (or other encoding) character range? All other font layout systems I know of do this. (Remember- a run of text in the OpenType sense is not the same as the scope of a TeX environment, it is typically a word, separated by white space or punctuation.)

Determining the script of a run of text is not that simple, take "english (ARABIC.)"; to which script should the parenthesis and the period be classified? (they have a "common" script property in Unicode and not assigned to any given script). Unicode annex #24 provides an algorithm for to handle this that an engine should implement: http://www.unicode.org/reports/tr24/

Regards, Khaled

___________________________________________________________________________________ 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

___________________________________________________________________________________

Khaled Hosny

7:49 a.m.

And how many of them do it right? None, not even Pango, not even Firefox, all are broken in some subtle ways. I'm not saying it is hard, though, I'm saying it is complex. Regards, Khaled On Sun, Dec 02, 2012 at 03:32:49PM +0100, Steve White wrote:

...

Determinig the script from the text is not hard.

It has been done in many projects.

On Sun, Dec 2, 2012 at 2:12 PM, Khaled Hosny wrote:

...
...
Hi all,

I finally got something like Pablo's test working on my system. It doesn't show much new. As had already been established, with the right ConTeXt switches, OpenType features of kerning and ligatures work correctly with FreeSerif.

Find attached. If there's a better way to do this, please comment: I may put some of this in the FreeFront usage notes. (Hm... I may tighten the italic y a bit.)

A question remains: Why does ConTeXt (like some other TeX derivatives

On Sun, Dec 02, 2012 at 10:58:56AM +0100, Steve White wrote: that

...
use OpenType) not determine the OpenType script of runs of text from the Unicode (or other encoding) character range? All other font layout systems I know of do this. (Remember- a run of text in the OpenType sense is not the same as the scope of a TeX environment, it is typically a word, separated by white space or punctuation.)

Determining the script of a run of text is not that simple, take "english (ARABIC.)"; to which script should the parenthesis and the period be classified? (they have a "common" script property in Unicode and not assigned to any given script). Unicode annex #24 provides an algorithm for to handle this that an engine should implement: http://www.unicode.org/reports/tr24/

Regards, Khaled

___________________________________________________________________________________ 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

___________________________________________________________________________________

...

___________________________________________________________________________________ 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 ___________________________________________________________________________________

4255

Age (days ago)

4257

Last active (days ago)

List overview

Download

38 comments

8 participants

participants (8)

Aditya Mahajan
Bill Meahan
Hans Hagen
Khaled Hosny
luigi scarso
Pablo Rodríguez
Steve White
Wolfgang Schuster