Re: [NTG-context] registered function call [1160]:...live/2023/texmf-dist/tex/context/base/mkiv/l-sandbox.lua:87: cannot open /.: Permission denied - Alpine Linux
On Sun, Apr 02, 2023 at 10:41:53AM +0200, Hans Hagen via ntg-context wrote:
> On 4/1/2023 11:21 PM, Carlos via ntg-context wrote:
> > On Fri, Mar 31, 2023 at 10:22:49PM +0200, Hans Hagen via ntg-context wrote:
> > > On 3/31/2023 10:08 PM, Carlos via ntg-context wrote:
> > >
> > > > > sure, why should it, you want lucida so better quit with an error than
> > > > > kicking in some font; actually cmr math fonts have been obsoleted for
> > > > > way
> > > > > over a decade by latin modern math fonts in 32 bit font engines
> > >
> > > Font loading and processing time can be mosty neglected so these 16
> > > seconds
> > > come from something else, maybe there are ways to trace file access.
> > > Another
> > > possibility is that your fonts are not cached in which case every run will
> > > involve parsing the otf / ttf and producing whatever resources needed
> > > (normally cached).
> >
> > interesting. Earlier as the output was showing
> >
> > > mkiv lua stats > loaded patterns: en::1, load time: 0.000
> > > mkiv lua stats > loaded fonts: 4 files: lucidabrightregular.otf,
> > > lucidasansregular.otf, latinmodern-math.otf, lmroman10-regular.otf
> >
> > you asked
> >
> > > so why not use lucida math fonts?
> >
> > which is a valid question but nevertheless unsettling in that
> > lmodern-regular may nat have been called out. I fully understand the
> > inclusion of a latinmodern-math in it as a lucidamath was not previously
> > available but I ponder at the idea and involuntary implementation of
> > having lmroman along the pack. Why? If this is TeX doings, or misdoings
> > (depending how one looks at it), it clearly shows to me that TeX also
> > restricts my freedom to use whatever font I may deem necessary. Don't you
> > think? You can probably disagree with me here, or anyone from the TeX
> > community can, but the roman last was imposed deliberately upon. Someoe may
> > also give a lengthy explanation but that would be just hogwash in thee very
> > end .
>
> The fact that a file is loaded doesn't mean that it is used. In fact there
> is some fallback loading going on because explaining when nothing gets
> typeset or why \nullfont is used which results in missing chars messages is
> a waste of time.
>
> It has nothing to do with restrictions: tex will load any font you want it.
> But for instance when you turn on some tracing the macro package can load a
> font it needs. Indirectly you get what you ask for.
>
You're right about that. My mistake. Somehow monospaced had been previously
defined and I hadn't even noticed it .
I think I got it (sort of) figured for what I want it so far.
The latest stats are
mkiv lua stats > loaded fonts: 5 files: latinmodern-math.otf,
lucidabrightdemiitalic.otf, lucidabrightitalic.otf, lucidabrightregular.otf,
lucidasansregular.otf
mkiv lua stats > font engine: otf 3.133, afm 1.513, tfm 1.000, 17 instances,
10 shared in backend, 3 common vectors, 7 common hashes, load time 0.413
seconds
mkiv lua stats > math tweaking time: 0.162 seconds, 24 math goodie tables
which is pretty much what I was looking for, except the math font issue. Thank
you!
While I was trying to play with it a bit, I noticed a problem with the tfb and
tfc resizing in math mode
The only mention of anything similar happened back in 2009 (but then again this
was with mkii). There may be more similar issues in the list. I just didn't
have the time to look for it.
https://www.mail-archive.com/ntg-context@ntg.nl/msg40224.html
But anyhow, the following did the trick , which I found it convenient really.
But I don't use math mode, although someone else might, it's intuitive, and
does the job
\startmidaligned
$\tfc a + \overbracket{b + c} + \underbracket{d + e} + \doublebracket{f + g} +
h$
\stopmidaligned
\startformula
\int_{\infty}
\stopformula
> I bet you didn't explicitly ask for e.g. english hyphentation patterns
> either but still got them, but tex will happily let you use polish ones
> instead.
>
> Of course the best remedy against any automatism is to just start with
> initex and implement from scratch.
>
> In the above case: just add \type {foo} and you might see another font you
> didn't ask for / set up.
>
> > > > I was actually thinking to ask you about that, and by falling back to
> > > > cmr math font that perhaps would expedite loading time along the way.
> > >
> > > These fonts are small (only huge cjk fonts with tens of thousands of
> > > glyphs
> > > or fonts with hundreds of accumulated features might have some impact but
> > > even then not in the final embedding stage).
> >
> > Yeah. I guess.
> >
> > I can also have
> >
> > mkiv lua stats > loaded patterns: en::1, load time: 0.000
> > mkiv lua stats > loaded fonts: 3 files: lucidabrightmathsymbol.ttf,
> > lucidanewmathitalic.ttf, lucidabrightregular.otf
> > mkiv lua stats > font engine: otf 3.133, afm 1.513, tfm 1.000, 6
> > instances, 3 shared in backend, 1 common
Re: [NTG-context] registered function call [1160]:...live/2023/texmf-dist/tex/context/base/mkiv/l-sandbox.lua:87: cannot open /.: Permission denied - Alpine Linux
On 4/1/2023 11:21 PM, Carlos via ntg-context wrote:
On Fri, Mar 31, 2023 at 10:22:49PM +0200, Hans Hagen via ntg-context wrote:
On 3/31/2023 10:08 PM, Carlos via ntg-context wrote:
sure, why should it, you want lucida so better quit with an error than
kicking in some font; actually cmr math fonts have been obsoleted for way
over a decade by latin modern math fonts in 32 bit font engines
Font loading and processing time can be mosty neglected so these 16 seconds
come from something else, maybe there are ways to trace file access. Another
possibility is that your fonts are not cached in which case every run will
involve parsing the otf / ttf and producing whatever resources needed
(normally cached).
interesting. Earlier as the output was showing
mkiv lua stats > loaded patterns: en::1, load time: 0.000
mkiv lua stats > loaded fonts: 4 files: lucidabrightregular.otf,
lucidasansregular.otf, latinmodern-math.otf, lmroman10-regular.otf
you asked
so why not use lucida math fonts?
which is a valid question but nevertheless unsettling in that lmodern-regular
may nat have been called out. I fully understand the inclusion of a
latinmodern-math in it as a lucidamath was not previously available but I
ponder at the idea and involuntary implementation of having lmroman along the
pack. Why? If this is TeX doings, or misdoings (depending how one looks at it),
it clearly shows to me that TeX also restricts my freedom to use whatever font
I may deem necessary. Don't you think? You can probably disagree with me here,
or anyone from the TeX community can, but the roman last was imposed
deliberately upon. Someoe may also give a lengthy explanation but that would be
just hogwash in thee very end .
The fact that a file is loaded doesn't mean that it is used. In fact
there is some fallback loading going on because explaining when nothing
gets typeset or why \nullfont is used which results in missing chars
messages is a waste of time.
It has nothing to do with restrictions: tex will load any font you want
it. But for instance when you turn on some tracing the macro package can
load a font it needs. Indirectly you get what you ask for.
I bet you didn't explicitly ask for e.g. english hyphentation patterns
either but still got them, but tex will happily let you use polish ones
instead.
Of course the best remedy against any automatism is to just start with
initex and implement from scratch.
In the above case: just add \type {foo} and you might see another font
you didn't ask for / set up.
I was actually thinking to ask you about that, and by falling back to cmr math
font that perhaps would expedite loading time along the way.
These fonts are small (only huge cjk fonts with tens of thousands of glyphs
or fonts with hundreds of accumulated features might have some impact but
even then not in the final embedding stage).
Yeah. I guess.
I can also have
mkiv lua stats > loaded patterns: en::1, load time: 0.000
mkiv lua stats > loaded fonts: 3 files: lucidabrightmathsymbol.ttf,
lucidanewmathitalic.ttf, lucidabrightregular.otf
mkiv lua stats > font engine: otf 3.133, afm 1.513, tfm 1.000, 6 instances, 3
shared in backend, 1 common vectors, 2 common hashes, load time 16.723 seconds
but that loading time gets back at me as the culprit sweet reminder of not
using cmr then.
i won't comment because (i verified) that lucidabrightmathsymbol.ttf and
lucidanewmathitalic.ttf are illegal copies (if created on someones
machine from the typeone its all up to that user).
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | 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 / https://www.ntg.nl/mailman/listinfo/ntg-context
webpage : https://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : https://contextgarden.net
___
Re: [NTG-context] registered function call [1160]:...live/2023/texmf-dist/tex/context/base/mkiv/l-sandbox.lua:87: cannot open /.: Permission denied - Alpine Linux
On Fri, Mar 31, 2023 at 10:22:49PM +0200, Hans Hagen via ntg-context wrote: > On 3/31/2023 10:08 PM, Carlos via ntg-context wrote: > > > > sure, why should it, you want lucida so better quit with an error than > > > kicking in some font; actually cmr math fonts have been obsoleted for way > > > over a decade by latin modern math fonts in 32 bit font engines > > Font loading and processing time can be mosty neglected so these 16 seconds > come from something else, maybe there are ways to trace file access. Another > possibility is that your fonts are not cached in which case every run will > involve parsing the otf / ttf and producing whatever resources needed > (normally cached). interesting. Earlier as the output was showing > mkiv lua stats > loaded patterns: en::1, load time: 0.000 > mkiv lua stats > loaded fonts: 4 files: lucidabrightregular.otf, > lucidasansregular.otf, latinmodern-math.otf, lmroman10-regular.otf you asked > so why not use lucida math fonts? which is a valid question but nevertheless unsettling in that lmodern-regular may nat have been called out. I fully understand the inclusion of a latinmodern-math in it as a lucidamath was not previously available but I ponder at the idea and involuntary implementation of having lmroman along the pack. Why? If this is TeX doings, or misdoings (depending how one looks at it), it clearly shows to me that TeX also restricts my freedom to use whatever font I may deem necessary. Don't you think? You can probably disagree with me here, or anyone from the TeX community can, but the roman last was imposed deliberately upon. Someoe may also give a lengthy explanation but that would be just hogwash in thee very end . > > > I was actually thinking to ask you about that, and by falling back to cmr > > math font that perhaps would expedite loading time along the way. > > These fonts are small (only huge cjk fonts with tens of thousands of glyphs > or fonts with hundreds of accumulated features might have some impact but > even then not in the final embedding stage). Yeah. I guess. I can also have mkiv lua stats > loaded patterns: en::1, load time: 0.000 mkiv lua stats > loaded fonts: 3 files: lucidabrightmathsymbol.ttf, lucidanewmathitalic.ttf, lucidabrightregular.otf mkiv lua stats > font engine: otf 3.133, afm 1.513, tfm 1.000, 6 instances, 3 shared in backend, 1 common vectors, 2 common hashes, load time 16.723 seconds but that loading time gets back at me as the culprit sweet reminder of not using cmr then. You know the story by now Hans. I can load any font but not speed things up. Not without going through cmr. It is what it is. > > Whan talking fonts, enabling for instance expansion (hz) and protusion might > increase runtime a little. In practice, enabling for instance synctex has a > bigger imnpacts on performance than handling fonts. > Hans > > - > Hans Hagen | PRAGMA ADE > Ridderstraat 27 | 8061 GH Hasselt | The Netherlands >tel: 038 477 53 69 | www.pragma-ade.nl | 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 / > https://www.ntg.nl/mailman/listinfo/ntg-context > webpage : https://www.pragma-ade.nl / http://context.aanhet.net > archive : https://bitbucket.org/phg/context-mirror/commits/ > wiki : https://contextgarden.net > ___ -- There's got to be more to life than compile-and-go. ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / https://www.ntg.nl/mailman/listinfo/ntg-context webpage : https://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : https://contextgarden.net ___
Re: [NTG-context] registered function call [1160]:...live/2023/texmf-dist/tex/context/base/mkiv/l-sandbox.lua:87: cannot open /.: Permission denied - Alpine Linux
On 3/31/2023 10:08 PM, Carlos via ntg-context wrote: sure, why should it, you want lucida so better quit with an error than kicking in some font; actually cmr math fonts have been obsoleted for way over a decade by latin modern math fonts in 32 bit font engines Font loading and processing time can be mosty neglected so these 16 seconds come from something else, maybe there are ways to trace file access. Another possibility is that your fonts are not cached in which case every run will involve parsing the otf / ttf and producing whatever resources needed (normally cached). I was actually thinking to ask you about that, and by falling back to cmr math font that perhaps would expedite loading time along the way. These fonts are small (only huge cjk fonts with tens of thousands of glyphs or fonts with hundreds of accumulated features might have some impact but even then not in the final embedding stage). Whan talking fonts, enabling for instance expansion (hz) and protusion might increase runtime a little. In practice, enabling for instance synctex has a bigger imnpacts on performance than handling fonts. Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | 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 / https://www.ntg.nl/mailman/listinfo/ntg-context webpage : https://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : https://contextgarden.net ___
Re: [NTG-context] registered function call [1160]:...live/2023/texmf-dist/tex/context/base/mkiv/l-sandbox.lua:87: cannot open /.: Permission denied - Alpine Linux
On Fri, Mar 31, 2023 at 04:40:27PM +0200, Hans Hagen via ntg-context wrote: > On 3/31/2023 1:40 PM, Carlos via ntg-context wrote: > > > > so why not use lucida math fonts? > > > > I have. But only with a couple of math fonts. I don't have all these fonts. > > It really pays off to buy the official lucida opentype package. I'll do that eventually. > > > mkiv lua stats > loaded fonts: 3 files: lucidanewmathitalic.ttf, > > lucidanewmathsymbol.ttf, lucidabrightregular.otf > > mkiv lua stats > font engine: otf 3.133, afm 1.513, tfm 1.000, 6 > > instances, 3 shared in backend, 1 common vectors, 2 common hashes, load > > time 16.733 seconds > > I never heard of these math ones. Did you get these from yandytex (no longer > around) or TUG (the official distributer of lucida opentype math)? Anyway, > as we fine tune math fonts for sure you get suboptimal results (or even > wrong output). Mikael and I put quite a bit of care into lucida opentype > math. > > > I do agree with you in that that loading time is perhaps unacceptable but… > > ... > > You ought to specify that must be only after subsequent callbacks. I just > > tried it with a one liner file of \setupbodyfont[lucida] and (looking > > around in disbelief) it took a whooping ahem > > fonts > names > skipped files: 164 > > fonts > names > duplicate files : 164 > > fonts > names > total scan time : 16.487 seconds > > I have no clue, unless that relates to your font path including some home > dir which gets scanned every time for whatever reason and that has tens of > thousands of files. I can process the 350+ page luametatex manual twice in > these 16 seconds and that one loads quite some (also math) fonts and my > laptop is not a fancy 2023 one > > > before it produced even error messages. > > > > beating me for 2 seconds. Great. And then it restricted my freedom by saying > > > > «Sorry, but I can't typeset math unless various parameters have been set. > > This is > > normally done by loading special math fonts into the math family slots. > > Your font > > set is lacking at least the parameter mentioned earlier.» > > that's pretty clear: you don't load a math font at all, maybe some text font > pretending it is math > > > Sorry, but sorry doesn't cut it here. > > it does: no proper math font found so reason to complain > > > I guess it must have been referring to \strc_formulas_place_number > > \strc_formulas_flush_number \dostarttagged \t!formulacontent \empty > > \dotagregisterformula \c_strc_formulas_n \csname \e!stop \formulaparameter > > \c!alternative \v!formula \endcsname > > dunno, that's numbering, not math > > > Okay. So I tried another file. This time around with only > > > > \setupbodyfont[lucida] > > > > \starttext > > $ test $ > > \stoptext > > > > and then the output message was «Somewhere in the math formula just ended, > > you used the stated character from an > > undefined font family. For example, plain TeX doesn't allow \it or \sl in > > subscripts. Proceed, and I'll try to forget that I needed that character.» > > > > There's not even a fallback to cmr or any other font. > > sure, why should it, you want lucida so better quit with an error than > kicking in some font; actually cmr math fonts have been obsoleted for way > over a decade by latin modern math fonts in 32 bit font engines I was actually thinking to ask you about that, and by falling back to cmr math font that perhaps would expedite loading time along the way. Thank you for the info on that last sentence. I didn't know. > > > There was not even a personalized touch in the output. That message sounds > > like one of these new GPT-chat features. Dry. When I read that «Proceed, > > and I'll try to forget it…» part the first thing I thought was: yeah, I'll > > proceed by removing that file altogether and you'll forget it for sure . > > that message is part of 'reference tex the program' for over 40 years so if > chatgpt would come up with it, it would do so by having parsed plenty of tex > sources instead of inventing it (and when it comes to answering tex related > questions chargpt is pretty unreliable, but that's another topic) > > > But instaed I looked at it and though to myself «how much has changed?!» In > > plain TeX (I have forgotten it a bit) but I can still type > > > \par > > > $test$ > > > \end > > > > and it'll produce a dvi file in return. > > a lot has changed: opentype math, unicode, more demands but indeed there is > nothing against using plain tex with cmr and dvi fonts if that suits well; > and plain tex will always be faster than context (or latex) just like pdftex > with 8 bit fonts is faster than luatex with 32 bit fonts (with luametatex > sitting in between wrt performance) > anyway, i bet that if you want to use lucida with plain you also have to do > some work and it will complain as loud as luametatex when th efont > parameters are not set > At this
Re: [NTG-context] registered function call [1160]:...live/2023/texmf-dist/tex/context/base/mkiv/l-sandbox.lua:87: cannot open /.: Permission denied - Alpine Linux
On 3/31/2023 1:40 PM, Carlos via ntg-context wrote: so why not use lucida math fonts? I have. But only with a couple of math fonts. I don't have all these fonts. It really pays off to buy the official lucida opentype package. mkiv lua stats > loaded fonts: 3 files: lucidanewmathitalic.ttf, lucidanewmathsymbol.ttf, lucidabrightregular.otf mkiv lua stats > font engine: otf 3.133, afm 1.513, tfm 1.000, 6 instances, 3 shared in backend, 1 common vectors, 2 common hashes, load time 16.733 seconds I never heard of these math ones. Did you get these from yandytex (no longer around) or TUG (the official distributer of lucida opentype math)? Anyway, as we fine tune math fonts for sure you get suboptimal results (or even wrong output). Mikael and I put quite a bit of care into lucida opentype math. I do agree with you in that that loading time is perhaps unacceptable but… > ... You ought to specify that must be only after subsequent callbacks. I just tried it with a one liner file of \setupbodyfont[lucida] and (looking around in disbelief) it took a whooping ahem fonts > names > skipped files: 164 fonts > names > duplicate files : 164 fonts > names > total scan time : 16.487 seconds I have no clue, unless that relates to your font path including some home dir which gets scanned every time for whatever reason and that has tens of thousands of files. I can process the 350+ page luametatex manual twice in these 16 seconds and that one loads quite some (also math) fonts and my laptop is not a fancy 2023 one before it produced even error messages. beating me for 2 seconds. Great. And then it restricted my freedom by saying «Sorry, but I can't typeset math unless various parameters have been set. This is normally done by loading special math fonts into the math family slots. Your font set is lacking at least the parameter mentioned earlier.» that's pretty clear: you don't load a math font at all, maybe some text font pretending it is math Sorry, but sorry doesn't cut it here. it does: no proper math font found so reason to complain I guess it must have been referring to \strc_formulas_place_number \strc_formulas_flush_number \dostarttagged \t!formulacontent \empty \dotagregisterformula \c_strc_formulas_n \csname \e!stop \formulaparameter \c!alternative \v!formula \endcsname dunno, that's numbering, not math Okay. So I tried another file. This time around with only \setupbodyfont[lucida] \starttext $ test $ \stoptext and then the output message was «Somewhere in the math formula just ended, you used the stated character from an undefined font family. For example, plain TeX doesn't allow \it or \sl in subscripts. Proceed, and I'll try to forget that I needed that character.» There's not even a fallback to cmr or any other font. sure, why should it, you want lucida so better quit with an error than kicking in some font; actually cmr math fonts have been obsoleted for way over a decade by latin modern math fonts in 32 bit font engines There was not even a personalized touch in the output. That message sounds like one of these new GPT-chat features. Dry. When I read that «Proceed, and I'll try to forget it…» part the first thing I thought was: yeah, I'll proceed by removing that file altogether and you'll forget it for sure . that message is part of 'reference tex the program' for over 40 years so if chatgpt would come up with it, it would do so by having parsed plenty of tex sources instead of inventing it (and when it comes to answering tex related questions chargpt is pretty unreliable, but that's another topic) But instaed I looked at it and though to myself «how much has changed?!» In plain TeX (I have forgotten it a bit) but I can still type > \par > $test$ > \end and it'll produce a dvi file in return. a lot has changed: opentype math, unicode, more demands but indeed there is nothing against using plain tex with cmr and dvi fonts if that suits well; and plain tex will always be faster than context (or latex) just like pdftex with 8 bit fonts is faster than luatex with 32 bit fonts (with luametatex sitting in between wrt performance) anyway, i bet that if you want to use lucida with plain you also have to do some work and it will complain as loud as luametatex when th efont parameters are not set Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | 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 /
Re: [NTG-context] registered function call [1160]:...live/2023/texmf-dist/tex/context/base/mkiv/l-sandbox.lua:87: cannot open /.: Permission denied - Alpine Linux
On Wed, Mar 29, 2023 at 12:48:53AM +0200, Hans Hagen via ntg-context wrote: > On 3/28/2023 7:05 PM, Carlos via ntg-context wrote: > > On Mon, Mar 27, 2023 at 03:43:47PM +0200, Hans Hagen via ntg-context wrote: > > > On 3/27/2023 3:31 PM, Carlos via ntg-context wrote: > > > > > > > mkiv lua stats > loaded fonts: 4 files: latinmodern-math.otf, > > > > lmroman10-regular.otf, lucidabrightregular.ttf, lucidasansregular.ttf > > > > > > i admit never having seen lucida ttf files (but when opentype ttf files > > > are > > > used with an afm file present then no map files are needed at all because > > > we're in wide font mode and encidings are ignored) > > > > > > > I hadn't either. But everything aligned and thought it was nice. > > > > You're right that loading a map file is not needed, but If you're concerned > > about afm files then bring these files over to the working directory, and > > then mtxrun --generate the same > > > > So yes. Even though the file was something like (intended originally to > > load the map file, correct?) but since the map file is no longer necessary > > then afm should suffice > > > > \starttypescript [serif] [lucida] [texnansi] > > > > \definefontsynonym[LucidaBrightDemiBold][texnansi-lucidabrightdemibold][encoding=texnansi] > > > > \definefontsynonym[LucidaBrightDemiItalic][texnansi-lucidabrightdemiitalic][encoding=texnansi] > > > > \definefontsynonym[LucidaBrightItalic][texnansi-lucidabrightitalic][encoding=texnansi] > > > > \definefontsynonym[LucidaBrightRegular][texnansi-lucidabrightregular][encoding=texnansi] > > \stoptypescript > > these encodings only make sense with mkii (in which case the map file tells > pdftex if a ttf or pfb file is used) > > in mkiv encodings are ignored, when a ttf/otf file is used no afm is read, > and when a pfb fils is used the afm is used (ligature adn kerning info etc) > but a wide font is assembled > > (when a ttf is used the lucidaot typescript file can serve as example) > > in mkxl we assume the otf files sold by TUG are used (recently the math font > was updated) > > > and not with the file specification as in: > > > > > > \starttypescript [mylucidaserif] % or mylucidasans > >\definefontsynonym[LucidaBrightRegular][file:LucidaBrightRegular] > >\definefontsynonym[LucidaBrightItalic] [file:LucidaBrightItalic] > >\definefontsynonym[LucidaBrightBold] [file:LucidaBrightDemiBold] > > \stoptypescript > > > > and \setups[font:fallback:serif:sans] wouldn't be needed either > > > > you'd end up with > > in mkxl (lmtx) > > \setupbodyfont[lucida] > > will load open type definitions > > > mkiv lua stats > loaded patterns: en::1, load time: 0.000 > > mkiv lua stats > loaded fonts: 4 files: lucidabrightregular.otf, > > lucidasansregular.otf, latinmodern-math.otf, lmroman10-regular.otf > > so why not use lucida math fonts? I have. But only with a couple of math fonts. I don't have all these fonts. mkiv lua stats > loaded fonts: 3 files: lucidanewmathitalic.ttf, lucidanewmathsymbol.ttf, lucidabrightregular.otf mkiv lua stats > font engine: otf 3.133, afm 1.513, tfm 1.000, 6 instances, 3 shared in backend, 1 common vectors, 2 common hashes, load time 16.733 seconds I do agree with you in that that loading time is perhaps unacceptable but… > > > > > mkiv lua stats > font engine: otf 3.133, afm 1.513, tfm 1.000, 12 > > > > instances, 5 shared in backend, 3 common vectors, 2 common hashes, load > > > > time 16.898 seconds > > > > i assume that you don't get this 16 seconds load time each run > > > > You're correct. That's why you recommended to use otf first . > even with type one fonts 17 sec load time for a few fonts is not okay, i > expect more something like: > > mkiv lua stats > loaded fonts: 3 files: lucidabrightmathot.otf, > lucidabrightot.otf, lucidasansot.otf > mkiv lua stats > font engine: otf 3.133, afm 1.513, tfm 1.000, 14 > instances, 10 shared in backend, 6 common vectors, 4 common hashes, load > time 0.161 seconds You ought to specify that must be only after subsequent callbacks. I just tried it with a one liner file of \setupbodyfont[lucida] and (looking around in disbelief) it took a whooping ahem fonts > names > skipped files: 164 fonts > names > duplicate files : 164 fonts > names > total scan time : 16.487 seconds before it produced even error messages. beating me for 2 seconds. Great. And then it restricted my freedom by saying «Sorry, but I can't typeset math unless various parameters have been set. This is normally done by loading special math fonts into the math family slots. Your font set is lacking at least the parameter mentioned earlier.» Sorry, but sorry doesn't cut it here. I guess it must have been referring to \strc_formulas_place_number \strc_formulas_flush_number \dostarttagged \t!formulacontent \empty \dotagregisterformula \c_strc_formulas_n \csname \e!stop \formulaparameter
Re: [NTG-context] registered function call [1160]:...live/2023/texmf-dist/tex/context/base/mkiv/l-sandbox.lua:87: cannot open /.: Permission denied - Alpine Linux
On 3/28/2023 7:05 PM, Carlos via ntg-context wrote: On Mon, Mar 27, 2023 at 03:43:47PM +0200, Hans Hagen via ntg-context wrote: On 3/27/2023 3:31 PM, Carlos via ntg-context wrote: mkiv lua stats > loaded fonts: 4 files: latinmodern-math.otf, lmroman10-regular.otf, lucidabrightregular.ttf, lucidasansregular.ttf i admit never having seen lucida ttf files (but when opentype ttf files are used with an afm file present then no map files are needed at all because we're in wide font mode and encidings are ignored) I hadn't either. But everything aligned and thought it was nice. You're right that loading a map file is not needed, but If you're concerned about afm files then bring these files over to the working directory, and then mtxrun --generate the same So yes. Even though the file was something like (intended originally to load the map file, correct?) but since the map file is no longer necessary then afm should suffice \starttypescript [serif] [lucida] [texnansi] \definefontsynonym[LucidaBrightDemiBold][texnansi-lucidabrightdemibold][encoding=texnansi] \definefontsynonym[LucidaBrightDemiItalic][texnansi-lucidabrightdemiitalic][encoding=texnansi] \definefontsynonym[LucidaBrightItalic][texnansi-lucidabrightitalic][encoding=texnansi] \definefontsynonym[LucidaBrightRegular][texnansi-lucidabrightregular][encoding=texnansi] \stoptypescript these encodings only make sense with mkii (in which case the map file tells pdftex if a ttf or pfb file is used) in mkiv encodings are ignored, when a ttf/otf file is used no afm is read, and when a pfb fils is used the afm is used (ligature adn kerning info etc) but a wide font is assembled (when a ttf is used the lucidaot typescript file can serve as example) in mkxl we assume the otf files sold by TUG are used (recently the math font was updated) and not with the file specification as in: \starttypescript [mylucidaserif] % or mylucidasans \definefontsynonym[LucidaBrightRegular][file:LucidaBrightRegular] \definefontsynonym[LucidaBrightItalic] [file:LucidaBrightItalic] \definefontsynonym[LucidaBrightBold] [file:LucidaBrightDemiBold] \stoptypescript and \setups[font:fallback:serif:sans] wouldn't be needed either you'd end up with in mkxl (lmtx) \setupbodyfont[lucida] will load open type definitions mkiv lua stats > loaded patterns: en::1, load time: 0.000 mkiv lua stats > loaded fonts: 4 files: lucidabrightregular.otf, lucidasansregular.otf, latinmodern-math.otf, lmroman10-regular.otf so why not use lucida math fonts? mkiv lua stats > font engine: otf 3.133, afm 1.513, tfm 1.000, 12 instances, 5 shared in backend, 3 common vectors, 2 common hashes, load time 16.898 seconds i assume that you don't get this 16 seconds load time each run You're correct. That's why you recommended to use otf first . even with type one fonts 17 sec load time for a few fonts is not okay, i expect more something like: mkiv lua stats > loaded fonts: 3 files: lucidabrightmathot.otf, lucidabrightot.otf, lucidasansot.otf mkiv lua stats > font engine: otf 3.133, afm 1.513, tfm 1.000, 14 instances, 10 shared in backend, 6 common vectors, 4 common hashes, load time 0.161 seconds (so 100 times less load time here) Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | 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 / https://www.ntg.nl/mailman/listinfo/ntg-context webpage : https://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : https://contextgarden.net ___
Re: [NTG-context] registered function call [1160]:...live/2023/texmf-dist/tex/context/base/mkiv/l-sandbox.lua:87: cannot open /.: Permission denied - Alpine Linux
On Mon, Mar 27, 2023 at 03:43:47PM +0200, Hans Hagen via ntg-context wrote: > On 3/27/2023 3:31 PM, Carlos via ntg-context wrote: > > > mkiv lua stats > loaded fonts: 4 files: latinmodern-math.otf, > > lmroman10-regular.otf, lucidabrightregular.ttf, lucidasansregular.ttf > > i admit never having seen lucida ttf files (but when opentype ttf files are > used with an afm file present then no map files are needed at all because > we're in wide font mode and encidings are ignored) > I hadn't either. But everything aligned and thought it was nice. You're right that loading a map file is not needed, but If you're concerned about afm files then bring these files over to the working directory, and then mtxrun --generate the same So yes. Even though the file was something like (intended originally to load the map file, correct?) but since the map file is no longer necessary then afm should suffice \starttypescript [serif] [lucida] [texnansi] \definefontsynonym[LucidaBrightDemiBold][texnansi-lucidabrightdemibold][encoding=texnansi] \definefontsynonym[LucidaBrightDemiItalic][texnansi-lucidabrightdemiitalic][encoding=texnansi] \definefontsynonym[LucidaBrightItalic][texnansi-lucidabrightitalic][encoding=texnansi] \definefontsynonym[LucidaBrightRegular][texnansi-lucidabrightregular][encoding=texnansi] \stoptypescript \starttypescript [sans] [lucida] [texnansi] \definefontsynonym[LucidaSansDemiBold][texnansi-lucidasansdemibold][encoding=texnansi] \definefontsynonym[LucidaSansDemiOblique][texnansi-lucidasansdemioblique][encoding=texnansi] \definefontsynonym[LucidaSansOblique][texnansi-lucidasansoblique][encoding=texnansi] \definefontsynonym[LucidaSansRegular][texnansi-lucidasansregular][encoding=texnansi] \stoptypescript \starttypescript [mono] [lucida] [texnansi] \definefontsynonym[LucidaSansTypewriterBold][texnansi-lucidatypewriterbold][encoding=texnansi] \definefontsynonym[LucidaSansTypewriterBoldOblique][texnansi-lucidayypewriterboldoblique][encoding=texnansi] \definefontsynonym[LucidaSansTypewriterOblique][texnansi-lucidatypewriteroblique][encoding=texnansi] \definefontsynonym[LucidaSansTypewriterRegular][texnansi-lucidatypewriterregular][encoding=texnansi] \stoptypescript \starttypescript [serif] [lucida] [name] \usetypescript[serif][fallback] \definefontsynonym[Serif] [LucidaBrightRegular] \definefontsynonym[SerifBold] [LucidaBrightDemi] \definefontsynonym[SerifItalic][LucidaBrightItalic] \definefontsynonym[SerifBoldItalic][LucidaBrightDemiItalic] \stoptypescript \starttypescript [sans] [lucida] [name] \usetypescript[sans][fallback] \definefontsynonym[Sans][LucidaSansRegular] \definefontsynonym[SansItalic] [LucidaSansOblique] \definefontsynonym[SansBold][LucidaSansDemiBold] \definefontsynonym[SansBoldItalic] [LucidaSansDemiOblique] \stoptypescript \starttypescript [mono] [lucida] [name] \usetypescript[mono][fallback] \definefontsynonym[Mono] [LucidaSansTypewriterRegular] \definefontsynonym[MonoItalic] [LucidaSansTypewriterOblique] \definefontsynonym[MonoBold][LucidaSansTypewriterBold] \definefontsynonym[MonoBoldItalic] [LucidaSansTypewriterBoldOblique] \stoptypescript \starttypescript [Lucida] \definetypeface[MyLucida][rm][serif][lucida][default][encoding=texnansi] \definetypeface[MyLucida][ss][sans][lucida][default][encoding=texnansi] \definetypeface[MyLucida][tt][mono][lucida][default][encoding=texnansi] \stoptypescript and not with the file specification as in: \starttypescript [mylucidaserif] % or mylucidasans \definefontsynonym[LucidaBrightRegular][file:LucidaBrightRegular] \definefontsynonym[LucidaBrightItalic] [file:LucidaBrightItalic] \definefontsynonym[LucidaBrightBold] [file:LucidaBrightDemiBold] \stoptypescript and \setups[font:fallback:serif:sans] wouldn't be needed either you'd end up with mkiv lua stats > loaded patterns: en::1, load time: 0.000 mkiv lua stats > loaded fonts: 4 files: lucidabrightregular.otf, lucidasansregular.otf, latinmodern-math.otf, lmroman10-regular.otf mkiv lua stats > font engine: otf 3.133, afm 1.513, tfm 1.000, 12 instances, 5 shared in backend, 3 common vectors, 2 common hashes, load time 0.306 seconds mkiv lua stats > math tweaking time: 0.055 seconds, 12 math goodie tables > > mkiv lua stats > font engine: otf 3.133, afm 1.513, tfm 1.000, 12 > > instances, 5 shared in backend, 3 common vectors, 2 common hashes, load > > time 16.898 seconds > > mkiv lua stats > math tweaking time: 0.102 seconds, 12 math goodie tables > > mkiv lua stats > font embedding time: 0.004 seconds, 2 fonts > > i assume that you don't get this 16 seconds load time each
Re: [NTG-context] registered function call [1160]:...live/2023/texmf-dist/tex/context/base/mkiv/l-sandbox.lua:87: cannot open /.: Permission denied - Alpine Linux
On 3/27/2023 3:31 PM, Carlos via ntg-context wrote: mkiv lua stats > loaded fonts: 4 files: latinmodern-math.otf, lmroman10-regular.otf, lucidabrightregular.ttf, lucidasansregular.ttf i admit never having seen lucida ttf files (but when opentype ttf files are used with an afm file present then no map files are needed at all because we're in wide font mode and encidings are ignored) mkiv lua stats > font engine: otf 3.133, afm 1.513, tfm 1.000, 12 instances, 5 shared in backend, 3 common vectors, 2 common hashes, load time 16.898 seconds mkiv lua stats > math tweaking time: 0.102 seconds, 12 math goodie tables mkiv lua stats > font embedding time: 0.004 seconds, 2 fonts i assume that you don't get this 16 seconds load time each run Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | 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 / https://www.ntg.nl/mailman/listinfo/ntg-context webpage : https://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : https://contextgarden.net ___
Re: [NTG-context] registered function call [1160]:...live/2023/texmf-dist/tex/context/base/mkiv/l-sandbox.lua:87: cannot open /.: Permission denied - Alpine Linux
On Sat, Mar 25, 2023 at 09:26:36PM +0100, Hans Hagen via ntg-context wrote: > On 3/25/2023 8:55 PM, Carlos via ntg-context wrote: > > Hello list: > > > > This is under a fresh TeXLive installation. Sort as to put aside any > > texlive prepackaged issues. > > > > And the followign lines is the output of the error I've been having with > > the call of context on a recent texlive installation by both mtxrun > > --generate and luatools --generate right after. > > there i no need to use luatools (it's something old from the early days) > > what does > > mtxrun --generate --verbose > > report (whre does it fail) > > > 57 \starttext > > 58 > > 59 \usetypescriptfile[type-lucida] > > 60 \usetypescript[Lucida][texnansi] > > 61 >> \setupbodyfont[MyLucida, 10pt] > > 62 > > 63 \input zapf > > 64 > > 65 \input tufte > > fwiw, lucida type one makes no sense any more because the opentype version > is way better (and in the updated math setup in lmtx we didn't even look at > it) > > > Is LuaLaTeX behaving the same way? > > > > Answer: no. > > no surprise because it doesn't use the same setup > > what cache path does > > mtxrun --variables > > report > > Hans > > Thanks a lot Hans! Of course your sugggestion by using otf rather than going through the ttf as it may be deprecated works. No doubt. But look at the output of only a few lines.. This is exactly what I wanted to see!: system >6: filename=texnansi-bandh-lucida.map filetype=map format=map foundname=/usr/local/texlive/2023/texmf-local/fonts/map/pdftex/context/texnansi-bandh-lucida.map fullname=/usr/local/texlive/2023/texmf-local/fonts/map/pdftex/context/texnansi-bandh-lucida.map usedmethod=database system > 13: filename=/usr/local/texlive/2023/texmf-local/fonts/afm/bandh/lucida/LucidaBrightDemiBold.afm foundname=/usr/local/texlive/2023/texmf-local/fonts/afm/bandh/lucida/LucidaBrightDemiBold.afm fullname=/usr/local/texlive/2023/texmf-local/fonts/afm/bandh/lucida/LucidaBrightDemiBold.afm usedmethod=direct system > 14: filename=/usr/local/texlive/2023/texmf-local/fonts/afm/bandh/lucida/LucidaBrightDemiItalic.afm foundname=/usr/local/texlive/2023/texmf-local/fonts/afm/bandh/lucida/LucidaBrightDemiItalic.afm fullname=/usr/local/texlive/2023/texmf-local/fonts/afm/bandh/lucida/LucidaBrightDemiItalic.afm usedmethod=direct system > 15: filename=/usr/local/texlive/2023/texmf-local/fonts/afm/bandh/lucida/LucidaBrightItalic.afm foundname=/usr/local/texlive/2023/texmf-local/fonts/afm/bandh/lucida/LucidaBrightItalic.afm fullname=/usr/local/texlive/2023/texmf-local/fonts/afm/bandh/lucida/LucidaBrightItalic.afm usedmethod=direct system > 16: filename=/usr/local/texlive/2023/texmf-local/fonts/afm/bandh/lucida/LucidaBrightRegular.afm foundname=/usr/local/texlive/2023/texmf-local/fonts/afm/bandh/lucida/LucidaBrightRegular.afm fullname=/usr/local/texlive/2023/texmf-local/fonts/afm/bandh/lucida/LucidaBrightRegular.afm usedmethod=direct system > 17: filename=/usr/local/texlive/2023/texmf-local/fonts/afm/bandh/lucida/LucidaSansDemiBold.afm foundname=/usr/local/texlive/2023/texmf-local/fonts/afm/bandh/lucida/LucidaSansDemiBold.afm fullname=/usr/local/texlive/2023/texmf-local/fonts/afm/bandh/lucida/LucidaSansDemiBold.afm usedmethod=direct system > 18: filename=/usr/local/texlive/2023/texmf-local/fonts/afm/bandh/lucida/LucidaSansDemiOblique.afm foundname=/usr/local/texlive/2023/texmf-local/fonts/afm/bandh/lucida/LucidaSansDemiOblique.afm fullname=/usr/local/texlive/2023/texmf-local/fonts/afm/bandh/lucida/LucidaSansDemiOblique.afm usedmethod=direct system > 19: filename=/usr/local/texlive/2023/texmf-local/fonts/afm/bandh/lucida/LucidaSansOblique.afm foundname=/usr/local/texlive/2023/texmf-local/fonts/afm/bandh/lucida/LucidaSansOblique.afm fullname=/usr/local/texlive/2023/texmf-local/fonts/afm/bandh/lucida/LucidaSansOblique.afm usedmethod=direct system > 20: filename=/usr/local/texlive/2023/texmf-local/fonts/afm/bandh/lucida/LucidaSansRegular.afm foundname=/usr/local/texlive/2023/texmf-local/fonts/afm/bandh/lucida/LucidaSansRegular.afm fullname=/usr/local/texlive/2023/texmf-local/fonts/afm/bandh/lucida/LucidaSansRegular.afm usedmethod=direct system > 21: filename=/usr/local/texlive/2023/texmf-local/fonts/afm/bandh/lucida/LucidaTypewriterBold.afm foundname=/usr/local/texlive/2023/texmf-local/fonts/afm/bandh/lucida/LucidaTypewriterBold.afm fullname=/usr/local/texlive/2023/texmf-local/fonts/afm/bandh/lucida/LucidaTypewriterBold.afm usedmethod=direct system > 22: filename=/usr/local/texlive/2023/texmf-local/fonts/afm/bandh/lucida/LucidaTypewriterBoldOblique.afm foundname=/usr/local/texlive/2023/texmf-local/fonts/afm/bandh/lucida/LucidaTypewriterBoldOblique.afm
Re: [NTG-context] registered function call [1160]:...live/2023/texmf-dist/tex/context/base/mkiv/l-sandbox.lua:87: cannot open /.: Permission denied - Alpine Linux
On Sun, Mar 26, 2023 at 01:04:30PM +0200, Henning Hraban Ramm via ntg-context wrote: > Am 25.03.23 um 23:42 schrieb Carlos via ntg-context: > > > > > fonts | names | 3092 afm files checked, okay > > > > fonts | names | identifying tree font files with suffix 'AFM' > > > > fonts | names | scanning path > > > > '/home/ce/.texlive2023/texmf-config' for AFM files > > > > > fonts | names | variable 'OSFONTDIR' specifies path '/home/ce' > > > > fonts | names | variable 'OSFONTDIR' specifies path > > > > '/usr/share/fonts' > > > > fonts | names | globbing path '/home/ce/**.otf' > > There is something strange here. > Is maybe TEXMFHOME set? > > Since you use a TeX live installation, some other texmfcnf.lua or texmf.cnf > might interfere. > Look into /usr/local/texlive/2023/ > > Since it scans everything in your home directory, maybe TEXMFHOME or > OSFONTDIR is set to ~ (instead ~/texmf) there? > > Hraban I created an entirely different folder and placed the otf files right in it following Hans' advice on using directly otf rather than ttf The latter was used successfully under Void TeXLive prepackaged 2021 using a loadmapfile[texnansi-bandh-lucida.map] There was a texmfcnf.lua under the TEXMFLOCAL variable, and another one under TEXMFDIST. Got rid of the former but haven't tested it enough. Thanks for bringing it up! It compiled fine, saved some rendering presumably from missing a few otf files that I didn't have under Alpine. > ___ > If your question is of interest to others as well, please add an entry to the > Wiki! > > maillist : ntg-context@ntg.nl / > https://www.ntg.nl/mailman/listinfo/ntg-context > webpage : https://www.pragma-ade.nl / http://context.aanhet.net > archive : https://bitbucket.org/phg/context-mirror/commits/ > wiki : https://contextgarden.net > ___ -- !07/11 PDP a ni deppart m'I !pleH ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / https://www.ntg.nl/mailman/listinfo/ntg-context webpage : https://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : https://contextgarden.net ___
Re: [NTG-context] registered function call [1160]:...live/2023/texmf-dist/tex/context/base/mkiv/l-sandbox.lua:87: cannot open /.: Permission denied - Alpine Linux
On Sat, Mar 25, 2023 at 09:26:36PM +0100, Hans Hagen via ntg-context wrote: > On 3/25/2023 8:55 PM, Carlos via ntg-context wrote: > > Hello list: > > > > This is under a fresh TeXLive installation. Sort as to put aside any > > texlive prepackaged issues. > > > > And the followign lines is the output of the error I've been having with > > the call of context on a recent texlive installation by both mtxrun > > --generate and luatools --generate right after. > > there i no need to use luatools (it's something old from the early days) > > what does > > mtxrun --generate --verbose > > report (whre does it fail) > > > 57 \starttext > > 58 > > 59 \usetypescriptfile[type-lucida] > > 60 \usetypescript[Lucida][texnansi] > > 61 >> \setupbodyfont[MyLucida, 10pt] > > 62 > > 63 \input zapf > > 64 > > 65 \input tufte > > fwiw, lucida type one makes no sense any more because the opentype version > is way better (and in the updated math setup in lmtx we didn't even look at > it) > Hans, your advice for using otf fonts worked. Thanks. system > lua > compiling '/home/ce/.texlive2023/texmf-var/luametatex-cache/context/1b4da46d1f340757f9984eae810b1464/fonts/streams/lucidabrightregularotf-1.tma' into '/home/ce/.texlive2023/texmf-var/luametatex-cache/context/1b4da46d1f340757f9984eae810b1464/fonts/streams/lucidabrightregularotf-1.tmd' system > lua > dumping '/home/ce/.texlive2023/texmf-var/luametatex-cache/context/1b4da46d1f340757f9984eae810b1464/fonts/streams/lucidabrightregularotf-1.tma' into '/home/ce/.texlive2023/texmf-var/luametatex-cache/context/1b4da46d1f340757f9984eae810b1464/fonts/streams/lucidabrightregularotf-1.tmd' stripped Not how I wanted it originally as in Void Linux with texnansi encoding and a TeXLive2021 prepackaged mkiv lua stats > loaded fonts: 4 files: lucidabrightregular.otf, lucidasansregular.otf, latinmodern-math.otf, lmroman12-regular.otf mkiv lua stats > font engine: otf 3.113, afm 1.513, tfm 1.000, 12 instances, 6 shared in backend, 4 common vectors, 2 common hashes, load time 0.413 seconds mkiv lua stats > used platform: linux-64, type: unix, binary subtree: usr mkiv lua stats > used engine: luatex version: 1.13, functionality level: 7418, banner: this is luatex, version 1.13.0 (tex live 2021/voidlinux) mkiv lua stats > used hash slots: 48145 of 65536 + 20 mkiv lua stats > lua properties: engine: lua 5.3, used memory: 158 MB, ctx: 158 MB, max: unknown MB, hash chars: min(64,40), symbol mask: utf (τεχ) Or with otf under Alpine. but yes. otf rather than ttf backend > fonts > width units in 'SGVYNL+LucidaBright-Italic' are 2048, forcing 1000 instead backend > fonts > width units in 'QRVECH+LucidaBright' are 2048, forcing 1000 instead system > start used files system > text: atestinlucida-OTF system > stop used files system > start used files > > Is LuaLaTeX behaving the same way? > > > > Answer: no. > > no surprise because it doesn't use the same setup > > what cache path does > > mtxrun --variables > > report > > Hans > > > - > Hans Hagen | PRAGMA ADE > Ridderstraat 27 | 8061 GH Hasselt | The Netherlands >tel: 038 477 53 69 | www.pragma-ade.nl | 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 / > https://www.ntg.nl/mailman/listinfo/ntg-context > webpage : https://www.pragma-ade.nl / http://context.aanhet.net > archive : https://bitbucket.org/phg/context-mirror/commits/ > wiki : https://contextgarden.net > ___ -- The New Testament offers the basis for modern computer coding theory, in the form of an affirmation of the binary number system. But let your communication be Yea, yea; nay, nay: for whatsoever is more than these cometh of evil. -- Matthew 5:37 ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / https://www.ntg.nl/mailman/listinfo/ntg-context webpage : https://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : https://contextgarden.net ___
Re: [NTG-context] registered function call [1160]:...live/2023/texmf-dist/tex/context/base/mkiv/l-sandbox.lua:87: cannot open /.: Permission denied - Alpine Linux
On Sun, Mar 26, 2023 at 03:21:35PM +0200, Hans Hagen via ntg-context wrote: > On 3/26/2023 3:08 PM, Carlos via ntg-context wrote: > > On Sun, Mar 26, 2023 at 01:04:30PM +0200, Henning Hraban Ramm via > > ntg-context wrote: > > > Am 25.03.23 um 23:42 schrieb Carlos via ntg-context: > > > > > > > > > fonts | names | 3092 afm files checked, okay > > > > > > fonts | names | identifying tree font files with suffix > > > > > > 'AFM' > > > > > > fonts | names | scanning path > > > > > > '/home/ce/.texlive2023/texmf-config' for AFM files > > > > > > > > > fonts | names | variable 'OSFONTDIR' specifies path > > > > > > '/home/ce' > > > > > > fonts | names | variable 'OSFONTDIR' specifies path > > > > > > '/usr/share/fonts' > > > > > > fonts | names | globbing path '/home/ce/**.otf' > > > > > > There is something strange here. > > > Is maybe TEXMFHOME set? > > > > > > Since you use a TeX live installation, some other texmfcnf.lua or > > > texmf.cnf > > > might interfere. > > > Look into /usr/local/texlive/2023/ > > > > I'll check again to make sure. But keep in mind this issue predates the > > official TeX Live installation . I've been using the distro prepackaged for > > a while. And yes. It's always been there. Sort of like, it came with the > > system :) > > > > > > Since it scans everything in your home directory, maybe TEXMFHOME or > > > OSFONTDIR is set to ~ (instead ~/texmf) there? > > > > But even if there was a conflict, it wouldn't justify to be scanninp up > > everything viciously. > > Well, if fonts can be anywhere that means checking for them anywhere. TeX > installations have some directory setup for a reason. Imagine that you set > up the installation to include that wildcard path in TEXINPUITS then every > run that whole tree would get scanned for a file you ask for and that is not > in the current directory. The whole idea behind TDS and defining paths for > specific kind of files it to limit lookups. Hans, plesae… please, You know deep inside that the above paragraph does not make any sense even after writing it convincingly. The fact that fonts can be anywhere DOES NOT mean that a program whatever that program may be is following whatever TDS sets in place or is presumably setting in place.. or much less — regardless of fonts' location, that a program out there needs to act erratically. Careless. To say the least. Bear with me in this one (I'm just a bit tired): Look at the same issue from another system perspective. I said system perspective because simply put there is so much one can do whenever you're dealing with a multiuser program such as TeX Live. Bear wiht me here: I have Void Linux on a spare system. Let's put aside for a second the inconsistencies surrounding texmfcnf.lua there. We can get back to it later And there's plenty of it taht can also be said. Do you know what is the method used to handle this problem? By folder. If I were to invoke mtxrun --script cache --erase it should behave accordingly. Or I'd expect it to act accordingly. The same with mtxrun --script font --reload Of course, it doesn't help if texmfcnf.lua sets anything else by doing otherwise. Does it sound far-fetched? Maybe. But it certainly makes more sense than looking up everything under every imaginable worktree by which presumably there can be fonts. Which 100 percent of the time there's none. But What fonts are to be found on cache and headers folders? tfm, afm, otf? come on! But then again. Even in Void Linux (a system for which concurrent files lookups seem to be working now under the right expectations) threw errors back and forth with both context.lua mtx-context.lua and base.lua unknown scripts, before eventually getting it right. (that may be a misnomer) I ought to say I got it right, I guess. Were mtxrun --generate or mtxrun --script cache --erase called out? Of course. Which led me to read about that pesky behavior here for example: https://tug.org/pipermail/tex-live/2022-August/048375.html and similarly https://tex.stackexchange.com/questions/653913/context-from-texlive-2021-says-unknown-script-context-lua-or-mtx-context-lua But the above was put aside. And there soon followed a matter-of-fact «it's not broken in TeX Live» statement. Well. If looked at from that narow angle, yes, I guess. Recall this is with a prepackaged TeXLive or the one put out by the devs. And I was aware of that. Not the case here. I'm just mentioning it because that's the method used or what it's doing on that spare system as of now. Lookups for every folder. > > > So far I've had to move about 7-8 folders. About 6 of them are owned by > > root, the rest are owned by root but symlinked to user. > > I would not do that, instead I'd fix ny OSFONTDIR path. Even with some > directories moved you still end with plenty useless scanning. > I'm working on it. > > And to top it off, after doing so, it didn't
Re: [NTG-context] registered function call [1160]:...live/2023/texmf-dist/tex/context/base/mkiv/l-sandbox.lua:87: cannot open /.: Permission denied - Alpine Linux
On 3/26/2023 3:08 PM, Carlos via ntg-context wrote: On Sun, Mar 26, 2023 at 01:04:30PM +0200, Henning Hraban Ramm via ntg-context wrote: Am 25.03.23 um 23:42 schrieb Carlos via ntg-context: fonts | names | 3092 afm files checked, okay fonts | names | identifying tree font files with suffix 'AFM' fonts | names | scanning path '/home/ce/.texlive2023/texmf-config' for AFM files fonts | names | variable 'OSFONTDIR' specifies path '/home/ce' fonts | names | variable 'OSFONTDIR' specifies path '/usr/share/fonts' fonts | names | globbing path '/home/ce/**.otf' There is something strange here. Is maybe TEXMFHOME set? Since you use a TeX live installation, some other texmfcnf.lua or texmf.cnf might interfere. Look into /usr/local/texlive/2023/ I'll check again to make sure. But keep in mind this issue predates the official TeX Live installation . I've been using the distro prepackaged for a while. And yes. It's always been there. Sort of like, it came with the system :) Since it scans everything in your home directory, maybe TEXMFHOME or OSFONTDIR is set to ~ (instead ~/texmf) there? But even if there was a conflict, it wouldn't justify to be scanninp up everything viciously. Well, if fonts can be anywhere that means checking for them anywhere. TeX installations have some directory setup for a reason. Imagine that you set up the installation to include that wildcard path in TEXINPUITS then every run that whole tree would get scanned for a file you ask for and that is not in the current directory. The whole idea behind TDS and defining paths for specific kind of files it to limit lookups. So far I've had to move about 7-8 folders. About 6 of them are owned by root, the rest are owned by root but symlinked to user. I would not do that, instead I'd fix ny OSFONTDIR path. Even with some directories moved you still end with plenty useless scanning. And to top it off, after doing so, it didn't stop there, heck no, it also wanted to snoop in a folder with cache and headers. To be honest. I woudlnt' know what to make of it. If it's simply looking into the permissions of the directories first, or the fact that it has a colon separated pattern. But. Then again. The other folders didn't have it. I'll let you know. What if you use the regular context installation (not texlive) and see what that does? Maybe that gives a clue. (btw, the official texlive 2023 was tested on windows, linux and osx so there must be something special at your end.) Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | 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 / https://www.ntg.nl/mailman/listinfo/ntg-context webpage : https://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : https://contextgarden.net ___
Re: [NTG-context] registered function call [1160]:...live/2023/texmf-dist/tex/context/base/mkiv/l-sandbox.lua:87: cannot open /.: Permission denied - Alpine Linux
On Sun, Mar 26, 2023 at 01:04:30PM +0200, Henning Hraban Ramm via ntg-context wrote: > Am 25.03.23 um 23:42 schrieb Carlos via ntg-context: > > > > > fonts | names | 3092 afm files checked, okay > > > > fonts | names | identifying tree font files with suffix 'AFM' > > > > fonts | names | scanning path > > > > '/home/ce/.texlive2023/texmf-config' for AFM files > > > > > fonts | names | variable 'OSFONTDIR' specifies path '/home/ce' > > > > fonts | names | variable 'OSFONTDIR' specifies path > > > > '/usr/share/fonts' > > > > fonts | names | globbing path '/home/ce/**.otf' > > There is something strange here. > Is maybe TEXMFHOME set? > > Since you use a TeX live installation, some other texmfcnf.lua or texmf.cnf > might interfere. > Look into /usr/local/texlive/2023/ I'll check again to make sure. But keep in mind this issue predates the official TeX Live installation . I've been using the distro prepackaged for a while. And yes. It's always been there. Sort of like, it came with the system :) > > Since it scans everything in your home directory, maybe TEXMFHOME or > OSFONTDIR is set to ~ (instead ~/texmf) there? But even if there was a conflict, it wouldn't justify to be scanninp up everything viciously. So far I've had to move about 7-8 folders. About 6 of them are owned by root, the rest are owned by root but symlinked to user. And to top it off, after doing so, it didn't stop there, heck no, it also wanted to snoop in a folder with cache and headers. To be honest. I woudlnt' know what to make of it. If it's simply looking into the permissions of the directories first, or the fact that it has a colon separated pattern. But. Then again. The other folders didn't have it. I'll let you know. Thank you Hraban Carlos > Hraban > ___ > If your question is of interest to others as well, please add an entry to the > Wiki! > > maillist : ntg-context@ntg.nl / > https://www.ntg.nl/mailman/listinfo/ntg-context > webpage : https://www.pragma-ade.nl / http://context.aanhet.net > archive : https://bitbucket.org/phg/context-mirror/commits/ > wiki : https://contextgarden.net > ___ -- This file will self-destruct in five minutes. ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / https://www.ntg.nl/mailman/listinfo/ntg-context webpage : https://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : https://contextgarden.net ___
Re: [NTG-context] registered function call [1160]:...live/2023/texmf-dist/tex/context/base/mkiv/l-sandbox.lua:87: cannot open /.: Permission denied - Alpine Linux
Am 25.03.23 um 23:42 schrieb Carlos via ntg-context: fonts | names | 3092 afm files checked, okay fonts | names | identifying tree font files with suffix 'AFM' fonts | names | scanning path '/home/ce/.texlive2023/texmf-config' for AFM files fonts | names | variable 'OSFONTDIR' specifies path '/home/ce' fonts | names | variable 'OSFONTDIR' specifies path '/usr/share/fonts' fonts | names | globbing path '/home/ce/**.otf' There is something strange here. Is maybe TEXMFHOME set? Since you use a TeX live installation, some other texmfcnf.lua or texmf.cnf might interfere. Look into /usr/local/texlive/2023/ Since it scans everything in your home directory, maybe TEXMFHOME or OSFONTDIR is set to ~ (instead ~/texmf) there? Hraban ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / https://www.ntg.nl/mailman/listinfo/ntg-context webpage : https://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : https://contextgarden.net ___
Re: [NTG-context] registered function call [1160]:...live/2023/texmf-dist/tex/context/base/mkiv/l-sandbox.lua:87: cannot open /.: Permission denied - Alpine Linux
On Sat, Mar 25, 2023 at 11:09:18PM +0100, Hans Hagen via ntg-context wrote: > On 3/25/2023 10:36 PM, Carlos via ntg-context wrote: > > On Sat, Mar 25, 2023 at 09:45:25PM +0100, Hans Hagen via ntg-context wrote: > > > On 3/25/2023 8:55 PM, Carlos via ntg-context wrote: > > > > > > > > > > > ...xlive/2023/texmf-dist/tex/context/base/mkiv/font-syn.lua:1030: in > > > > upvalue 'walk_tree' > > > Maybe your OSFONTDIR is pointing to empty. Does > > > > Good call. Thank you for the reminder Hans. But no. That variable was set > > long ago . Even appended it to both the bash initialization file and also > > under /etc/profile (just in case here). Alpine uses ash so shells must be > > changed > > > > > > > >mtxrun --script font --reload > > > > > fonts | names | 3092 afm files checked, okay > > fonts | names | identifying tree font files with suffix 'AFM' > > fonts | names | scanning path > > '/home/ce/.texlive2023/texmf-config' for AFM files > > fonts | names | 0 AFM files checked, okay > > fonts | names | scanning path '/home/ce/texmf' for AFM files > > fonts | names | 0 AFM files checked, okay > > fonts | names | scanning path > > '/usr/local/texlive/2023/texmf-config' for AFM files > > fonts | names | 0 AFM files checked, okay > > fonts | names | scanning path '/usr/local/texlive/2023/texmf-var' > > for AFM files > > fonts | names | 0 AFM files checked, okay > > fonts | names | scanning path > > '/usr/local/texlive/2023/texmf-local' for AFM files > > fonts | names | 24 AFM files checked, okay > > fonts | names | scanning path > > '/usr/local/texlive/2023/texmf-dist' for AFM files > > fonts | names | 3092 AFM files checked, okay > > fonts | names | 6232 tree files identified, 14 skipped, 14 > > duplicates, 6218 hash entries added, runtime 8.458 seconds > > fonts | names | identifying system font files with suffix 'otf' > > fonts | names | variable 'OSFONTDIR' specifies path '/home/ce' > > fonts | names | variable 'OSFONTDIR' specifies path > > '/usr/share/fonts' > > fonts | names | globbing path '/home/ce/**.otf' > > > > lua error : function call: > > /usr/local/texlive/2023/bin/x86_64-linuxmusl/mtxrun.lua:649: cannot open > > /home/ce/cache/headers/imaps:@gmail@imap.gmail.com/[Gmail]/.: > > Permission denied > > hm, but is home/ce/cache a path where there are fonts to be found? something Not to my knownledge. It's just that that particular folder only has root permissions and not for the user. Recursively that is. Like you said. Only not with fonts. > sets that path to be a fully recursive font dir > > can you set OSFONTDIR to '/usr/share/fonts' > it's already set echo $OSFONTDIR /usr/share/fonts > (personally i never use system fonts, i always put copies in > texmf-fonts/fonts/data becasue system fonts can change or disappear) > I'll probably do that. > > Recall that the other folders owned by root had to be moved out of the way > > > > So it seems it wasn't enough, nope. Now it wants access elsewhere > > > > bottom line: it wants root permissions or else fails flat out > > well, it's not entirely clear what generates the permission denied; i can > check for the home/ce being readable but doing that for every regular file > below that would add lots of slow checks and i'm not even sure if it would > fix it; i can try to check nested dirs but that then also obscures possible > issues You would know better than I do here. I somehow postponed this current issue thinking that a fresh TeX Live installation would resolve it once and for all. But no. > > Hans > - > Hans Hagen | PRAGMA ADE > Ridderstraat 27 | 8061 GH Hasselt | The Netherlands >tel: 038 477 53 69 | www.pragma-ade.nl | 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 / > https://www.ntg.nl/mailman/listinfo/ntg-context > webpage : https://www.pragma-ade.nl / http://context.aanhet.net > archive : https://bitbucket.org/phg/context-mirror/commits/ > wiki : https://contextgarden.net > ___ -- ASHes to ASHes, DOS to DOS. ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / https://www.ntg.nl/mailman/listinfo/ntg-context webpage : https://www.pragma-ade.nl / http://context.aanhet.net
Re: [NTG-context] registered function call [1160]:...live/2023/texmf-dist/tex/context/base/mkiv/l-sandbox.lua:87: cannot open /.: Permission denied - Alpine Linux
On 3/25/2023 10:36 PM, Carlos via ntg-context wrote: On Sat, Mar 25, 2023 at 09:45:25PM +0100, Hans Hagen via ntg-context wrote: On 3/25/2023 8:55 PM, Carlos via ntg-context wrote: ...xlive/2023/texmf-dist/tex/context/base/mkiv/font-syn.lua:1030: in upvalue 'walk_tree' Maybe your OSFONTDIR is pointing to empty. Does Good call. Thank you for the reminder Hans. But no. That variable was set long ago . Even appended it to both the bash initialization file and also under /etc/profile (just in case here). Alpine uses ash so shells must be changed mtxrun --script font --reload fonts | names | 3092 afm files checked, okay fonts | names | identifying tree font files with suffix 'AFM' fonts | names | scanning path '/home/ce/.texlive2023/texmf-config' for AFM files fonts | names | 0 AFM files checked, okay fonts | names | scanning path '/home/ce/texmf' for AFM files fonts | names | 0 AFM files checked, okay fonts | names | scanning path '/usr/local/texlive/2023/texmf-config' for AFM files fonts | names | 0 AFM files checked, okay fonts | names | scanning path '/usr/local/texlive/2023/texmf-var' for AFM files fonts | names | 0 AFM files checked, okay fonts | names | scanning path '/usr/local/texlive/2023/texmf-local' for AFM files fonts | names | 24 AFM files checked, okay fonts | names | scanning path '/usr/local/texlive/2023/texmf-dist' for AFM files fonts | names | 3092 AFM files checked, okay fonts | names | 6232 tree files identified, 14 skipped, 14 duplicates, 6218 hash entries added, runtime 8.458 seconds fonts | names | identifying system font files with suffix 'otf' fonts | names | variable 'OSFONTDIR' specifies path '/home/ce' fonts | names | variable 'OSFONTDIR' specifies path '/usr/share/fonts' fonts | names | globbing path '/home/ce/**.otf' lua error : function call: /usr/local/texlive/2023/bin/x86_64-linuxmusl/mtxrun.lua:649: cannot open /home/ce/cache/headers/imaps:@gmail@imap.gmail.com/[Gmail]/.: Permission denied hm, but is home/ce/cache a path where there are fonts to be found? something sets that path to be a fully recursive font dir can you set OSFONTDIR to '/usr/share/fonts' (personally i never use system fonts, i always put copies in texmf-fonts/fonts/data becasue system fonts can change or disappear) Recall that the other folders owned by root had to be moved out of the way So it seems it wasn't enough, nope. Now it wants access elsewhere bottom line: it wants root permissions or else fails flat out well, it's not entirely clear what generates the permission denied; i can check for the home/ce being readable but doing that for every regular file below that would add lots of slow checks and i'm not even sure if it would fix it; i can try to check nested dirs but that then also obscures possible issues Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | 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 / https://www.ntg.nl/mailman/listinfo/ntg-context webpage : https://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : https://contextgarden.net ___
Re: [NTG-context] registered function call [1160]:...live/2023/texmf-dist/tex/context/base/mkiv/l-sandbox.lua:87: cannot open /.: Permission denied - Alpine Linux
On Sat, Mar 25, 2023 at 09:45:25PM +0100, Hans Hagen via ntg-context wrote: > On 3/25/2023 8:55 PM, Carlos via ntg-context wrote: > > > ...xlive/2023/texmf-dist/tex/context/base/mkiv/font-syn.lua:1030: > > in upvalue 'walk_tree' > Maybe your OSFONTDIR is pointing to empty. Does Good call. Thank you for the reminder Hans. But no. That variable was set long ago . Even appended it to both the bash initialization file and also under /etc/profile (just in case here). Alpine uses ash so shells must be changed > > mtxrun --script font --reload > fonts | names | 3092 afm files checked, okay fonts | names | identifying tree font files with suffix 'AFM' fonts | names | scanning path '/home/ce/.texlive2023/texmf-config' for AFM files fonts | names | 0 AFM files checked, okay fonts | names | scanning path '/home/ce/texmf' for AFM files fonts | names | 0 AFM files checked, okay fonts | names | scanning path '/usr/local/texlive/2023/texmf-config' for AFM files fonts | names | 0 AFM files checked, okay fonts | names | scanning path '/usr/local/texlive/2023/texmf-var' for AFM files fonts | names | 0 AFM files checked, okay fonts | names | scanning path '/usr/local/texlive/2023/texmf-local' for AFM files fonts | names | 24 AFM files checked, okay fonts | names | scanning path '/usr/local/texlive/2023/texmf-dist' for AFM files fonts | names | 3092 AFM files checked, okay fonts | names | 6232 tree files identified, 14 skipped, 14 duplicates, 6218 hash entries added, runtime 8.458 seconds fonts | names | identifying system font files with suffix 'otf' fonts | names | variable 'OSFONTDIR' specifies path '/home/ce' fonts | names | variable 'OSFONTDIR' specifies path '/usr/share/fonts' fonts | names | globbing path '/home/ce/**.otf' lua error : function call: /usr/local/texlive/2023/bin/x86_64-linuxmusl/mtxrun.lua:649: cannot open /home/ce/cache/headers/imaps:@gmail@imap.gmail.com/[Gmail]/.: Permission denied Recall that the other folders owned by root had to be moved out of the way So it seems it wasn't enough, nope. Now it wants access elsewhere bottom line: it wants root permissions or else fails flat out Even with sudo privileges the best it can do is: resolvers | formats | executing runner 'run luametatex format': /usr/local/texlive/2023/bin/x86_64-linuxmusl/luametatex --jobname="./atestinlucida-context-55.mkiv" --fmt=/usr/local/texlive/2023/texmf-var/luametatex-cache/context/78ac5e3684a91334606faa581c7ce1d1/formats/luametatex/cont-en.fmt --lua=/usr/local/texlive/2023/texmf-var/luametatex-cache/context/78ac5e3684a91334606faa581c7ce1d1/formats/luametatex/cont-en.lui --c:currentrun=1 --c:fulljobname="./atestinlucida-context-55.mkiv" --c:input="./atestinlucida-context-55.mkiv" --c:kindofrun=1 --c:maxnofruns=9 --c:texmfbinpath="/usr/local/texlive/2023/bin/x86_64-linuxmusl" system > system > ConTeXt ver: 2023.03.10 12:15 LMTX fmt: 2023.3.25 int: english/english system > system > 'cont-new.mkxl' loaded open source > level 1, order 1, name '/usr/local/texlive/2023/texmf-dist/tex/context/base/mkxl/cont-new.mkxl' system > beware: some patches loaded from cont-new.mkiv close source> level 1, order 1, name '/usr/local/texlive/2023/texmf-dist/tex/context/base/mkxl/cont-new.mkxl' system > files > jobname './atestinlucida-context-55', input './atestinlucida-context-55.mkiv', result './atestinlucida-context-55' fonts > latin modern fonts are not preloaded languages > language 'en' is active open source > level 1, order 2, name './atestinlucida-context-55.mkiv' fonts > preloading latin modern fonts (second stage) mathematics > tweak > 'LatinModernMath-Regular', size 6, math size 3, version 'Version 1.959' found, version 'Version 1.958' expected fonts > 'fallback modern rm 12pt' is loaded open source > level 2, order 3, name '/usr/local/texlive/2023/texmf-dist/tex/context/fonts/mkiv/type-imp-lucida.mkiv' close source> level 2, order 3, name '/usr/local/texlive/2023/texmf-dist/tex/context/fonts/mkiv/type-imp-lucida.mkiv' fonts > defining > forced type 'otf' of 'LucidaBrightOT' not found fonts > defining > unable to define 'LucidaBrightOT.otf' as 'MyLucida-10pt-rm-tf-0--0' open source > level 2, order 4, name 'zapf.tex' close source> level 2, order 4, name 'zapf.tex' open source > level 2, order 5, name 'tufte.tex' close source> level 2, order 5, name 'tufte.tex' backend > xmp > using file '/usr/local/texlive/2023/texmf-dist/tex/context/base/mkiv/lpdf-pdx.xml' pages > flushing realpage 1, userpage 1, subpage 1 close source> level 1, order 5, name
Re: [NTG-context] registered function call [1160]:...live/2023/texmf-dist/tex/context/base/mkiv/l-sandbox.lua:87: cannot open /.: Permission denied - Alpine Linux
On Sat, Mar 25, 2023 at 09:26:36PM +0100, Hans Hagen via ntg-context wrote:
> On 3/25/2023 8:55 PM, Carlos via ntg-context wrote:
> > Hello list:
> >
> > This is under a fresh TeXLive installation. Sort as to put aside any
> > texlive prepackaged issues.
> >
> > And the followign lines is the output of the error I've been having with
> > the call of context on a recent texlive installation by both mtxrun
> > --generate and luatools --generate right after.
>
> there i no need to use luatools (it's something old from the early days)
>
> what does
>
> mtxrun --generate --verbose
It doesn't.
This is under the same folder in question. Recall I moved the other group owned
files elsewhere out of the way
This is the output
system | lua | compiling
'/home/ce/.texlive2023/texmf-var/luametatex-cache/context/78ac5e3684a91334606faa581c7ce1d1/trees/73630a261795d9c53610a28af4550cbc.lua'
into
'/home/ce/.texlive2023/texmf-var/luametatex-cache/context/78ac5e3684a91334606faa581c7ce1d1/trees/73630a261795d9c53610a28af4550cbc.lud'
system | lua | dumping
'/home/ce/.texlive2023/texmf-var/luametatex-cache/context/78ac5e3684a91334606faa581c7ce1d1/trees/73630a261795d9c53610a28af4550cbc.lua'
into
'/home/ce/.texlive2023/texmf-var/luametatex-cache/context/78ac5e3684a91334606faa581c7ce1d1/trees/73630a261795d9c53610a28af4550cbc.lud'
stripped
resolvers | caching | 'files' compiled to
'/home/ce/.texlive2023/texmf-var/luametatex-cache/context/78ac5e3684a91334606faa581c7ce1d1/trees/73630a261795d9c53610a28af4550cbc.lud'
resolvers | resolving | saving tree 'selfautoparent:texmf-dist'
resolvers | caches | hashing tree 'selfautoparent:texmf-dist', hash
'929f6dbc83f6d3b65dab91f1efa4aacb'
resolvers | caching | preparing 'files' for 'selfautoparent:texmf-dist'
resolvers | caching | category 'files', cachename
'selfautoparent:texmf-dist' saved in
'/home/ce/.texlive2023/texmf-var/luametatex-cache/context/78ac5e3684a91334606faa581c7ce1d1/trees/929f6dbc83f6d3b65dab91f1efa4aacb.lua'
system | lua | compiling
'/home/ce/.texlive2023/texmf-var/luametatex-cache/context/78ac5e3684a91334606faa581c7ce1d1/trees/929f6dbc83f6d3b65dab91f1efa4aacb.lua'
into
'/home/ce/.texlive2023/texmf-var/luametatex-cache/context/78ac5e3684a91334606faa581c7ce1d1/trees/929f6dbc83f6d3b65dab91f1efa4aacb.lud'
system | lua | dumping
'/home/ce/.texlive2023/texmf-var/luametatex-cache/context/78ac5e3684a91334606faa581c7ce1d1/trees/929f6dbc83f6d3b65dab91f1efa4aacb.lua'
into
'/home/ce/.texlive2023/texmf-var/luametatex-cache/context/78ac5e3684a91334606faa581c7ce1d1/trees/929f6dbc83f6d3b65dab91f1efa4aacb.lud'
stripped
resolvers | caching | 'files' compiled to
'/home/ce/.texlive2023/texmf-var/luametatex-cache/context/78ac5e3684a91334606faa581c7ce1d1/trees/929f6dbc83f6d3b65dab91f1efa4aacb.lud'
mtxrun |
mtxrun | elapsed lua time: 4.327 seconds
> > 58
> > 59 \usetypescriptfile[type-lucida]
> > 60 \usetypescript[Lucida][texnansi]
> > 61 >> \setupbodyfont[MyLucida, 10pt]
> > 62
> > 63 \input zapf
> > 64
> > 65 \input tufte
>
> fwiw, lucida type one makes no sense any more because the opentype version
> is way better (and in the updated math setup in lmtx we didn't even look at
> it)
>
It goes throught without a problem under Void Linux. pfm and afm files on this
one are right there in place. On this one: Alpine. It's a problem. or a given
:) depending how one looks at it.
> > Is LuaLaTeX behaving the same way?
> >
> > Answer: no.
>
> no surprise because it doesn't use the same setup
>
> what cache path does
>
> mtxrun --variables
>
> report
mtxrun --variables
resolvers | lists | AFMFONTS
resolvers | lists | env: unset
resolvers | lists | var: AFMFONTS
resolvers | lists | exp: .\{home:.texlive2023/texmf-config, home:texmf,
!!selfautoparent:texmf-config, !!selfautoparent:texmf-var,
!!selfautoparent:texmf-project, !!selfautoparent:texmf-fonts,
!!selfautoparent:texmf-local, !!selfautoparent:texmf-dist}/fonts/{data,
afm}//\/home/ce\/usr/share/fonts
resolvers | lists | res: .\{/home/ce/.texlive2023/texmf-config,
/home/ce/texmf, !!/usr/local/texlive/2023/texmf-config,
!!/usr/local/texlive/2023/texmf-var, !!/usr/local/texlive/2023/texmf-project,
!!/usr/local/texlive/2023/texmf-fonts, !!/usr/local/texlive/2023/texmf-local,
!!/usr/local/texlive/2023/texmf-dist}/fonts/{data,
afm}//\/home/ce\/usr/share/fonts
resolvers | lists | BIBINPUTS
resolvers | lists | env: unset
resolvers | lists | var: BIBINPUTS
resolvers | lists | exp: .\{home:.texlive2023/texmf-config, home:texmf,
!!selfautoparent:texmf-config, !!selfautoparent:texmf-var,
!!selfautoparent:texmf-project, !!selfautoparent:texmf-fonts,
!!selfautoparent:texmf-local,
!!selfautoparent:texmf-dist}/bibtex/bib//\{home:.texlive2023/texmf-config,
home:texmf, !!selfautoparent:texmf-config, !!selfautoparent:texmf-var,
Re: [NTG-context] registered function call [1160]:...live/2023/texmf-dist/tex/context/base/mkiv/l-sandbox.lua:87: cannot open /.: Permission denied - Alpine Linux
On 3/25/2023 8:55 PM, Carlos via ntg-context wrote: ...xlive/2023/texmf-dist/tex/context/base/mkiv/font-syn.lua:1030: in upvalue 'walk_tree' Maybe your OSFONTDIR is pointing to empty. Does mtxrun --script font --reload work Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | 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 / https://www.ntg.nl/mailman/listinfo/ntg-context webpage : https://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : https://contextgarden.net ___
Re: [NTG-context] registered function call [1160]:...live/2023/texmf-dist/tex/context/base/mkiv/l-sandbox.lua:87: cannot open /.: Permission denied - Alpine Linux
On 3/25/2023 8:55 PM, Carlos via ntg-context wrote: Hello list: This is under a fresh TeXLive installation. Sort as to put aside any texlive prepackaged issues. And the followign lines is the output of the error I've been having with the call of context on a recent texlive installation by both mtxrun --generate and luatools --generate right after. there i no need to use luatools (it's something old from the early days) what does mtxrun --generate --verbose report (whre does it fail) 57 \starttext 58 59 \usetypescriptfile[type-lucida] 60 \usetypescript[Lucida][texnansi] 61 >> \setupbodyfont[MyLucida, 10pt] 62 63 \input zapf 64 65 \input tufte fwiw, lucida type one makes no sense any more because the opentype version is way better (and in the updated math setup in lmtx we didn't even look at it) Is LuaLaTeX behaving the same way? Answer: no. no surprise because it doesn't use the same setup what cache path does mtxrun --variables report Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | 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 / https://www.ntg.nl/mailman/listinfo/ntg-context webpage : https://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : https://contextgarden.net ___
[NTG-context] registered function call [1160]:...live/2023/texmf-dist/tex/context/base/mkiv/l-sandbox.lua:87: cannot open /.: Permission denied - Alpine Linux
Hello list: This is under a fresh TeXLive installation. Sort as to put aside any texlive prepackaged issues. And the followign lines is the output of the error I've been having with the call of context on a recent texlive installation by both mtxrun --generate and luatools --generate right after. mtxrun --script cache --erase has also been called out to no avail registered function call [1160]: ...live/2023/texmf-dist/tex/context/base/mkiv/l-sandbox.lua:87: cannot open /.: Permission denied stack traceback: [C]: in upvalue 'func' ...live/2023/texmf-dist/tex/context/base/mkiv/l-sandbox.lua:87: in function 'lfs.dir' .../texlive/2023/texmf-dist/tex/context/base/mkiv/l-dir.lua:139: in upvalue 'glob_pattern_table' .../texlive/2023/texmf-dist/tex/context/base/mkiv/l-dir.lua:163: in upvalue 'glob_pattern_table' .../texlive/2023/texmf-dist/tex/context/base/mkiv/l-dir.lua:163: in upvalue 'glob_pattern_table' .../texlive/2023/texmf-dist/tex/context/base/mkiv/l-dir.lua:163: in upvalue 'glob_pattern_table' .../texlive/2023/texmf-dist/tex/context/base/mkiv/l-dir.lua:163: in upvalue 'glob_pattern_table' .../texlive/2023/texmf-dist/tex/context/base/mkiv/l-dir.lua:180: in function <.../texlive/2023/texmf-dist/tex/context/base/mkiv/l-dir.lua:169> (...tail calls...) ...xlive/2023/texmf-dist/tex/context/base/mkiv/font-syn.lua:1030: in upvalue 'walk_tree' ...xlive/2023/texmf-dist/tex/context/base/mkiv/font-syn.lua:1190: in local 'method' ...xlive/2023/texmf-dist/tex/context/base/mkiv/font-syn.lua:1152: in local 'traverse' ...xlive/2023/texmf-dist/tex/context/base/mkiv/font-syn.lua:1200: in upvalue 'analyzefiles' ...xlive/2023/texmf-dist/tex/context/base/mkiv/font-syn.lua:1286: in field 'identify' ...xlive/2023/texmf-dist/tex/context/base/mkiv/font-syn.lua:1311: in field 'load' ...xlive/2023/texmf-dist/tex/context/base/mkiv/font-syn.lua:1322: in field 'load' ...xlive/2023/texmf-dist/tex/context/base/mkiv/font-syn.lua:1588: in field 'getfilename' ...xlive/2023/texmf-dist/tex/context/base/mkxl/font-otl.lmt:835: in function <...xlive/2023/texmf-dist/tex/context/base/mkxl/font-otl.lmt:828> (...tail calls...) ...xlive/2023/texmf-dist/tex/context/base/mkxl/font-def.lmt:378: in function <...xlive/2023/texmf-dist/tex/context/base/mkxl/font-def.lmt:366> (...tail calls...) ...xlive/2023/texmf-dist/tex/context/base/mkxl/font-def.lmt:485: in field 'read' ...xlive/2023/texmf-dist/tex/context/base/mkxl/font-ctx.lmt:1377: in function <...xlive/2023/texmf-dist/tex/context/base/mkxl/font-ctx.lmt:1234> (...tail calls...) 51 ;definetypeface[MyLucida][rm][serif][lucida][default][encoding=texnansi] 52 \definetypeface[MyLucida][ss][sans][lucida][default][encoding=texnansi] 53 \definetypeface[MyLucida][tt][mono][lucida][default][encoding=texnansi] 54 \stoptypescript 55 56 57 \starttext 58 59 \usetypescriptfile[type-lucida] 60 \usetypescript[Lucida][texnansi] 61 >> \setupbodyfont[MyLucida, 10pt] 62 63 \input zapf 64 65 \input tufte 66 67 68 \stoptext 69 mtx-context | fatal error: return code: 1 it doesn't matter either whatever the typescript name goes and whether is type-lucida from texnansi-lucida-map file as it has been previously advised to change the name from . makes no difference. Is LuaLaTeX behaving the same way? Answer: no. The permission denied message happened first with folders whose permeissions were not owned by the user, but the root, so I moved the files out of harm's way to another folder . Anothr folder, NOT a subfolder. Then the problem persisted to read folders and even subfolders (directories, subdirectories) with cache filenames and headers that follow So let's not get to apprehensive, It's understandable that say, not reasonable, but understandable maybe? that mtxrun or lua for that matter will stop right before. So the folders were moved right after. Gone out of the binaries. But what I can't understand is why would it try to access cache folders unrelated with anything TeX or header folders for that matter This is perhaps more serious than I thought at first. And Let's not blame the TeXLive pre-packaged running under Alpine Linux. To put it in laymans' terms and If anything is clear to me, is that Alpine ir not letting Lua running beserk on the system and its folders, owned by whatever/whoever else, and with pesmissions set elsewhere. It's out of the question. Or it rather be. This is all writh a fresh TeX Live Installation. I mentioned the problem that may arise by questioning the Alpine installation because there were some problems with some binaries from the prepackaged TeX Live put out by Alpine devs. But this is not prepackaged. Nope. -- "We are on the verge: Today our
