November 2021 - ntg-context - NTG Mailing Lists

\doifinstring: strange characters on the output
by Tomas Hala 02 Nov '21

02 Nov '21

Hi all, I noticed that \doifinstring produces quite strange output if a command follows immediately (or with any amount of spaces) after the substring I am searching for: -------------------------------------MWE \starttext \def\xxx{asdf \bf Z:\bf asdf} % strange \def\xxx{asdf \bf Z: \bf asdf} % strange \def\xxx{asdf \bf Z:: \bf asdf} % OK \def\xxx{asdf \bf Z: text \bf asdf} % OK \def\xxx{asdf \bf Z:{} \bf asdf} % OK \doifinstring{Z:}{\xxx}{yes!} \stoptext ----------------------------------OUTPUT fbf@yes! fbf@yes! yes! yes! yes! ---------------------------------------- If I insert another character, text or {} between them (with or without spaces), all is ok. I would like to ask what is the cause of this behavior and how to use the \doifinstring to prevent the "fbf@" on the output. Best wishes Tomáš

2 3

check installed program using Lua
by Pablo Rodriguez 02 Nov '21

02 Nov '21

Dear list, is there a way if a program is installed on the computer using Lua. I have the following sample: \starttext \startluacode filename = tex.jobname .. ".pdf" os.exec("dir " .. filename) \stopluacode \stoptext Is there a way to wrap os.exec() in the sample so that it only runs if "dir" is available? I know that os.name would be an option here, but not in my real world document. Many thanks for your help, Pablo -- http://www.ousia.tk

3 4

new upload
by Hans Hagen 02 Nov '21

02 Nov '21

Hi, I uploaded a new lmtx. There is a new low level manual (lowlevel-localboxes) that describes the extended local boxes interface as well as a layer on top. New is that we have classes which makes this (engine) mechanism more useable. It definitely is some low level mechanism but you can for instance use if for high performance efficient maginal notes and line numbering in controlled situations. (There is some room fro optimization in the engien but I deal with that later.) 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 -----------------------------------------------------------------

3 4

Cannot access Lua function
by kauśika cittūr 01 Nov '21

01 Nov '21

Dear list, In one of my documents I have this lua block – \startluacode local metadata = lpdf.getmetadata(); ⋮ \stopluacode to modify some metadata fields. The file compiles with the latest LMTX (2021.10.28) without any errors but no PDF is produced. In the log, the following line is present : backend > blocked > function 'getmetadata' is not accessible I recall that this was working just fine some days back. Please advise. Thanks, kauśika

3 7

SyncTeX setup
by Henning Hraban Ramm 01 Nov '21

01 Nov '21

Hi, has anyone a working SyncTeX setup with ConTeXt LMTX for anything else than TeXshop? With LaTeX, it works for me with Skim (+ Atom/Textadept/TeXworks) and TeXstudio. And in TeXshop we got our own parser. But can we expect others to adapt to our “superior” SyncTeX format? (I don’t understand the format yet and can’t tell what’s the difference.) Hraban

2 1

\externafigure and \at do not work together
by a badin 01 Nov '21

01 Nov '21

Hello, perhaps this is how it is supposed to work, but: \externalfigure[clock.jpg][clock] \starttext \at[clock] refers to a clock \stoptext produces "?? refers to a clock", instead of "1 refers a clock" --- the wiki of \at says, that labels of figures can be refered to. Is this a bug, or can only some labels be refered to? I was able to fix it using: \reference[clock]{\externalfigure[clock.jpg]} \starttext \at[clock] refers to a clock \stoptext and \externalfigure[clock][] \starttext \at \stoptext produces an interesting artwork... so I thought maybe this could be a bug. LMTX 2021.10.21 Best, Andrej

4 4

Bloody PDF boxes and cr*p marks!
by Henning Hraban Ramm 01 Nov '21

01 Nov '21

Comrades! There must have been a time when PDF boxes (i.e. CropBox, TrimBox, BleedBox) worked as they should, but it must have been a short time. The wiki page https://wiki.contextgarden.net/PDF_Boxes is mostly a documentation of bugs and workarounds, but even that is not entirely correct (any more?). I gave up on that subject and still fix the boxes with Acrobat Pro whenever I need them to be correct. But that’s no solution. (And it’s probably also my fault, since I was one of those who wanted this implemented and then didn’t check enough if it does what it should.) Ok, calm down, try again... * MediaBox is supposed to be the biggest, i.e. print sheet. * CropBox is the viewable area – usually same as MediaBox or TrimBox makes sense. * BleedBox must be TrimBox plus bleed. * ArtBox is neglectable for whole layouts (same as TrimBox might make sense), just interesting in \externalfigure. According to PDF Standard, MediaBox is the only required one; but CropBox is the most important one, since PDF viewers rely on it. With \setuppaper[A4] all boxes can be the same (or undefined). Status quo. With \setuppaper[A4][A4,oversized] I’d expect ConTeXt to set... * MediaBox and CropBox to the bigger format * TrimBox to the page format (A4) * BleedBox also to the page format, while no bleed is defined Status quo: no additional boxes defined. Beware, \showframe draws a green box at the paper size (supposed TrimBox), this is misleading in Acrobat Reader & Pro, where the TrimBox is shown in green (if this option is activated)! Bleed is to be defined in \setuplayout: \showframe \setuppapersize[A4][A4,oversized] \setuplayout[ location=middle, bleedoffset=-5mm, marking=on, ] %\setupinteractionscreen[width=max,height=max] \starttext X \stoptext Status quo: * works only with \setupinteractionscreen * bleedoffset must be negative * BleedBox is set, but not TrimBox (TB > BB is a nesting error) Beware, \setupbleeding refers only to stretching of images (\externalfigure)! This gives more or less correct results: \setuplayout[ location=middle, trimoffset=-7.5mm, bleedoffset=3mm, marking=on, ] * still works only with \setupinteractionscreen * negative trimoffset defines the TrimBox (actual page size), value is subtracted from sheet size. * positive bleedoffset (internally added to trimoffset) * to define trimoffset, I must know the difference between paper size and sheet size ("oversized" adds 15 mm). I.e. ConTeXt “thinks” from the sheet size instead from the (IMO more natural) paper size. For me, the more natural setup would be: \setuplayout[ trimoffset=0mm, % from the paper size outward bleedoffset=3mm, % same, independent of trimoffset ] % ... and no dependency on interactionscreen! So far, I ignored cropoffset. The parameter in itself works as I expected it to: cropoffset=3mm decreases the visible area by 3mm on each side. But it also moves the other boxes by that value! IMO that makes no sense, CropBox can be completely independent of the other boxes! It would be logical to use negative values here, since the size decreases, in opposite to my suggested handling of the other parameters. Yes, that would mean a backward incompatible change. But how many of us rely on the strange current behavior? Please let us fix this! In some cases it makes sense to have different values on e.g. inner and outer edges; I feat that would add a plethora of additional parameters (leftbleedoffset, innerbleedoffset...). Maybe give a list like in CSS? bleedoffset={3mm,3mm,3mm,0mm} – top, right, bottom, left order implied; not very “ConTeXt style”. Hraban

4 9