- ntg-context - Mailing Lists

basic issues with formulas
by Pablo Rodriguez 03 Dec '20

03 Dec '20

Dear list, math is all Greek to me and I’m experiencing issues when typesetting the most basic inline formulas. \starttext \startitemize[packed] \item Valor actual neto: $beneficios - costes$. \item Beneficio por euro: $\frac{beneficios}{costes}$. \item Beneficio obtenido el primer año. \stopitemize \startitemize[packed] \item Valor actual neto: $beneficios - costes$. \item Beneficio por euro: $beneficios - costes$. \item Beneficio obtenido el primer año. \stopitemize \startitemize[packed, columns, two] \item Valor actual neto: $beneficios - costes$. \item Beneficio por euro: $\frac{beneficios}{costes}$. \item Beneficio obtenido el primer año. \stopitemize \startitemize[packed, columns, two] \item Valor actual neto: $beneficios - costes$. \item Beneficio por euro: $beneficios - costes$. \item Beneficio obtenido el primer año. \stopitemize \stoptext The issues I’m experiencing are: 1. Kernings around ligatures (fi) are wrong. 2. Is there a way to enable ligatures? 3. Packed works fine with fractions, but packed columns is wrong with them. It adds too much space. Again, formulas are totally foreign to my work with ConTeXt. I don’t know whether they are bugs in latest (2020.01.30 14:13) or there is a way to avoid the issues. Many thanks for your help, Pablo -- http://www.ousia.tk

4 7

Bug (?) using \externalfigure with layers and backgrounds
by Jairo A. del Rio 03 Dec '20

03 Dec '20

Hi everyone. The following \setuppagenumbering[state=stop] \definelayer[mybg] [ repeat=yes, x=0mm, y=0mm, width=\paperwidth, height=\paperheight, ] \setlayer[mybg]{\externalfigure[cow][width=\paperwidth,height=\paperheight]} \setupbackgrounds[page][background=mybg,state=repeat] \setupindenting[yes,small] \startsetups background:default \setupbackgrounds[page][background=mybg,state=repeat] \stopsetups \startsetups background:void \setupbackgrounds[page][background=] \stopsetups \starttext \dorecurse{7}{\input knuth} \page \setups[background:void] \dorecurse{8}{\input tufte} \page \setups[background:default] \dorecurse{7}{\input knuth} \page \stoptext works with a local image (say, if "cow" is in the same folder as the main file), but it doesn't find sample images (cow, hacker, etc.). Is that a bug or an intended result? Thank you in advance. Best regards, Jairo

2 2

Using ConTeXt-LMTX for modern Mathematically-Literate-Programming 1/2
by Stephen Gaito 03 Dec '20

03 Dec '20

