- dev-context - NTG Mailing Lists

Re: [dev-context] setup-en.pdf and mkiv command list
by Idris Samawi Hamid ادريس سماوي ح امد 13 May '17

13 May '17

On Sat, 13 May 2017 13:41:04 -0600, Idris Samawi Hamid ادريس سماوي حامد <Idris.Hamid(a)colostate.edu> wrote: CHANGE > Copying the text of setup-en.pdf to a text file gives usable results but > a text file with some regular structure might be better. TO Copying the text of setup-en.pdf to a text file gives usable results but a text file with some regular structure, auto-generated via the script, might be better. -- Idris Samawi Hamid, Professor Department of Philosophy Colorado State University Fort Collins, CO 80512

1 0

setup-en.pdf and mkiv command list
by Idris Samawi Hamid ادريس سماوي ح امد 13 May '17

13 May '17

Dear gang, We need to generate a complete list of mkiv commands. setup-en.pdf has everything but some clarification and modification is needed: 1. Clarification: Does setup-en.pdf includes both mkii and mkiv commands? If so, then can a version of the auto-generation script be made that will generate a version setup-mkiv-en.pdf that is complete but restricted to mkiv commands? [Is the auto-generation script publicly available?] 2. Modification: It appears that all command names that appear in slanted text are used to mention user-defined commands of a particular class, e.g., /\BACKGROUND/ - slanted text which obviously names each of a class of commands defined by \definebackground - regular text Can a version of the auto-generation script be made that will generate a version setup-mkiv-strict-en.pdf that is restricted to mkiv commands explicitly defined in mkiv, excluding class commands or anything else represented in slanted text? 3. Although it is intuitive, a legend precisely explaining the semantics of the command list in setup.pdf would be useful. If there is already one available, could you point it out to me? 4. Would it be possible for the auto-generation to export the command list to a semi-formatted text file? Copying the text of setup-en.pdf to a text file gives usable results but a text file with some regular structure might be better. In sum: we need - urgently - a comprehensive ConTeXt command list restricted to mkiv that excludes class names for user definitions and the like. Any help is greatly appreciated, and thanks in advance! Best wishes Idris -- Idris Samawi Hamid, Professor Department of Philosophy Colorado State University Fort Collins, CO 80512

1 0

Re: [dev-context] [MacTeX] Context Problem?
by Norbert Preining 04 May '17

04 May '17

Hi ConteXt people, here a problem report from Herbert on MacOS, but it is the same on Linux in tlpretest. Thanks Norbert On Wed, 03 May 2017, Herbert Schulz wrote: > Howdy, > > I know virtually nothing about ConTeXt but have a few very simple test files that I picked up from who knows where. In the process of testing TeX Live 2017 pretest I happened to try out the latest ConTeXt on the enclosed file (all updates, including context, this morning). I also enclose the pdf output. > > I checked with the final TeX Live 2016 and the problem doesn't exist in that distribution. > > > > I'm sure there are some folks on this list that understand what is happening here and can pass on worthwhile information to the ConTeXt folks. > > Good Luck, > > Herb Schulz > (herbs at wideopenwest dot com) > -- PREINING Norbert http://www.preining.info Accelia Inc. + JAIST + TeX Live + Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

2 2

LuaTeX 1.0.3 announcement
by luigi scarso 17 Feb '17

17 Feb '17

============================================================== LuaTeX Release 1.0.3 was released 2017021514 ============================================================== This is a minor upgrade and probably this version will go on texlive. There are a couple of fixes and additions. - We added a few a few more helpers in the pdf namespace (like set|get]gentounicode, [set|get]omitcidset and set|get]decimaldigits. Some helpers were moved from the tex to the pdf namespace. - We added a build_page_insert callback for inserts so that one can for instance adapt spacing on demand. - On the agenda has been some more control over word start and end in hyphenation and this is now possible via hyphenationbounds. We also updated the manual with some more details. - An old tracker item with respect to control over spacing around math was revived and has resulted in mathsurroundmode (one can wonder how useful this is). - We improved the resolution detection in included jpeg images. - An ffi library has been added to luatex so that it is more in sync with luajittex. This permits easy and flexible loading of libraries. Our policy is to make luatex as lean as possible with no dependencies and this is a step towards that. Eventually we hope to support all relevant platforms. - The glue and skip register accessors have been improved as a step in freeing the user from glue spec management. - We added a few more getters and setters for nodes in order to get a more consistent set. - Irrelevant fields have been removed from the status table and an engine identifier has been added. - Of course there are numerous fixes and improvements but none of these have consequences for the interfaces. - The manual has been updated but will be improved over time. Have fun, Hans, Luigi, Taco

