Re: [NTG-context] framedtext is (still) broken in LMTX
On 11/30/2020 15:05, Wolfgang Schuster wrote:
Rik Kabel schrieb am 30.11.2020 um 18:15:
On 11/29/2020 17:15, Hans Hagen wrote:
On 11/29/2020 10:33 PM, Rik Kabel wrote:
With ConTeXt ver: 2020.11.28 13:18 LMTX fmt: 2020.11.29 the
*\framedtext* output is consistently *0.8\textwidth*. MkiV gives
the expected result.
\starttext
\framedtext{Fail}\par
\framedtext[width=fit]{Fail}\par
\framedtext[width=3cm]{Fail}\par
\framedtext[width=0.8\textwidth]{Fine by accident}\par
\framedtext[width=\textwidth]{Fail}\par
\framed{Fine}\par
\framed[width=fit]{Fine}\par
\framed[width=3cm]{Fine}\par
\framed[width=0.8\textwidth]{Fine}\par
\framed[width=\textwidth]{Fine}\par
\stoptext
fixed in next upload (tomorrow)
Sadly, *\framedtext* still appears to have a problem with the default
width, although with today's update one can now explicitly set the
width. (Nothing I can find in the docs suggests that *\framedtext*
has a different default width than *\framed*. Perhaps I missed it.)
There is nothing wrong with framedtext, the command always used a
fixed width as default setting.
Wolfgang
Wikified.
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
[NTG-context] Adding syntax highlighting when typesetting from xml (asciidoc/docbook)
Hi,
A while ago Hans provided an example of typesetting a document from a
docbook source.
I'm attaching an over-simplified version of the initial module (a
somewhat more complete version exists, but it still needs lots of
work) and a minimum working example with XML.
I'm not sure how to extend the xml parser to support typesetting from
something like this:
Hello World in C and ConTeXt
#include
stdio.h
int main()
{
printf("Hello, World!\n");
return 0;
}
\starttext
Hello world!
\stoptext
Maybe using the vim module would be the right approach here (since the
built-in parser only has support for a limited set of languages), but
I'm not exactly sure about the implementation to achieve that goal.
I started with
\startxmlsetups xml:programlisting
\dontleavehmode
\startframedtext[background=color,backgroundcolor=lightgray]
\obeylines
\tt
\xmlflush{#1}
\stopframedtext
\stopxmlsetups
but something more is needed to properly handle new lines and to
properly pass the text to vim, for example.
Any hints welcome.
Thank you,
Mojca
http://docbook.org/ns/docbook; xmlns:xl="http://www.w3.org/1999/xlink; version="5.0" xml:lang="en">
Syntax highlighting with AsciiDoc
2020-11-30
Hello World in C
#include stdio.h
int main()
{
printf("Hello, World!\n");
return 0;
}
\starttext
Hello world!
\stoptext
test-syntax-highlighting.tex
Description: Binary data
m-asciidoc-basic.tex
Description: Binary data
test-syntax-highlighting.adoc
Description: Binary data
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] framedtext is (still) broken in LMTX
Rik Kabel schrieb am 30.11.2020 um 18:15:
On 11/29/2020 17:15, Hans Hagen wrote:
On 11/29/2020 10:33 PM, Rik Kabel wrote:
With ConTeXt ver: 2020.11.28 13:18 LMTX fmt: 2020.11.29 the
*\framedtext* output is consistently *0.8\textwidth*. MkiV gives the
expected result.
\starttext
\framedtext{Fail}\par
\framedtext[width=fit]{Fail}\par
\framedtext[width=3cm]{Fail}\par
\framedtext[width=0.8\textwidth]{Fine by accident}\par
\framedtext[width=\textwidth]{Fail}\par
\framed{Fine}\par
\framed[width=fit]{Fine}\par
\framed[width=3cm]{Fine}\par
\framed[width=0.8\textwidth]{Fine}\par
\framed[width=\textwidth]{Fine}\par
\stoptext
fixed in next upload (tomorrow)
Sadly, *\framedtext* still appears to have a problem with the default
width, although with today's update one can now explicitly set the
width. (Nothing I can find in the docs suggests that *\framedtext* has
a different default width than *\framed*. Perhaps I missed it.)
There is nothing wrong with framedtext, the command always used a fixed
width as default setting.
Wolfgang
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] Using ConTeXt-LMTX for modern Mathematically-Literate-Programming 1/2
On 11/30/2020 10:51 AM, Stephen Gaito wrote:
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.
maybe something
\startmystuff
\stopmystuff
and then you can hook something into startmystuff and \stopmystuff
2. After line/paragraph/page layout but before PDF generation.
pdf is generated per page, if needed one can kick in a shipout overload
but keep in mind that multipass data is flushed as part of the shipout
(because it is often location and order bound)
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.
hm, the problem is always in the 'state' of all kind of variables
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.
not sure what you mean here ... what is fast? or: how slow is it now?
what is the bottleneck? can you cache data that didn't change?
a large document is normally split up in sections that can be processed
independent
\starttext
\dorecurse{1}{\samplefile{ward}\par}
\stoptext
runs on my 2013 laptop at over 65 pages per second
quite often performance is hit by inefficient styling and such .. it's
no problem to bring a tex system a grinding halt
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".
yes and often something is left over for a next page so it's kind of fluid
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?
sure, you can kick in handlers at various stages (assuming that you keep
in mind where you kick them in as there is some order involved)
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?
you can but linebreak is not the most costly one, you probbaly want to
intercept the list builder but when you do that you can as well do a
\stoptext which prevents further reading of content (but i probably
misunderstand)
Could I use the "pre_output_filter" to "return" an empty value and
hence "stop" PDF generation?
assuming a properky structured document forcing a \stoptext should work
in most cases
(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)
actually, the callbacks themselves hardly change, but the code plugged
into them might occasionally (a lot of mkiv code is already quite old so
i'm now looking at it and see if i can use some recent tricks)
ALTERNATIVE QUESTION: Would it be possible to provide official
ConTeXt-LMTX "modes" which suppress further computation at these points?
the question is: what do you want to suppress? best first identify the
bottleneck and then figure out what can be skipped (as mentioned:
multipass data can be made more independent I guess but it still demands
some calculations and analyzing and it's that bit that takes the time)
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.
i need more info (also from others then) about what the reason, goal and
possible gain is
- tex: the context code is quite efficient, and tex is quite fast, so
there's little to gain there (but as said one can write slow macros that
spoil that game)
- lua: on the average lua is fast but garbage collection can be of
Re: [NTG-context] framedtext is (still) broken in LMTX
On 11/29/2020 17:15, Hans Hagen wrote:
On 11/29/2020 10:33 PM, Rik Kabel wrote:
With ConTeXt ver: 2020.11.28 13:18 LMTX fmt: 2020.11.29 the
*\framedtext* output is consistently *0.8\textwidth*. MkiV gives the
expected result.
\starttext
\framedtext{Fail}\par
\framedtext[width=fit]{Fail}\par
\framedtext[width=3cm]{Fail}\par
\framedtext[width=0.8\textwidth]{Fine by accident}\par
\framedtext[width=\textwidth]{Fail}\par
\framed{Fine}\par
\framed[width=fit]{Fine}\par
\framed[width=3cm]{Fine}\par
\framed[width=0.8\textwidth]{Fine}\par
\framed[width=\textwidth]{Fine}\par
\stoptext
fixed in next upload (tomorrow)
Sadly, *\framedtext* still appears to have a problem with the default
width, although with today's update one can now explicitly set the
width. (Nothing I can find in the docs suggests that *\framedtext* has a
different default width than *\framed*. Perhaps I missed it.)
New overwrought example:
\definelayer [HRule]
[x=0mm,y=0pt,width=\textwidth,height=\textheight]
\setlayer [HRule]
[hoffset=0pt,voffset=10em]
{\blackrule[color=green,height=1pt,width=10cm]}
%setupframedtext [offset=0pt]
\definelayer [VRule]
[x=0mm,y=0pt,width=\textwidth,height=\textheight]
\setlayer [VRule]
[hoffset=0.75\textwidth,voffset=0pt]
{\blackrule[color=red,height=10em,width=1pt]}
\setupbackgrounds [text]
[background={HRule,VRule}]
\setupframedtext [offset=0pt]
\starttext
\framed{default width for \tex{framed} is {\tt fit}}\par
\framedtext{default width for \tex{framedtext} is not {\tt fit}. It
appears to be 0.75\tex{textwidth}}\par
\framedtext[width=10cm]{explicit width for \tex{framedtext} now
works}\par
\framedtext[width=fit]{{\tt fit} width for \tex{framedtext} now
works}\par
\stoptext
--
Rik
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] Problem with word not hyphenating
Pablo Rodriguez schrieb am 30.11.2020 um 17:16:
On 11/30/20 4:48 PM, Bruce Horrocks wrote:
The word "re-implementation" refuses to hyphenate and consequently
stick outs into the right margin.
I've tried using \hyphenation but it makes no difference.
[...]
Any suggestions, please?
Hi Bruce,
here you have a sample:
\setuphyphenation[method=traditional]
\registerhyphenationexception[en][re-im-ple-men-ta-tion]
\starttext
\startTEXpage[offset=1em]
\hyphenatedword{re-implementation}\\
\hyphenatedword{re||implementation}\\
\hyphenatedword{re--implementation}\\
\hyphenatedword{reimplementation}
\stopTEXpage
\stoptext
If you comment the first line, only "||" allows hyphenation.
Another option is to add \setbreakpoints[compound] to the document.
Wolfgang
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] Problem with word not hyphenating
On 11/30/20 4:48 PM, Bruce Horrocks wrote:
> The word "re-implementation" refuses to hyphenate and consequently
> stick outs into the right margin.
>
> I've tried using \hyphenation but it makes no difference.
> [...]
> Any suggestions, please?
Hi Bruce,
here you have a sample:
\setuphyphenation[method=traditional]
\registerhyphenationexception[en][re-im-ple-men-ta-tion]
\starttext
\startTEXpage[offset=1em]
\hyphenatedword{re-implementation}\\
\hyphenatedword{re||implementation}\\
\hyphenatedword{re--implementation}\\
\hyphenatedword{reimplementation}
\stopTEXpage
\stoptext
If you comment the first line, only "||" allows hyphenation.
I hope it helps,
Pablo
--
http://www.ousia.tk
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
[NTG-context] Problem with word not hyphenating
The word "re-implementation" refuses to hyphenate and consequently stick outs
into the right margin.
I've tried using \hyphenation but it makes no difference.
\showframe
\starttext
\hyphenation{re-im-ple-men-ta-tion}
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
re-implementation
tempor incididunt ut labore et doloremagna aliqua. Ut enim ad minim veniam,
quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo
consequat.
\stoptext
Any suggestions, please?
(LMTX current version: 2020.11.30 10:24)
--
Bruce Horrocks
Hampshire, UK
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
[NTG-context] Using ConTeXt-LMTX for modern Mathematically-Literate-Programming 1/2
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 ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
[NTG-context] Using ConTeXt-LMTX for modern Mathematically-Literate-Programming 2/2
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).
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:
> ...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).
(The ConTeXt I am using identifies itself as: ConTeXt ver: 2020.11.25
19:18 LMTX fmt: 2020.11.25 int: english/english)
I note that the output of `luametatex --help` includes the following
statement:
> Loading libraries is blocked unless one explicitly permits it (will
> be in 2.08+):
>
> --permitloadlib permit loading of external libraries (coming)
QUESTIONS:
1. Is this an oversight and `--permitloadlib` is meant to be working
now?
2. Is this a trivial fix (and might be fixed soon -- time permitting)?
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)?
4. Is this a case of "the `lua_checkstack` symbol will never be part of
luametatex"?
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)...
... it would however be useful to have an idea of which scenario is
most likely.
Again Many thanks for a wonderful (and stable) tool!
Regards,
Stephen Gaito
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] mathmatrix and internal lines
> On 29 Nov 2020, at 08:48, Otared Kavian wrote: > >> On 26 Nov 2020, at 23:23, Hans Hagen wrote: >> […] >> A bit more code needed but the next upload will have it. Of course you have >> to wikify it. >> >> Hans > > Hi, > I created a page on the wiki: > https://wiki.contextgarden.net/Matrix_in_maths > However the LMTX code is not typeset on the wiki. I'll see with taco whether > it is possible to have lmtx mode on the wiki. I plan to update the lmtx on the wiki sometime between now and new years’ eve. Sorry, I can not be more precise right now. Best wishes, Taco ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
