Hi all!
It seems that Luatex (0.76 2013/04/05) don't works with Mavericks?
Thank's in advanced for your help and testimonies
Best wishes
-- Pierre Bovet Documentaliste technique | Chargé de sécurité CFST
Tel : +41 (0) 26 401 61 56 Courriel : pierre67@me.com
On 24 Oct 2013, at 07:41, Pierre Bovet pierre67@me.com wrote:
Hi all!
It seems that Luatex (0.76 2013/04/05) don't works with Mavericks?
Thank's in advanced for your help and testimonies
Best wishes
I’m afraid you’re right! I installed Mavericks yesterday; trying to build the format, I get this:
fonts > names > globbing path '/Library/Fonts/**.ttf' mtx-context | fatal error: no return code, message: luatex: execution interrupted
It may be a new wacky font in /Library/Fonts. 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…
Thomas
On 24 Oct 2013, at 07:41, Pierre Bovet pierre67@me.com wrote:
Hi all!
It seems that Luatex (0.76 2013/04/05) don't works with Mavericks?
Thank's in advanced for your help and testimonies
Best wishes
I’m afraid you’re right! I installed Mavericks yesterday; trying to build the format, I get this:
fonts > names > globbing path '/Library/Fonts/**.ttf' mtx-context | fatal error: no return code, message: luatex: execution interrupted
It may be a new wacky font in /Library/Fonts. 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…
Thomas
On 24 Oct 2013, at 09:01, Schmitz Thomas A. thomas.schmitz@uni-bonn.de 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.
Thomas
On 10/24/2013 4:12 PM, Schmitz Thomas A. wrote:
On 24 Oct 2013, at 09:01, Schmitz Thomas A. thomas.schmitz@uni-bonn.de 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:
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
- 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 Thu, 24 Oct 2013 23:17:13 +0900 Hans Hagen pragma@wxs.nl 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).
Users can set OSFONTDIR in their environment if they wish, and this can be specified in the wiki. Also, the standalone script can include a (harmless) message informing the user of this possibility.
Alan
On 24 Oct 2013, at 16:17, Hans Hagen pragma@wxs.nl 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 Thu, 24 Oct 2013, Schmitz Thomas A. wrote:
On 24 Oct 2013, at 16:17, Hans Hagen pragma@wxs.nl 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).
You need to set it to a dummy directory! See: http://tex.stackexchange.com/a/136073/323
Aditya
On 24 Oct 2013, at 16:44, Aditya Mahajan adityam@umich.edu 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 pragma@wxs.nl 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 10/25/2013 7:01 AM, Schmitz Thomas A. wrote:
On 24 Oct 2013, at 16:44, Aditya Mahajan adityam@umich.edu 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 pragma@wxs.nl 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
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.
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 -----------------------------------------------------------------
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 adityam@umich.edu 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 pragma@wxs.nl 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 okt. 2013, at 00:13, Hans Hagen <pragma@wxs.nlmailto:pragma@wxs.nl> wrote:
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.
(1) Where resides above mentioned "main cnf file"? Useful as template for local changes.
(2) I presume that the main cnf file is read in first and the local one after that. Thus changing only that what is done in the local file. Correct?
Hans van der Meer
On 25 Oct 2013, at 00:13, Hans Hagen pragma@wxs.nl 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
On 10/24/2013 11:39 PM, Schmitz Thomas A. wrote:
On 24 Oct 2013, at 16:17, Hans Hagen pragma@wxs.nl 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).
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.
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 -----------------------------------------------------------------
Am 24.10.2013 um 07:41 schrieb Pierre Bovet pierre67@me.com:
Hi all!
It seems that Luatex (0.76 2013/04/05) don't works with Mavericks?
Thank's in advanced for your help and testimonies
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
On 24 Oct 2013, at 09:04, Wolfgang Schuster wolfgang.schuster@gmail.com 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).
Thomas
Am 24.10.2013 um 09:13 schrieb Schmitz Thomas A. thomas.schmitz@uni-bonn.de:
On 24 Oct 2013, at 09:04, Wolfgang Schuster wolfgang.schuster@gmail.com 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
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
Pierre
Le 24 oct. 2013 à 09:24, Wolfgang Schuster wolfgang.schuster@gmail.com a écrit :
Am 24.10.2013 um 09:13 schrieb Schmitz Thomas A. thomas.schmitz@uni-bonn.de:
On 24 Oct 2013, at 09:04, Wolfgang Schuster wolfgang.schuster@gmail.com 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 ___________________________________________________________________________________ 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 ___________________________________________________________________________________
Am 24.10.2013 um 09:30 schrieb Pierre Bovet pierre67@me.com:
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
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
Pierre
Le 24 oct. 2013 à 09:36, Wolfgang Schuster wolfgang.schuster@gmail.com a écrit :
Am 24.10.2013 um 09:30 schrieb Pierre Bovet pierre67@me.com:
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
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 ___________________________________________________________________________________
Am 24.10.2013 um 09:45 schrieb Pierre Bovet pierre67@me.com:
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
On 24 Oct 2013, at 10:00, Wolfgang Schuster wolfgang.schuster@gmail.com 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
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. thomas.schmitz@uni-bonn.de a écrit :
On 24 Oct 2013, at 10:00, Wolfgang Schuster wolfgang.schuster@gmail.com 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 All, Wolfgang,
The PROBLEM is that Skia.ttf has the wrong permissions! Everyone is set to none. meaning this file can not be read!
Solution copy to somewhere else, remove from /Library/Fonts and reinstall.
This suggest to me that when scanning the fonts and building the support files there is a sanity check missing! Whether this sanity is truly needed is a matter of taste, as I assume this is most likely a very rare case, where a system font has for some reason bad permissions. Interestingly enough on my clean OSX only emergency drive Skia.ttf has the proper permissions.
Since I did a clean and migrated the my user with Migration Assistant I assume it mangled the permissions.
regards Keith.
Am 24.10.2013 um 10:00 schrieb Wolfgang Schuster wolfgang.schuster@gmail.com:
Am 24.10.2013 um 09:45 schrieb Pierre Bovet pierre67@me.com:
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 ___________________________________________________________________________________ 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 -----------------------------------------------------------------
On 10/24/2013 10:00 AM, Wolfgang Schuster wrote:
Am 24.10.2013 um 09:45 schrieb Pierre Bovet pierre67@me.com:
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
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 taco@elvenkind.com wrote:
On 10/24/2013 10:00 AM, Wolfgang Schuster wrote:
Am 24.10.2013 um 09:45 schrieb Pierre Bovet pierre67@me.com:
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 ___________________________________________________________________________________
Hi Pierre,
I have Mavericks installed and no problems.
But, I did a clean install, migrated User Folder from a TM-Backup, and my ConTeXt Suite (latest beta) work fine.
Since I did a clean install I had to install MacTeX. -- Tried an older LuaLaTeX and got an error -- Ran TeXLive Utility and update TeXLive Everything works fine.
I did notice that LuaTeX binaries were updated.
Since you have not said where you got your version from try repairing permission on your disk. You should do this especially you did not do this before the update.
or just update or reinstall!
Sorry for going slightly OT.
regards Keith.
Am 24.10.2013 um 07:41 schrieb Pierre Bovet pierre67@me.com:
Hi all!
It seems that Luatex (0.76 2013/04/05) don't works with Mavericks?
Thank's in advanced for your help and testimonies
Best wishes
-
Aditya Mahajan -
Alan BRASLAU -
Hans Hagen -
Keith J. Schultz -
Meer, H. van der -
Meer, Hans van der
-
Otared Kavian -
Pierre Bovet -
Schmitz Thomas A. -
Taco Hoekwater -
Wolfgang Schuster