Re: registered function call [1160]:...live/2023/texmf-dist/tex/context/base/mkiv/l-sandbox.lua:87: cannot open /.: Permission denied - Alpine Linux

[Carlos via ntg-context <ntg-context@ntg.nl>]

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 \c!alternative \v!formula \endcsname 

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. 

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 . 

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. 


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

-- 
New systems generate new problems.

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