Hi, I uploaded a new version. I got sidetracked by an experiment. We can read from zip files, but as I had some tar archives I wondered if we could read from them. They happened to be compressed. It uses an already present infrastructure (early mkiv I played a bit with reading from zip files). \starttext \dorecurse{100}{ \input {tar:///e:/temporary/test/foo.tar?name=test.tex}\par \input {tar:///e:/temporary/test/foo.tar.xz?name=test.tex}\par \input {tar:///e:/temporary/test/foo.tar.gz?name=test.tex}\par } \stoptext The tar files are handled by lmtx itself, the gzipped variant uses the basic decompressor of the engine (different in lmtx than in mkiv but that should not matterl i only tested lmtx). The xz one is a bit more special as it uses the external xz program unless one has limlzma installed, e.g. in: tex/texmf-win64/bin/lib/luametatex/lzma/liblzma.dll (mtxrun --generate makes it locatable). In all three examples performance is quite ok. It might a nice solution for cases where one has many small files cluttering the system. It actually might be more efficient to use tar.xz instead of zip files but then we also need to ship the lib and that is not on the agenda. I'm in no hurry with such alternatives (most of todays bandwidth is wasted with ads and related crap anyway). Concerning math .... we have several fonts, and the public ones don't really play the game like cambria does. So, th emore bugs become features, the more we're stuck with it. Now, once fonts are stable (including bugs) we cna think of goodie files that fix things but an other option is to tell the math machinery in what aspects as font is not really opentype. Read: when to follow a traditional code path. For the moment that is just an experiment and mostly meant for myself to explore things but it is likely to stay. Contrary to other variabls that control the math engine, here we have a bitset (adding dozens more commands makes no sense): \setupbodyfont[newcomputermodern-book] \starttext \startTEXpage[offset=10pt] $ \showglyphs\showmakeup[math] f = 10 $ $ \mathcontrolmode\plusone \bitwiseflip\mathfontcontrol\orditalickernmathcontrolcode \bitwiseflip\mathfontcontrol\charitalicnoreboxmathcontrolcode \bitwiseflip\mathfontcontrol\orditalickernmathcontrolcode \bitwiseflip\mathfontcontrol\charitalicnoreboxmathcontrolcode \bitwiseflip\mathfontcontrol\overrulemathcontrolcode \bitwiseflip\mathfontcontrol\underrulemathcontrolcode \bitwiseflip\mathfontcontrol\radicalrulemathcontrolcode \bitwiseflip\mathfontcontrol\fractionrulemathcontrolcode \bitwiseflip\mathfontcontrol\accentskewhalfmathcontrolcode \bitwiseflip\mathfontcontrol\accentskewapplymathcontrolcode \bitwiseflip\mathfontcontrol\accentitalickernmathcontrolcode \bitwiseflip\mathfontcontrol\delimiteritalickernmathcontrolcode \bitwiseflip\mathfontcontrol\charitalicwidthmathcontrolcode \bitwiseflip\mathfontcontrol\boxednoitalickernmathcontrolcode \bitwiseflip\mathfontcontrol\nostaircasekernmathcontrolcode \bitwiseflip\mathfontcontrol\textitalickernmathcontrolcode \showglyphs\showmakeup[math] f = 10 $ \stopTEXpage \stoptext Here, when \mathcontrolmode larger than zero, the \mathfontcontrol bitset will control code paths. When the value is zero, a normal opentype font is assumed. There might be some more options but it's a bit tricky (maybe I already introduced some issues, who knows). A font can also communicate a bitset and this is supported by a font feature in lmtx: % \definefontfeature[newcm-mathextra][mathcontrol={% % over_rule,% % under_rule,% % radical_rule,% % fraction_rule,% % accent_skew_half,% % accent_skew_apply,% % accent_italic_kern,% % delimiter_italic_kern,% % ord_italic_kern,% % char_italic_width,% % char_italic_no_rebox,% % boxed_no_italic_kern,% % no_staircase_kern,% % text_italic_kern,% % }] the newcm-mathextra is for instance applied with that font when defined (as usual with features), Again there is some detailed control and more can be added. So we have a control variable at the tex end and one that goes with a font. The 'bits' have funny names but such are the internals. Eventually I'll wrap this up in a progress article. In addition to the above there are a few fixes for issues discussed on the mailing list. I'm still trying to get tracing a bit nicer, so here is another trick: \starttext \def\MyPrimitiveCommandA#1{\hbox to 3cm{#1}} \untraced\def\MyPrimitiveCommandB#1{\hbox to 3cm{#1}} \bgroup \tracingall \MyPrimitiveCommandA{oeps} \MyPrimitiveCommandB{oeps} \egroup The first one gives: 2:3: \MyPrimitiveCommandA #1->\hbox to 3cm{#1} 2:3: #1<-oeps 2:4: {\hbox} 2:5: {entering adjusted hbox group (level 2) at line 10} and the second one: 2:3: \MyPrimitiveCommandB 2:4: {\hbox} 2:5: {entering adjusted hbox group (level 2) at line 11} not that users do much tracing, but sometimes it helps not to see clutter in the log for (e.g.) low level helpers that act like primiteves. Taks: \setbox0\hbox{test me} With "\showbox 0" we get:
\box0= 1:3: \hbox[hbox][color=1,colormodel=1], width 38.69073, height 7.37595, depth 0.13193, direction l2r 1:3: .\list 1:3: ..\glyph[32768][color=1,colormodel=1], language (n=1,l=2,r=3), hyphenationmode "79F3F, options "80, font <2: newcm10-book @ 12.0pt>, glyph U+000074 t ...............................
But with "\showboxhere 0" gives \hbox[hbox][color=1,colormodel=1], width 38.69073, height 7.37595, depth 0.13193, direction l2r .\list ..\glyph[32768][color=1,colormodel=1], language (n=1,l=2,r=3), hyphenationmode "79F3F, options "80, font <2: newcm10-book @ 12.0pt>, glyph U+000074 t ............................... WHen we say: \meaning\showboxhere it reports itself as for instance \relax does. This because it is defined with the \untraced prefix (it's also unexpandable and protected against overloading when one has overloadmode set). \untraced\permanent\protected\def\showboxhere{\showbox nolevels content online } % no group/input info, only content, and forced online (There are cases where the meaning will show up, but at least it adds a little to the abstraction.) 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 -----------------------------------------------------------------
On Thu, Jun 24, 2021 at 7:29 PM Hans Hagen
Hi,
I uploaded a new version. I got sidetracked by an experiment. We can read from zip files, but as I had some tar archives I wondered if we could read from them. They happened to be compressed. It uses an already present infrastructure (early mkiv I played a bit with reading from zip files).
libarchive looks quite useful http://libarchive.org/ (see https://docs.microsoft.com/en-us/virtualization/community/team-blog/2017/201... ) -- luigi
On 6/25/2021 12:18 AM, luigi scarso wrote:
On Thu, Jun 24, 2021 at 7:29 PM Hans Hagen
mailto:j.hagen@xs4all.nl> wrote: Hi,
I uploaded a new version. I got sidetracked by an experiment. We can read from zip files, but as I had some tar archives I wondered if we could read from them. They happened to be compressed. It uses an already present infrastructure (early mkiv I played a bit with reading from zip files).
libarchive looks quite useful http://libarchive.org/ http://libarchive.org/ (see https://docs.microsoft.com/en-us/virtualization/community/team-blog/2017/201... https://docs.microsoft.com/en-us/virtualization/community/team-blog/2017/201...)
But it's huge and add lots of dependencies and thereby complications; often these libs have special platform optimizations (so one needs to run configure scripts) ... in luametatex i try to stay away from that .. but loading as external lib is of course an option; we already support zip, gz, tar, lz4, lzma (xz), lzo, xstd but i doubt if in practice they are used often (zip we need for pdf, gz for some graphics, xz because it's used in texlive but most of it is also kind of fun to play with: as less code as possible and then lua support code). 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 -----------------------------------------------------------------
participants (2)
-
Hans Hagen
-
luigi scarso