1 0

\pdfannot
by Taco Hoekwater 14 Feb '17

14 Feb '17

Hi Hans, I just tried this with a fairly new ConTeXt: \starttext \message{pdfannot: [\meaning \pdfannot] pdflastannot: [\meaning \pdflastannot] \stoptext reports pdfannot: [\relax] pdflastannot: [\count1160] which is not really useful. It actually hit me inside a file that was actually using \pdfannot to do some fancy stuff, which was working fine a few years back. (I know it is now called "\pdfextension annot", that is not actually the problem) If you do no longer want to support the primitives in ConTeXt, sure. But could you at least produce a message and/or error ? In particular, the \let \pdfannot \relax creates mayhem inside the produced PDF, because of all the associated keywords in the primitive \pdfannot implementation that are now suddenly being typeset as-is, which is rather messy. Best wishes, Taco

1 0

Solarized colors
by Aditya Mahajan 12 Feb '17

12 Feb '17

Hi, I am wondering if there is any interest in adding solarized colors to the core. I am attaching colo-imp-solarized.mkiv file. (Essentially the same file will work in MkII). For those who do not know, solarized (http://ethanschoonover.com/solarized) is a 16 color palatte designed with a precise LAB lightness between the colors and is supposed to work well in a variety of lighting conditions. I have named the colors such that loading this will override the default color values of yello, orange, red, magenta, violet, blue, cyan, and green (X11 does the same, but X11's color definitions match the default). Another option is to either use CamelCase names or names such as 'solarizedYellow', etc. If you think that it is not worth having such small color palattes in the core, then I can create a separate module that collects these. Aditya

2 2

Re: [dev-context] local allocation in ConTeXt
by Sašo Živanović 26 Jan '17

26 Jan '17

Dear Hans, thank you very much for helping me out here. Aditya's rephrasal of the question might have shown a tree but hidden the forest ... ;-) Let me try to explain below, but please also take a look at my original post, https://mailman.ntg.nl/pipermail/dev-context/2016/003346.html. As far as I can see, in your 10 million example I can only work on one of the local boxes at the time, whereas I need to save an undetermined number of boxes, do some computation which uses dimensions of all these boxes (this computation potentially invokes user's code, so I don't have control over it), and then use all the saved boxes. (Btw, saving just the dimensions is not an acceptable solution, both because of speed and because in general, setting the box with same content twice won't yield the same result.) As the number of needed boxes cannot be known in advance, I'd like to be nice and "give them back" to the allocation system after using them. And I *do* know how to do that (see localloc, elocalloc, or etex), but I'm not sure if it would cause any trouble in ConTeXt: I'd prefer "not to mess with allocation" indeed and have the issue fixed systemically. > The overhead is just one box per name and you probably don't allocate > a million unique tempboxes as you will then already ran out of names. I believe this overhead is precisely what I'm trying to avoid. A further detail of my situation might help. I've got, for each node of the tree: \locbox\tempbox \setbox\tempbox\hbox{...} \expandafter\let\csname node<id>@box\endcsname\tempbox > Messing with the allocation can fail because when the content of the > boxes triggers a new box allocation itself that one might be forgotten > as well. I'm not sure I get this. Even if the new box allocation was global (so, the usual \newbox)? Best, Sašo P.S. And I did test it! Albeit with two iterations, not ten million. ;-) On 24. 01. 2017 13:48, Hans Hagen wrote: > On 1/24/2017 10:47 AM, Sašo Živanović wrote: >> I'm afraid this doesn't do the trick: \c_syst_last_allocated_box is >> definitely incremented. >> >> Let me try explaining again. This is essentially what I do: >> >> { >> \newbox\TempBox >> \setbox\TempBox\hbox{Box One} >> \let\BoxOne\TempBox >> \global\let\TempBox\relax >> >> \newbox\TempBox >> \setbox\TempBox\hbox{Box Two} >> \let\BoxTwo\TempBox >> \global\let\TempBox\relax >> >> \the\numexpr\BoxOne: [\box\BoxOne] >> \the\numexpr\BoxTwo: [\box\BoxTwo] >> } >> >> But I want the number of available box registers at entering and exiting >> the group to be the same, and substituting \newbox for \locbox is what >> does the trick in my package. So I can run the following a million times: >> >> { >> \newlocalbox\TempBox >> \setbox\TempBox\hbox{Box One} >> \let\BoxOne\TempBox >> \global\let\TempBox\relax >> >> \newlocalbox\TempBox >> \setbox\TempBox\hbox{Box Two} >> \let\BoxTwo\TempBox >> \global\let\TempBox\relax >> >> \the\numexpr\BoxOne: [\box\BoxOne] >> \the\numexpr\BoxTwo: [\box\BoxTwo] >> } >> >> Each of the million "\the\numexpr\BoxOne" should produce the same >> number, whereas in the \newbox-based example these numbers increment. > > I suppose you didn't test it ... > > \starttext > > % \unprotect > % > % \installcorenamespace{localbox} > % > % \unexpanded\def\newlocalbox#1% > % {\expandafter\let\expandafter#1\csname\??localbox\string#1\endcsname > % \ifx#1\relax > % \syst_aux_new_localbox#1% > % \fi} > % > % \def\syst_aux_new_localbox#1% > % {\expandafter\newbox\csname\??localbox\string#1\endcsname > % \newlocalbox#1} > % > % \protect > > \newbox\MyBoxA \number\MyBoxA > > \dorecurse{10} { > \dorecurse{1000000} { > \newlocalbox\TempBox > } > \writestatus{!!!}{#1 million done} > #1: \number\TempBox\par > } > > \newbox\MyBoxB \number\MyBoxB > > \stoptext > > The overhead is just one box per name and you probably don't allocate a > million unique tempboxes as you will then already ran out of names. > > Messing with the allocation can fail because when the content of the > boxes triggers a new box allocation itself that one might be forgotten > as well. > >> Best, >> Sašo >> >> On 24. 01. 2017 09:52, Hans Hagen wrote: >>>> You are asking how to define a macro, \locbox, such that the following >>>> code should not change the value of \c_syst_last_allocated_box. >>>> >>>> \bgroup >>>> \locbox\BoxOne >>>> \locbox\BoxTwo >>>> >>>> \BoxOne\hbox{Box One} >>>> \BoxTow\hbox{Box Two} >>>> % Do some measurement based on the size of the boxes >>>> \egroup >>>> >>>> The fact that a LaTeX package implements this behaviour by allocating >>>> local box numbers from the end seems to be an implementation detail. >>>> >>>> I don't know the best way to implement such a macro in ConTeXt, but I >>>> want to make sure that the user-level behavior that you want is >>>> properly >>>> understood. Given the details in your question, one can easily lose the >>>> forest for the trees (pun intended :-) >>> >>> \unprotect >>> >>> \installcorenamespace{localbox} >>> >>> \unexpanded\def\newlocalbox#1% >>> {\expandafter\let\expandafter#1\csname\??localbox\string#1\endcsname >>> \ifx#1\relax >>> \syst_aux_new_localbox#1% >>> \fi} >>> >>> \def\syst_aux_new_localbox#1% >>> {\expandafter\newbox\csname\??localbox\string#1\endcsname >>> \newlocalbox#1} >>> >>> \protect >>> >>> \starttext >>> >>> \newlocalbox\BoxOne >>> \newlocalbox\BoxTwo >>> >>> \setbox\BoxOne\hbox{Box One} >>> \setbox\BoxTwo\hbox{Box Two} >>> >>> [\box\BoxTwo] >>> [\box\BoxOne] >>> >>> \let\locbox\newlocalbox >>> >>> \stoptext >>> >>> ----------------------------------------------------------------- >>> Hans Hagen | PRAGMA ADE >>> Ridderstraat 27 | 8061 GH Hasselt | The Netherlands >>> tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl >>> ----------------------------------------------------------------- >>> _______________________________________________ >>> dev-context mailing list >>> dev-context(a)ntg.nl >>> https://mailman.ntg.nl/mailman/listinfo/dev-context >> > >

2 5

local allocation in ConTeXt
by Sašo Živanović 24 Jan '17

24 Jan '17

Hi! I'm the author of a PGF/TikZ-based LaTeX package Forest for drawing (linguistic) trees. I have received several requests to support ConTexT and I'm trying to do that now. Forest uses a lot of \boxes. Actually, the number of boxes used cannot be known in advance, as it depends on the document. Here's why: Forest's main job is to place the nodes of a tree so that they don't overlap and to do that, it needs to first typeset the individual nodes and measure them. The typeset nodes are kept around and later used when typesetting the entire tree. There are three reasons for keeping the typeset nodes, and not typesetting them again as part of the entire tree. First (at least historically): performance. Second: there is no guarantee that running the same code twice will result in the same box. Third: changing this now would break compatibility. The typeset nodes are kept in "local" boxes. They are created using \locbox, which is defined either by plain eTeX format or package elocalloc.sty for LaTeX >2015. (Prior to LaTeX 2015, \locbox was defined in etex.sty.) elocalloc.sty's \locbox is somewhat broken, but still works, mainly because it seems no other package is using local allocation. ;-) Using normal, "global" boxes, created by \newbox, would be bad. If a \newbox was simply executed for each new node, the number of used boxes would remain increased even after Forest was done with a tree, so in a document with lots of big trees, the upper limit of 32000+ could actually be hit. An alternative approach would be to track and reuse boxes which were created by \newbox by are not used anymore. But implementing such a tracking mechanism seems quite complicated, and besides, it would not be perfect: after exiting the TeX group where the tree is drawn, the allocated boxes would persist. (So, from the outside perspective, Forest's box usage in the entire document would equal the box usage of the largest tree.) The approach taken in the implementation of \locbox seems quite appealing in its simplicity: The local boxes (counts etc) are allocated "from the top" (starting at 32767 and going down) and all the \chardefs and allocation register changes are local (i.e. not \global). A bit of care to prevent clashes with global allocation "from the bottom", and that's it. I've studied the allocation mechanism of ConTeXt --- but note that I'm new to ConTeXt! --- and it seems that I'd know how to implement \loc<thing>s using "from the top" approach, but there are two, or rather three, problems. (I took a look at both MKII and MKIV, but the changes seemed mostly cosmetic, so I concentrated on MKIV.) 1. I'm not sure how happy ConTeXt were if I changed the value of \c_syst_max_allocated_register. The name seems to imply it should be constant. 2. Simply decreasing \c_syst_max_allocated_register would while doing a \locbox would also decrease the upper limit for, say, \loccount, as they use the same upper limit, i.e. \c_syst_max_allocated_register. A proper way would be to declare \c_syst_max_allocated_box_register etc. Again, I have no idea how such a change would impact other parts of the system. (Btw, elocalloc.sty's implementation, unlike the plain eTeX one, suffers from precisely this problem.) 3. It seems that, unlike in the messy LaTeX world, ConTeXt people like to do things The Right Way. ;-) As making a change like this in a module is surely not The Right Way, I hope that ConTeXt developers can help me out here, either by implementing the local allocation (I'm happy to assist in any way) or by maybe suggesting an alternative approach. (Btw, if it helps, I guess a MKIV-only solution would be acceptable to most users.) Thanks in advance, Sašo Živanović

3 4

syst-aux.lua
by Wolfgang Schuster 17 Jan '17

17 Jan '17

Hi, line 280 (extra t in triple): local option = ( P("single") + P("double") - + P("tripple") + + P("triple") + P("quadruple") + P("quintuple") + P("sixtuple") ) * (P("empty") + P("argument")) Wolfgang

1 1

Re: [dev-context] Installing old version of context
by Taco Hoekwater 18 Nov '16

18 Nov '16

Hi, > On 18 Nov 2016, at 00:55, Lars Hamren <lh(a)sdu.se> wrote: > > > Hi, > > > i'm not sure if there are zips on the garden > > Not that I can find. There are old zips at http://context.aanhet.net/ , but there was no easy access to them until now. I just added that, and the archived zips from pragma-ade.com are now all below this directory: http://context.aanhet.net/archives/ Folder names are based on the time of mirroring. Note that I occasionally weed out duplicate mirrored files, only keeping the oldest one, so old folders sometimes are not a complete mirror of http://www.pragma-ade.com/context/ , you may have to go back a few archives to get a full set of zip files. Those zip files are also only the content of texmf-context, though. > > >> I'm sorry, but that does not answer my question. Can I install > >> a version from a certain date (à la version control), and if so, how? > > > > https://bitbucket.org/phg/context-mirror.git > > Thanks. Unfortunately it only contains the files from tex/texmf-context, > not e.g. the bin directories. > > /Lars > _______________________________________________ > dev-luatex mailing list > dev-luatex(a)ntg.nl > https://mailman.ntg.nl/mailman/listinfo/dev-luatex Taco Hoekwater Elvenkind BV

3 2