Hello, I am slowly working on a Mathematical problem requiring underlying computation. As Mathematicians (myself included) are rather "conservative", I need to discuss each "chunk" of code with the full set of Mathematical notation. A couple of years ago I started using ConTeXt-MKIV as a Mathematically-Literate-Programming tool by using its excellent Lua interface to capture the code and dump it to disk for external compilation. I am now revisiting my original design and want to redo my tools using ConTeXt-LMTX. I would *like* to be able to "stop" the ConTeXt typesetting at various points for differing purposes: 1. After all macro expansions (and hence after *my* calls into Lua) but before line/paragraph/page layout begins. 2. After line/paragraph/page layout but before PDF generation. 3. After all PDF generated (ie. a "normal" "full" ConTeXt run). Stopping after all macro expansions would allow my code generation builds to proceed without the un-needed page setting or PDF generation. Stopping after the line/paragraph/page layout would allow multiple "faster(?)" ConTeXt runs while the "*.tuc" file converges to a complete set of page numbers and cross references (etc). Then, once the "*.tuc" file has converged, a full ConTeXt run with PDF output could be done. I am very aware that *internally* ConTeXt is probably structured as a tight pipeline with each of the "traditional" TeX stages "Mouth", "Stomach", "page setting", PDF generation.... tightly "chained"... This means that there is no "one" place in the code where all macro expansions have completed but before the page setting "starts", or similarly, after the page setting has finished but before the PDF generation "starts". ---- QUESTION: Is it possible to use the new LuaMetaTeX callbacks (found in chapter 10 of the "LuaMetaTEX Reference Manual") to "suppress" any further computation at various points in the ConTeXt pipeline? ---- For example, could I use one of the "*_linebreak_filter"s (or the "append_to_vlist_filter") to "return" an empty value and hence reduce further computation downstream in the pipeline? Could I use the "pre_output_filter" to "return" an empty value and hence "stop" PDF generation? (I realize that these callbacks *are* a currently fast moving target. I am happy to follow their changes, equally I would be testing their usefulness and/or impact) ---- ALTERNATIVE QUESTION: Would it be possible to provide official ConTeXt-LMTX "modes" which suppress further computation at these points? ---- This alternative, while some more work for the writing of ConTeXt-LMTX, would ensure less direct external dependence on the LuaMetaTeX callbacks, but would almost certainly be welcomed by the ConTeXt community. ---- QUESTION: Are the "stages" I have identified major, computationally expensive, "steps" in the overall ConTeXt "computation"? ---- Many thanks for an excellent tool! Regards, Stephen Gaito

3 8

Parallelizing typesetting of large documents with lots of cross-references
by Stephen Gaito 03 Dec '20

03 Dec '20

