April 2022 - ntg-context - NTG Mailing Lists

XML Namespaces and XML Setups
by Christoph Reller 24 May '22

24 May '22

Dear List, Consider the following MWE: \startxmlsetups xml:demo:base \xmlsetsetup{#1}{tag}{xml:demo:tag} \stopxmlsetups \xmlregisterdocumentsetup{demo}{xml:demo:base} \startxmlsetups xml:demo:tag %\doif{\xmlnamespace{#1}}{o}{NameSpaceO:} \xmlflush{#1} \stopxmlsetups \starttext \startbuffer[test] <?xml version="1.0"?> <root xmlns="NameSpaceA" xmlns:o="NameSpaceO"> <tag>text</tag> <o:tag>text</o:tag> </root> \stopbuffer \xmlprocessbuffer{demo}{test}{} \stoptext My questions: - Is there a good way to have a separate XML setup for each XML namespace? - Alternatively, one has to do the distinction within the same XML setup. In this case, how do we get the complete namespace? (In this example: "NameSpaceA" and "NameSpaceO") Thanks in advance for your help! Cheers, Christoph

3 4

lua-widow-control module error in LMTX
by Eduardo Bohoyo 14 May '22

14 May '22

Hi, I would like to know if anyone has experienced the same error with the lua-widow-control module when compiling the pdf: modules > 'lua-widow-control' is loaded open source > level 2, order 3, name '/opt/luametatex/texmf-modules/tex/context/third/lua-widow-control/t-lua-widow-control.mkxl'. resolvers > lua > unknown file 'lua-widow-control.lua' lua error > lua error on line 74 in file /opt/luametatex/texmf-modules/tex/context/third/lua-widow-control/t-lua-widow-control.mkxl The odd thing is that line 75 of the t-lua-widow-control file is empty. On the other hand, I confess that I don't know what "resolvers" means when it says it doesn't know the lua-widow-control.lua file. I don't see any mention of this file within the t-lua-widow-control module. Could it be that this module is not yet mature for lmtx, or am I missing something? I have \usemodule[lua-widow-control] in my tex document, and I haven't forgotten to do the prescribed mtxrun --generate after including the module in my third-party folder of my luametatex installation on Arch. Kind regards, Edu

2 8

Fuzzy paragraph when exporting to XML
by Aditya Mahajan 01 May '22

01 May '22

Hi, I am trying to debug a bug-report for t-vim: https://github.com/adityam/filter/issues/64 Exporting with trackers=export* gives a warning: backend > export > fuzzy paragraph: I have managed to narrow it down to the attached MWE (which does not depend on the t-vim module at all). Compiling it using $context --trackers=export\* lines gives the fuzzy paragraph warning. Any hints on how to resolve this? Thanks, Aditya

2 3

\doifnotdocumentargument in proper Lua
by Pablo Rodriguez 29 Apr '22

29 Apr '22

Dear list, I have the following command in one of my documents: \doifnotdocumentargument{no-metadata} {\ctxlua{document.transfer_metadata(document.main_file)}} Which would be the right way to write \doifnotdocumentargument in proper Lua? Many thanks for your help, Pablo

1 0

Problem with a defined colour in MetaFun
by Keith McKay 29 Apr '22

29 Apr '22

Hi, In the MWE below I define an rgb colour, myColor1, using random numbers for the r, g and b components. I then use it to fill a unitsquare the size of the page, which works as expected. In the loop that follows I then use the defined colour, myColor1, along with white and the variable r to create shades of myColor1 as in the MWE below. However, myColor1 is not recognised in the loop and seems to be replaced by black, although if I use a predefined colour, in this case BurntSienna from the crayola collection, it works as expected. I have tried a number of ways to get this to work as shown in the code but without success. I would be grateful for any suggestions. Best Wishes Keith McKay %%%%%%%%%%%%%%%%%%%%MWE%%%%%%%%%%%%% \setuppapersize[A4,portrait] \usecolors[crayola] \starttext \dorecurse{10}{ \startMPpage StartPage; \definecolor[name="myColor1", r = uniformdeviate(1), g = uniformdeviate(1), b = uniformdeviate(1) ] ; fill unitsquare xscaled PaperWidth yscaled PaperHeight withcolor "myColor1"; for i =2 step 2 until 10: r := i/10; fill unitsquare xscaled 5cm yscaled .5cm shifted (1cm,i*cm) withcolor(r[\MPcolor{BurntSienna},white]); fill unitsquare xscaled 5cm yscaled .5cm shifted (7cm,i*cm) withcolor(r[\MPcolor{myColor1}, white]); fill unitsquare xscaled 5cm yscaled .5cm shifted (13cm,i*cm) withcolor(r[\MPcolor{"myColor1"}, white]); %fill unitsquare xscaled 5cm yscaled .5cm shifted (13cm,i*cm) withcolor(r[myColor1 , white]); This line causes an error. endfor; StopPage; \stopMPpage } \stoptext %%%%%%%%%%%%%%%%%%%%%%%%%%%end MWE%%%%%%%%%%% I am running: system > system > ConTeXt ver: 2022.04.20 19:18 LMTX fmt: 2022.4.26 int: english/english system > system > 'cont-new.mkxl' loaded

3 5

Re: [NTG-context] lua-widow-control module error in LMTX
by Max Chernoff 29 Apr '22

29 Apr '22

On 2022-04-27 3:59 p.m., Eduardo Bohoyo wrote: > When I uncomment grid=yes in my \setuplayout, lwc makes its real > appearance on the scene. So it looks like lwc was broken with grid snapping. This surprised me -- I originally wrote lwc *specifically* to use with grid snapping -- but it looks like I quickly forgot about that goal and never actually tested it with grids. > I suppose that in other documents than mine, > i.e. less complex, this performance would be a success. But in my file > it is, considering my current aesthetic requirements, a failure. This is > because for me grid=yes is a non-negotiable part of my code. I _think_ that I've fixed it now. Can you try the beta version at https://github.com/gucci-on-fleek/lua-widow-control/releases/tag/release-47… please? Hopefully this solves the issue. > Do you want the new pdf with lwc actually acting on my file? Then you > can get a better idea of what I mean by the end of some pages when I > comment grid=yes (apart from the mischief that happens with the > horizontal spaces in some paragraphs of the bibliographic section). > > Or, if you prefer, and you need more feedback, I can send you my current > code to use it as a test bench for " daring " texts. I was able to reproduce the issue just by adding \setuplayout[grid=yes] to my "standard" test files, so I shouldn't need anything else, provided that the above beta actually fixes anything. If there are still lingering issues, then having the TeX source would likely simplify things on my end. -- Max

3 5

context module t-account in LMTX
by Heinrich Paeßens 28 Apr '22

28 Apr '22

Hi there I just tried to test the use of the t-account module, compiling with LMTX, but no avail. What is wrong? Does the module need a fix for LMTX or is the fault on my side (having no experience …)? Many thanks for your support. Kind regards, Heinrich the example is in the file tst-account.tex —— % !TEX program = lmtx \usemodule[t-account] \environment TACCOUNT \startDEBITS \debit [Auto] {2000} \debit [Bus] {5000} \startCREDITS \credit [Bank] {1000} \credit [Kasse] {200} \credit [Kasse] {200} \stopCREDITS \stopACCOUNT —— leads to error shown in the log: —— resolvers | formats | executing runner 'run luametatex format': /Users/hp/Library/context-osx-64/tex/texmf-osx-64/bin/luametatex --jobname="./tst-account.tex" --fmt=/Users/hp/Library/context-osx-64/tex/texmf-cache/luametatex-cache/context/5fe67e0bfe781ce0dde776fb1556f32e/formats/luametatex/cont-en.fmt --lua=/Users/hp/Library/context-osx-64/tex/texmf-cache/luametatex-cache/context/5fe67e0bfe781ce0dde776fb1556f32e/formats/luametatex/cont-en.lui --c:autopdf --c:currentrun=1 --c:directives="system.showerror" --c:fulljobname="./tst-account.tex" --c:input="./tst-account.tex" --c:kindofrun=1 --c:maxnofruns=9 --c:purgeall --c:texmfbinpath="/Users/hp/Library/context-osx-64/tex/texmf-osx-64/bin" system > system > ConTeXt ver: 2022.04.15 20:20 LMTX fmt: 2022.4.17 int: english/english system > system > 'cont-new.mkxl' loaded open source > level 1, order 1, name '/Users/hp/Library/context-osx-64/tex/texmf-context/tex/context/base/mkxl/cont-new.mkxl' system > beware: some patches loaded from cont-new.mkiv close source > level 1, order 1, name '/Users/hp/Library/context-osx-64/tex/texmf-context/tex/context/base/mkxl/cont-new.mkxl' system > files > jobname './tst-account', input './tst-account.tex', result './tst-account' fonts > latin modern fonts are not preloaded languages > language 'en' is active open source > level 1, order 2, name './tst-account.tex' modules > using user prefixed file 't-account' modules > 't-account' is loaded open source > level 2, order 3, name '/Users/hp/Library/context-osx-64/tex/texmf-modules/tex/context/third/account/t-account.mkiv' close source > level 2, order 3, name '/Users/hp/Library/context-osx-64/tex/texmf-modules/tex/context/third/account/t-account.mkiv' context report > file: tst-account-status.html mtx-context | fatal error: return code: 1 —— and the -status.html says: —— Error Undefined control sequence \startDEBITS File ./tst-account.tex Line 7 1 % !TEX program = lmtx 2 \usemodule[t-account] 3 \environment TACCOUNT 4 5 \startACCOUNT[left=S,middle=Bilanz,right=H] 6 7 >> \startDEBITS 8 \debit [Auto] {2000} 9 \debit [Bus] {5000} 10 \stopDEBITS 11 12 \startCREDITS 13 \credit [Bank] {1000} 14 \credit [Kasse] {200} 15 \credit [Kasse] {200} 16 \stopCREDITS 17 ——

2 4

Space around figure
by Alain Delmotte 28 Apr '22

28 Apr '22

2 2

installing modules
by Henning Hraban Ramm 28 Apr '22

28 Apr '22

Hi, while the rsync installation shown in https://wiki.contextgarden.net/Modules#ConTeXt_LMTX works well, it doesn’t install all available modules listed in modules.contextgarden.net. E.g. lua-widow-control and metaducks are missing. Why, and how can we change that? Has it to do with the t- prefix? Hraban

1 0

Fwd: lua-widow-control module error in LMTX
by Eduardo Bohoyo 27 Apr '22

27 Apr '22

Hello, Max: As I promised you this morning, I had time this evening to read more carefully all your remarks in the last mail. And now I can answer you with more basis. In my particular case, it is not necessary to consider any of the seven possible problems you describe from highest to lowest probability. The question you asked me in the first paragraph about "interesting" features in my ConTeXt code is the key. When I uncomment grid=yes in my \setuplayout, lwc makes its real appearance on the scene. I suppose that in other documents than mine, i.e. less complex, this performance would be a success. But in my file it is, considering my current aesthetic requirements, a failure. This is because for me grid=yes is a non-negotiable part of my code. As I told you this morning when I sent you my pdf without the module activated, but with the layout my way, I understand that lwc can have problems with a text whose chapters have capital letters and small caps on the first page with less text than on the following pages; with long quotations that involve paragraphs of different layout and separated from the main text; with more than one footnote in a row, with a bibliography at the end with French indentation; with vertical spaces separating two lines within the same chapter when in the dummy text there is a supposed change of scene within the narrative; with etc. etc., etc., etc... Anyway, after uncommenting grid=yes again, I will send you the log file, as you asked me. By the way, I do get some "Widow/Orphan NOT removed on page..." in spite of the rest of "successes" that move the final lines of my pages away from the result I would like, and that you have seen in the pdf I sent you this morning. Do you want the new pdf with lwc actually acting on my file? Then you can get a better idea of what I mean by the end of some pages when I comment grid=yes (apart from the mischief that happens with the horizontal spaces in some paragraphs of the bibliographic section). Or, if you prefer, and you need more feedback, I can send you my current code to use it as a test bench for " daring " texts. Greetings, edu El 27/4/22 a las 9:14, Max Chernoff escribió: > Quick question before I begin: are you using any especially "interesting" > ConTeXt features? By "interesting" I mean things like grid typesetting, > pagecolumns, bidirectional text, etc. I haven't tested lwc with every > possible ConTeXt feature, so there may be some adverse interaction. If > you are using something like this, try disabling it and see if that solves > anything (then let me know so that I can fix it!) > > On 2022-04-26 3:45 a.m., Eduardo Bohoyo wrote: > >> I can see "modules > 'lua-widow-control' is loaded". >> >> But, luckily, I can also see this: >> >> open source > level 2, order 4, name >> '/opt/luametatex/texmf-modules/tex/context/third/lua-widow-control/t-lua-widow-control.mkxl' >> >> resolvers > lua > loading file >> '/opt/luametatex/texmf-modules/tex/luatex/lua-widow-control/lua-widow-control.lua' >> succeeded >> close source > level 2, order 4, name >> '/opt/luametatex/texmf-modules/tex/context/third/lua-widow-control/t-lua-widow-control.mkxl' >> >> module > lua-widow-control > Already enabled > > Ok, so this is good; lwc is for sure being loaded successfully. > >> No line such as "Widow/orphan detected. Attempting to delete". >> >> I see interleaved new groups with the same line always repeating a >> warning message throughout the whole file. In short, there are 613 >> new lines with the message "luatex warning > tex: left parfill skip >> is gone". >> But I didn't give it any importance, because I interpreted that they >> could be inherent to the module. > > Well this at least narrows the issue down quite a bit. Lwc runs in pretty > much two stages: when a paragraph has finished being broken by TeX, lwc > saves the paragraph. The second stage is ran just before each time the > output routine is triggered so that lwc can remove the widows and orphans. > > Due to an lwc bug, the first stage results in the "left parfill skip" > warning being printed twice for each paragraph. Normally this is quite > annoying, but here it is good -- we know for sure that the first stage > is running just fine. > > It is the second stage where you should get the "Widow/orphan detected" > message, but this isn't happening. The code here is at lwc.lua:362-388. > > Here is a list of all possible reasons, in order of likelihood, why > "Widow/orphan detected" wouldn't be printed when there is actually > a widow or orphan: > > (Just listing all of these to make sure that *I* don't forget > anything. I'd > say that 1 and 2 are the only ones that are actually likely -- you can > probably ignore all of the others) > > 1. "\clubpenalty" and/or "\widowpenalty" are either zero or infinite > > In these cases, lwc can't distinguish a widow or orphan from other > penalties, so it doesn't do anything. You can check for this with > > \showthe\widowpenalty > \showthe\clubpenalty > > some time after "\starttext". This will print the values to the log > file. The values should probably be "1", but things like "150" and > "5000" are fine too. If you see negative values, "0", or values > greater than ten thousand, then something is wrong here. > > 2. Something is "hiding" the widow/orphan penalties from lwc. > > Something like "\vadjust{\penalty X}" or the e-TeX "\-penalties" > commands could potentially do this. > > One potential solution for (a subset of) this problem would be to > modify lwc.mkxl to insert "\directsetup{*reset}" at line 52, to > get: > > \startsetups[*default] > \directsetup{*reset} > \clubpenalty=\lwcparameter{orphanpenalty} > \widowpenalty=\lwcparameter{widowpenalty} > \displaywidowpenalty=\lwcparameter{widowpenalty} > \brokenpenalty=\lwcparameter{brokenpenalty} > \stopsetups > > If that doesn't do anything, keep the above modifications but also > insert > > \setups[*default] > > after "\starttext" in your test document. > > 3. Lwc hasn't saved any paragraphs since the last output routine. > > Since we know that the first stage is running, this shouldn't be > possible unless there is a weird bug somewhere else. > > 4. A weird engine/format bug. > > The LMTX test file was successful on Debian x86_64 three days ago > > https://github.com/gucci-on-fleek/lua-widow-control/runs/6144354147?check_s… > > so something quite weird would have to be going on here. > > 5. Something is overwriting the "pre_output_filter" callback. > > Now this is an interesting one. ConTeXt has frozen most of the core > engine callbacks, but "pre_output_filter" is unfrozen and unassigned. > There is a ConTeXt interface for most of the other callbacks, but here > I need to fallback to the low-level interface. With this interface, > you can only register a single callback, so it is possible that some > other package is overwriting the callback. To test this, the very > beginning of your document should look like: > \usemodule[lua-widow-control] > \startluacode > lwc.callbacks.disable_box_warnings.enable = function () end > lwc.callbacks.disable_box_warnings.disable = function () end > callback = nil > \stopluacode > > If you get a really strange error from some other package/module (not > lwc), then this may be the issue. Fairly unlikely. > > 6. The values of "\club/widowpenalty" change between the paragraph > being typeset and the output routine being triggered. > > I can't imagine this happening for *every* page in a document > except unless you are specifically trying to do this. Fairly > unlikely. > > 7. You have the exact Lua code > lwc.callbacks.remove_widows.disable() > written in your document. Exceedingly unlikely. > >> On the other hand, the distribution and size of my paragraphs take >> great care that their "design" optimises the module's goodness, >> except, of course, for the first pages of each of the nine dummy text >> chapters (they start at a third of a page). > > Well as long as you aren't seeing > > Widow/Orphan NOT removed > > in your log file then your text should be fine. > >> I will go over the lua-widow-control.pdf document once more in case >> there is a tiny detail I am missing, but I think, if I keep going at >> this pace, I will end up learning it by heart. > > There's probably not too much else in there -- and the documentation > is a bit of a mess right now anyways. > > --- > > If none of the above solutions solved anything, then what I'll need to > debug further will be for you to insert > > \setuplwc[debug=true] > > into your document right after you load lwc. Then, send me the full > log file -- probably as a link since it will be quite large. > > Thanks. > > -- Max >

1 0