On 10/24/2013 4:12 PM, Schmitz Thomas A. wrote:

On 24 Oct 2013, at 09:01, Schmitz Thomas A. wrote:

...

But so far, I have not been able to unset OSFONTDIR and make context ignore this directory. (Unlike some people in a recent discussion, my preference would be to NOT include any system fonts by default: it slows rebuilding the formats down, people who want it can achieve it, and it’s generally a bad idea). I’ll see if I can figure out how to do this and will report back, but for the time being, context cannot be used on Mavericks…

I’m getting slightly annoyed, please excuse my rant. I DO NOT want context to search for system fonts. What I have done is:

1. delete the lines

elseif osname=="macosx" then ossetenv("OSFONTDIR","$HOME/Library/Fonts//;/System/Library/Fonts//“ etc.

in mtxrun.lua. Rebuild formats. Result when I compile a file:

fonts > names > globbing path '/Library/Fonts/**.ttf’ mtx-context | fatal error: no return code, message: luatex: execution interrupted

2. set an environment variable OSFONTDIR, rebuild formats. Result: same as above

Why, oh why is context doing this? Just because some lazy people want their “system fonts” used, why is it impossible to make a clean separation? I only want fonts in my tex-trees used and searched, nothing else.

Hm. The problem is that we get some oscillation (with a few year cycle) between the 'demand' for os fonts support vs tree only (as far as remember os font support was mostly requested by osx users). Anyhow, we can make it an option, but then the question is: what is the default (and who is going to defend that choice to distributers and users). Hans (who never uses system fonts anyway) ----------------------------------------------------------------- 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 -----------------------------------------------------------------

On 24 Oct 2013, at 16:17, Hans Hagen wrote:

Hm. The problem is that we get some oscillation (with a few year cycle) between the 'demand' for os fonts support vs tree only (as far as remember os font support was mostly requested by osx users). Anyhow, we can make it an option, but then the question is: what is the default (and who is going to defend that choice to distributers and users).

Hans

Yes, I’m aware that any default will make some users unhappy. I would prefer to have osfontdir unset by default because there’s a real speed penalty in having it set so I would agree with Alan on that one. (It would also abolish the inconsistency between platforms.) But for me the real question is: what do I have to do to have osfontdir unset as things are now? I tried some things, none worked. (see my earlier mail). Thomas

On 24 Oct 2013, at 16:44, Aditya Mahajan wrote:

You need to set it to a dummy directory! See: http://tex.stackexchange.com/a/136073/323

No, even that doesn’t help: echo $OSFONTDIR /tmp/dummy and then on a first run (after regnerating the format with this variable set), I get lines such as fonts > names > 'OSFONTDIR' specifies path '/Users/tas/Library/Fonts' fonts > names > 'OSFONTDIR' specifies path '/Library/Fonts' fonts > names > 'OSFONTDIR' specifies path '/System/Library/Fonts' fonts > names > globbing path '/System/Library/Fonts/**.OTF' fonts > names > 68 system files identified, 2 skipped, 2 duplicates, 66 hash entries added, runtime 43.223 seconds So something appears to be overriding the variable that I set. But what? And why? And how do I stop it? On 24 Oct 2013, at 23:40, Hans Hagen wrote:

I don't understand the speed issue. We're talking about relatively few fonts only and context will not scan them unless there is a change. After a remake a rescan takes < 9 sec on my laptop and < 6 sec once the directories have been cached (windows 8 / 64 bit / i7 / ssd).

Only an initial full scan takes a while (deleted cache), but that's mostly because I have a pretty large font collection in my texmf-fonts tree.

You’re right of course that it’s only the initial run when a new font cache has to be built, but the time I get on os x is much longer than what you report: with rescanning of system fonts: system | total runtime: 114.131 (yes, that’s almost 2 minutes!) And I don’t want to twiddle my thumbs for two minutes, and don’t want to use those “system fonts” (or if I want to use them, I will copy them to my texmf directories)! Thomas

On Fri, 25 Oct 2013, Hans Hagen wrote:

On 10/25/2013 7:01 AM, Schmitz Thomas A. wrote:

...

On 24 Oct 2013, at 16:44, Aditya Mahajan wrote:

...

You need to set it to a dummy directory! See: http://tex.stackexchange.com/a/136073/323

No, even that doesn’t help:

echo $OSFONTDIR /tmp/dummy

and then on a first run (after regnerating the format with this variable set), I get lines such as

fonts > names > 'OSFONTDIR' specifies path '/Users/tas/Library/Fonts' fonts > names > 'OSFONTDIR' specifies path '/Library/Fonts' fonts > names > 'OSFONTDIR' specifies path '/System/Library/Fonts' fonts > names > globbing path '/System/Library/Fonts/**.OTF' fonts > names > 68 system files identified, 2 skipped, 2 duplicates, 66 hash entries added, runtime 43.223 seconds

So something appears to be overriding the variable that I set. But what? And why? And how do I stop it?

On 24 Oct 2013, at 23:40, Hans Hagen wrote:

...

I don't understand the speed issue. We're talking about relatively few fonts only and context will not scan them unless there is a change. After a remake a rescan takes < 9 sec on my laptop and < 6 sec once the directories have been cached (windows 8 / 64 bit / i7 / ssd).

Only an initial full scan takes a while (deleted cache), but that's mostly because I have a pretty large font collection in my texmf-fonts tree.

You’re right of course that it’s only the initial run when a new font cache has to be built, but the time I get on os x is much longer than what you report:

with rescanning of system fonts: system | total runtime: 114.131 (yes, that’s almost 2 minutes!)

And I don’t want to twiddle my thumbs for two minutes, and don’t want to use those “system fonts” (or if I want to use them, I will copy them to my texmf directories)!

hm, i wonder why that takes so long as i get:

tex tree:

561 tree files identified, 5 skipped, 5 duplicates, 556 hash entries added, runtime 14.282 seconds 426 tree files identified, 7 skipped, 5 duplicates, 419 hash entries added, runtime 12.297 seconds 8 tree files identified, 0 skipped, 0 duplicates, 8 hash entries added, runtime 0.188 seconds 0 tree files identified, 0 skipped, 0 duplicates, 0 hash entries added, runtime 0.156 seconds 677 tree files identified, 1 skipped, 1 duplicates, 676 hash entries added, runtime 0.672 seconds

system:

2 system files identified, 0 skipped, 0 duplicates, 2 hash entries added, runtime 0.047 seconds 437 system files identified, 57 skipped, 57 duplicates, 380 hash entries added, runtime 20.001 seconds 20 system files identified, 1 skipped, 1 duplicates, 19 hash entries added, runtime 0.063 seconds 0 system files identified, 0 skipped, 0 duplicates, 0 hash entries added, runtime 0.031 seconds 0 system files identified, 0 skipped, 0 duplicates, 0 hash entries added, runtime 0.047 seconds

That is similar to what I get (regular hard drive, no SSD) mtxrun --script fonts --reload --force | grep time fonts | names | 757 tree files identified, 245 skipped, 244 duplicates, 512 hash entries added, runtime 7.720 seconds fonts | names | 224 tree files identified, 60 skipped, 48 duplicates, 164 hash entries added, runtime 3.052 seconds fonts | names | 2 tree files identified, 1 skipped, 1 duplicates, 1 hash entries added, runtime 0.404 seconds fonts | names | 0 tree files identified, 0 skipped, 0 duplicates, 0 hash entries added, runtime 0.406 seconds fonts | names | 1503 tree files identified, 210 skipped, 113 duplicates, 1293 hash entries added, runtime 1.034 seconds fonts | names | 50 system files identified, 14 skipped, 14 duplicates, 36 hash entries added, runtime 4.429 seconds fonts | names | 126 system files identified, 21 skipped, 21 duplicates, 105 hash entries added, runtime 0.548 seconds fonts | names | 0 system files identified, 0 skipped, 0 duplicates, 0 hash entries added, runtime 0.005 seconds fonts | names | 0 system files identified, 0 skipped, 0 duplicates, 0 hash entries added, runtime 0.005 seconds fonts | names | 35 system files identified, 0 skipped, 0 duplicates, 35 hash entries added, runtime 0.007 seconds fonts | names | total scan time 39.783 seconds Aditya

On 25 Oct 2013, at 00:13, Hans Hagen wrote (in a discussion on the OSFONTDIR environment variable in MacOSX)

anyway, in a next beta you can set this in texmf.cnf.lua:

return { content = { directives = { ["fonts.usesystemfonts"] = false, }, }, }

Best do that in texmf-local as a next update will overwrite the main cnf file. Entries in the he local file overload main ones.

I took the liberty to look again into this matter because the above advice does not what I should expect it does: ignoring the MacOSX font directories. This is what I found in various experiments, OSFONTDIR not defined in the environment. (1) I guess the name of the cnf file should be texmfcnf.lua not texmf.cnf.lua because a file with the latter name has no effect, the MACOSX font directories still appear in the log. (2) That file in texmf.local does nothing because again the MacOSX font directories are still in the log, but there is a reference to a file of that name: mkiv lua stats > used config file: selfautoparent:/texmf/web2c/texmfcnf.lua (3) Moving texmfcnf.lua to a directory /texmf.local/web2c/ is desastrous, the log tells me: resolvers | trees | analyzing '/Users/hansm/Documents/TeX/texmf' mtxrun | unknown script 'context.lua' or 'mtx-context.lua' Questions therefore: - is the name texmfcnf.lua indeed? - what should be its location in texmf.local? (texmf/web2c doesn't exist on my system because I restrict myself to the beta) - is the content of texmfcnf.lua as given above complete? Referring to a dummy font directory in OSFONTDIR still seems the most viable option. Is that correct? Hans van der Meer

Am 24.10.2013 um 09:13 schrieb Schmitz Thomas A. :

On 24 Oct 2013, at 09:04, Wolfgang Schuster wrote:

...

There are no problems for me with the last version of the context suite and OS 10.9.

This is LuaTeX, Version beta-0.76.0-2013040508 (TeX Live 2013/dev)(rev 4627)

Wolfgang

not on my system. I have this version and the latest suite, and context bails out (see my other messages).

I get also a error message when I update the font database fonts | names | globbing path '/Library/Fonts/**.ttf'Segmentation fault: 11 but it doesn’t prevent me from using LuaTeX or regenerating the context format. Wolfgang

Am 24.10.2013 um 09:30 schrieb Pierre Bovet :

Context (luatex) works without problem under Mavericks, but it don't works with external font:

\usetypescript[lucida][ec] \setupbodyfont[lucida,12pt] \starttext

Hello world!

\stoptext

This is unrelated to the problem. MkIV has no support for the Type1 version of the Lucida fonts, use the OpenType version instead (new version which can be purchased from TUG). \setupbodyfont[lucidaot] \starttext Hello world! \stoptext Wolfgang

Am 24.10.2013 um 09:45 schrieb Pierre Bovet :

OK, that was not a good example… But the the message above is coming with any other otf fonts:

fonts > names > globbing path '/Library/Fonts/**.ttf'

mtx-context | fatal error: no return code, message: luatex: execution interrupted

Can you remove the Skia.ttf (copy it to another directory) font from /Library/Fonts, this helped on my system to get rid of the error message. Wolfgang

Oh yes, thank you very much! I can compile again with Myriad Pro and all other otf fonts! Thank you! Pierre Le 24 oct. 2013 à 10:08, Schmitz Thomas A. a écrit :

On 24 Oct 2013, at 10:00, Wolfgang Schuster wrote:

...

Can you remove the Skia.ttf (copy it to another directory) font from /Library/Fonts, this helped on my system to get rid of the error message.

Wolfgang

Yes, that helped, and I can at least compile my documents again. (How did you find out it was this particular font?).

Thanks a lot

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

Hi, Concerning unix: Norbert Preining (tex live maintainer) found out that when font directories are symlinks, file access is much slower due to more lookups (esp with long names as then the lookup is indirect which means more disk access). Of course on a modern machine with ssd this is neglectable. 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 -----------------------------------------------------------------

Hi everyone, I installed MacOS X 10.9 « Mavericks » on top of the latest MacOS X 10.8, and could run my installation of ConTeXt stand alone without any problem, despite having Skia.ttf on my system: Version 8.0d1e1 Location /Library/Fonts/Skia.ttf Unique name Skia Regular; 8.0d1e1; 2012-09-05 Copyright © 1993-2002 Apple Inc. Enabled Yes Duplicate No Copy protected No Glyph count 591 The rights for this font are: -rw-r--r-- 1 root wheel 480K 25 oct 04:56 Skia.ttf (these rights are the same as other fonts, and clearly I never changed these…). I also made anew the formats after having installed Mavericks, and did not notice any problem with a dozen tests I did. So it seems that the cases in which problems have shown up are quite various. The version of ConTeXt I have now is ConTeXt ver: 2013.10.15 13:52 MKIV beta fmt: 2013.10.25 (By the way, even after running first-setup.sh, I get always the same version… This may be due to the fact that I am in China right now?). A last word regarding the requests for changing the defaults for system fonts. The present situation has the advantage that people who are far from being geeks (for instance like me and the secretaries to whom I have shown how to use ConTeXt) can use whatever fonts they have on their system without tweaking the .cnf file, and without knowing how to write a typescript (thanks to the features added recently by Wolfgang). People who have the technical knowledge and don’t want to use their system fonts because of waste of typesetting time, can indeed change this default behaviour. So PLEASE don’t change the present default! Best regards: OK On 25 oct. 2013, at 16:49, Taco Hoekwater wrote:

On 10/24/2013 10:00 AM, Wolfgang Schuster wrote:

...

Am 24.10.2013 um 09:45 schrieb Pierre Bovet :

...

OK, that was not a good example… But the the message above is coming with any other otf fonts:

fonts > names > globbing path '/Library/Fonts/**.ttf'

mtx-context | fatal error: no return code, message: luatex: execution interrupted

Can you remove the Skia.ttf (copy it to another directory) font from /Library/Fonts, this helped on my system to get rid of the error message.

It is definitely Skia.ttf itself, and not its permissions. After my upgrade to Mavericks, I got a fresh Skia.ttf (491796 bytes), and even though the permissions were fine (644), it crashes luatex, standalone fontforge, and ttx.

Actually, changing the file permissions to 000 (not readable by anyone) fixed context's use of system fonts.

ttx says: TT instructions error: 'illegal opcode: 0x91'; texlua and fontforge just crash on an undefined glyph in the internals of the font.

Best wishes, Taco

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