Hello, This email is largely a simple notification of one "Fool's" dream... ("Only Fools rush in where Angels fear to tread"). I am currently attempting to create "a" (crude) "tool" with which I can typeset: - very large (1,000+ pages), - highly cross-referenced documents, - with embedded literate-programmed code (which needs concurrent compiling and execution), - containing multiple MetaFun graphics, all based upon ConTeXt-LMTX. "In theory", it should be possible to typeset individual "sub-documents" (any section which is known to start on a page boundary rather than inside a page), and then re-combine the individual PDFs back into one single PDF for the whole document (complete with control over the page numbering). The inherent problem is that the *whole* of a ConTeXt document depends upon cross-references from *everywhere* else in the document. TeX and ConTeXt "solve" this problem by using a multi-pass approach (in, for example, 5 passes for the `luametatex` document). Between each pass, ConTeXt saves this multi-pass data (page numbers and cross-references) in the `*.tuc` file. Clearly any parallelization approach needs to have a process which coordinates the update and re-distribution of any changes in this multi-pass data obtained by typesetting each "sub-document". My current approach is to have a federation of Docker/Podman "pods". Each "pod" would have a number of ConTeXt workers, as well as (somewhere in the federation) a Lua based Multi-Pass-Data-coordinator. All work would be coordinated by messages sent and received over a corresponding federation of [NATS servers](https://nats.io/). (Neither [Podman](https://podman.io/) pods nor NATS message coordination are problems at the moment). -------------------------------------------------------------------- **The real problem**, for typesetting a ConTeXt document, is the design of the critical process which will act as a "Multi-Pass-Data-coordinator". -------------------------------------------------------------------- All ConTeXt sub-documents would be typeset in "once" mode using the latest complete set of "Multi-Pass-Data" obtained from the central coordinator. Then, once each typesetting run is complete, the resulting "Multi-Pass-Data" would be sent back to the coordinator to be used to update the coordinator's complete set of "Multi-Pass-Data" ready for any required next typesetting pass. (From the `context --help`: >mtx-context | --once only run once (no multipass data file is produced) I will clearly have to patch(?) the mtx-context.lua script to allow multipass data to be produced... this is probably not a problem). (There would also be a number of additional processes/containers for dependency analysis, build sequencing, compilation of code, execution or interpretation of the code, stitching the PDFs back into one PDF, etc -- these processes are also not the really critical problem at the moment). -------------------------------------------------------------------- QUESTIONS: 1. Are there any other known attempts to parallelize context? 2. Are there any other obvious problems with my approach? 3. Is there any existing documentation on the contents of the `*.tuc` file? 4. If there is no such documentation, is there any naming pattern of the Lua functions which get/set this multi-pass information that I should be aware of? -------------------------------------------------------------------- Many thanks for all of the very useful comments so far... Regards, Stephen Gaito

3 2

Re: [NTG-context] Using ConTeXt-LMTX for modern Mathematically-Literate-Programming 2/2
by Stephen Gaito 03 Dec '20

03 Dec '20

Hans, Many thanks for your comments... see below. On Mon, 30 Nov 2020 19:31:55 +0100 Hans Hagen <j.hagen(a)xs4all.nl> wrote: > On 11/30/2020 10:51 AM, Stephen Gaito wrote: > > Hello (again), > > > > This email is further to my previous "Using ConTeXt-LMTX for modern > > Mathematically-Literate-Programming 1/2" email... > > > > My ultimate goal in using ConTeXt-LMTX as a > > Mathematically-Literate-Programming tool, is to actually write a > > kernel "Mathematical Language" in ANSI-C (wrapped in Lua) which is > > then imported back into ConTeXt-LMTX as a standard Lua module (with > > an ANSI-C shared library). > > Just curious: do you think that using c instead of lua for that has > advantages? This is a very good and important question. One I have asked myself repeatedly. My ultimate goal is to write a small mathematical kernel in ANSI-C, which is, using [Frama-C](https://frama-c.com/), proven *correct*. To my knowledge, Lua has no similar tool for correctness proofs. Equally importantly, there are a very wide range of very different compilers which compile ANSI-C for an equally very wide range of CPU's. Again, to my knowledge, Lua v5.4 has only one implementation (though this implementation *can* be compiled for a very wide range of CPU's). The problem here is that Mathematicians are inherently very conservative about the concept of "proof" (it has taken well over 2,000 hard years to develop our current understanding). My kernel will be an extensible "proof" engine. For mathematicians to trust it, this proof engine must itself be proven correct (or as correct as currently possible). It must also be simple enough to *see* that it is correct (hence the Literate-Programming approach), *and* (since I can not even hope to prove the compilers are *correct*), there must be many *different* compiler implementations (to show that the results are not artefacts of one particular implementation). Finally, the computational complexity of my proof engine, will be comparable to MetaFun/MetaPost... which I suspect you would not consider implementing in pure Lua. Some things are faster in C. So yes I do need to implement it in ANSI-C wrapped in Lua (so that it can be used from *inside* ConTeXt). Since this is a mathematical tool, "embedding" it in ConTeXt is ideal. As a mathematician writes, what they write gets proof-checked automatically... in the document they are writing, and by the typesetting tool they are using for the finished PDF. :-) ConTeXt (via LuaMetaTex) makes this possible in a way native TeX/LaTeX never could. So once again, many many thanks for the vision to create such a flexible tool! > > > This would allow the output of "code" in my "Mathematical Language" > > to be directly embedded/typeset in the output of my Mathematical > > document. > > > > (The ultimate goal is to ensure that there is NO wishful thinking > > that the code is "correct" ("just trust me")... all results would be > > directly visible in the PDF). > > > > Alas, while, for other reasons, trying to use the Lua-CJSON Lua > > module from within ConTeXt-LMTX (which also makes use of a shared > > library written in C), I find that the current ConTeXt-LMTX is > > missing (among potentially others) the `lua_checkstack` symbol: > > could be .. we dont' use it > > >> ...Xt/tex/texmf-context/tex/context/base/mkiv/l-package.lua:333: > >> error loading module 'cjson' from file > >> '/usr/local/lib/lua/5.4/cjson.so': > >> /usr/local/lib/lua/5.4/cjson.so: undefined symbol: lua_checkstack > > > > even when using the ConTeXt/LuaMetaTeX `--permiteloadlib` switch. > > > > (Note that this Lua-CJSON module does work with the native 5.4 Lua). > > why not use the build in helpers The test, which triggered the error message (above), was to prove that I could send [NATS](https://nats.io/) messages from *inside* ConTeXt. "Out of the box", the [Lua-NATS](https://github.com/DawnAngel/lua-nats) requires: - luasocket (which LuaMetaTex provides, many many thanks!) - lua-cjson (which is an external shared library and is what I was testing) Fortunately, I found a couple of pure Lua JSON tools which I could get Lua-NATS to use with a one line change. (And, for the record, I *can* send and receive messages from a NATS server from inside ConTeXt :-) If I find I need to make changes to the Lua-NATS code, I will probably use LuaMetaTeX's internal JSON implementation as you suggest below (again many thanks for embedding a JSON implementation). Using Lua-NATS is part of my larger goal to parallelize the typesetting of large documents using ConTeXt (more on this in another email). > > \usemodule[json] > > \starttext > > \startluacode > local l = { a = 1, b = { c = "d" } } > inspect(l) > local j = utilities.json.tojson(l) > inspect(j) > local s = utilities.json.tostring(j) > inspect(s) > io.savedata("temp.json",j) > local t = utilities.json.load("temp.json") > inspect(t) > \stopluacode > > \stoptext > > > 1. Is this an oversight and `--permitloadlib` is meant to be working > > now? > > I dont' know. I never use external modules myself (in luatex I use(d) > ffi for some database acces but those (and a few more) are build in > luametatex as optional modules (as minimalistic as possible lua > itself can do most). I don't want a bloated bianry with all kind of > dependencies that force constant updates. A very important consideration. > > > 2. Is this a trivial fix (and might be fixed soon -- time > > permitting)? > > It's probably a side effect of binaries being stripped cq. functions > being inlined and we don't use lua_checkstack in luametatex. We can > at some point probably add some 'don't strip' feature (which then of > course exposes a whole bunch more that then for sure gets abused and > triggers issues when they change) > > > 3. Is this a rather complex refactoring of the code/build system > > (and hence might take some time before a fix can be rolled > > out)? > > dunno, a such things are driven by demand (and when it doesn't fit > into the 'fun to do' it has to be part of some project) > > > 4. Is this a case of "the `lua_checkstack` symbol will never be > > part of luametatex"? > > dunno, i haven't figured out how to selectively strip and making lua > into a lib that is loaded at runtime adds a dependency and > installation hassle (apart from the fact that when users then kick in > their own variant we need to support it which agsin is not that much > fun) > > > Any of the above scenarios is OK (though scenario 4 would be a > > disappointment as it means no shared library lua modules could be > > used in ConTeXt)... > > at some point (when we're stable and mojca and i have some more > infractstucrure set up, we have some ideas but are not in a hurry) > the source of luatex will be in the distribution and then users can > add their own optional modules If you ever want/need a beta tester of writing and building these optional modules, please let me know. For the moment, I suspect I will "simply" use Lua-NATS to request the proof-computations from an external Docker/Podman container process. Given the size and complexity of the proof-computations, the required network traffic will probably be nearly insignificant. > > > ... it would however be useful to have an idea of which scenario is > > most likely. > > As I said before, again many thanks for a wonderful (and stable) tool! Regards, Stephen Gaito > ----------------------------------------------------------------- > Hans Hagen | PRAGMA ADE > Ridderstraat 27 | 8061 GH Hasselt | The Netherlands > tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl > -----------------------------------------------------------------

2 2

Placing extra bookmarks?
by Bruce Horrocks 02 Dec '20

02 Dec '20

I have \placebookmarks[chapter] in my doc and all is fine except that I'd like to force an extra bookmark at the top of the list that jumps to the cover page. However there is no chapter title, or other built in style on the cover. I tried inserting \bookmark[chapter]{The Cover} but nothing happened - no error, no bookmark. Any suggestions please? There's no need to bookmark to a specific point - just going to page 1 would be enough. (I have looked through the mailing list archives but can't find quite the same scenario.) -- Bruce Horrocks Hampshire, UK

3 4

How do I get rid of the ct and st ligatures in EBGaramond?
by T. Kurt Bond 02 Dec '20

02 Dec '20

Searches didn't reveal the answer. -- T. Kurt Bond, tkurtbond(a)gmail.com, https://tkurtbond.github.io

6 17

Re: [NTG-context] ntg-context Digest, Vol 198, Issue 8
by Andres Conrado Montoya 02 Dec '20

02 Dec '20

You are naming your font "english". If you call "ebgaramond" it will always take the default ebgaramond features. Just call your font with the name you gave it. \definefontfamily[english] [rm] [ebgaramond] [features={dlig=no}] \setupbodyfont[english,10pt] \starttext ct st \stoptext -- Andrés Conrado Montoya Andi Kú andresconrado(a)gmail.com http://sesentaycuatro.com http://messier87.com http://chiquitico.org ---------------------------------------- Los fines no justifican los medios, porque la medida verdadera de nuestro carácter está dada por los medios que estamos dispuestos a utilizar, no por los fines que proclamamos. ---------------------------------------- “You develop an instant global consciousness, a people orientation, an intense dissatisfaction with the state of the world, and a compulsion to do something about it. From out there on the moon, international politics look so petty. You want to grab a politician by the scruff of the neck and drag him a quarter of a million miles out and say, ‘Look at that, you son of a bitch.’” — Apollo 14 astronaut Edgar Mitchell

2 1

Re: [NTG-context] Installing VSCode extension?
by Jeong Dal 02 Dec '20

02 Dec '20

Dear Mikael, > 2) Is there a nice way to compile the tex file from > within vs code? As of > now, I opened a terminal and compiled from that, but that feels like the > wrong way of doing it. For the first question, I don’t know either. For the second question, I’d like to explain what I did for compiling TeX file in vscode. Since I use vscode in MacOsX, you may find your way in Linux. There is a tasks.json file in .vscode folder. I added the following script in the “tasks":[ ] and save it. (You have to modify the "texmf-osx-64/bin” path in the following script from your machine. { "label": "ConTeXt LuaMetaTeX", "type": "shell", "command": "export PATH=/Users/graph/ConTeXtLM/tex/texmf-osx-64/bin:$PATH;mtxrun --autogenerate --script context --autopdf --purge '${file}'", "args": [], "options": { "cwd": "${fileDirname}" }, "group": { "kind": "build", "isDefault": true } }, When you want to compile a ConTeXt file, find “terminal > Run Build task” in the menu, then “ConTeXt LuaMetaTex” will pop up. Or just use the key “command-shift-B” instead using menu item. I hope that it may help. Best wishes, Dalyoung

3 2

Context install for Apple Silicon M1 mac mini
by Keith McKay 01 Dec '20

01 Dec '20

Hi, I have recently retired my 2012 mac mini in favour of a new Apple silicon M1 mac mini on which I would like to install ConTeXt. I know that their are no ARM binaries yet for ConTeXt but Apple say that intel binaries can be run on an ARM using the Rosetta emmulation software. I tried to download the intel binaries using the install.sh that comes with the context-osx-64.zip file but of course it does not recognise the ARM chip and suggests contacting the mailing list. In some previous emails to the list, in which I was a participent, (see the post "new upload" of 26/11/2020) their was some discussion on how Context could be set up to work on these machines by building binaries using Xcode. I am afraid this is well above my skillset so I was wondering how I could get the Intel binaries and then set up ConTeXt running with the Rosetta emulation software. I should be able to do that. If this is possible, I would be very happy to do some testing and report back my experiences to the list. Best Wishes Keith McKay Scotland, UK

3 3