On 10/14/22 16:34, Alain Delmotte via ntg-context wrote:
> Hi!
Hi Alain,
many thanks for your help.
> For me it works! And
>
> also for this!
I’m afraid that I cannot make latest from 2022.10.14 10:16 with LuaTeX.
I’m on Linux64. I hope I may make it work with Win64.
As f
th version from 2022.09.11 20:44.
I attach an overlay of the results from both LuaMeTaTeX (in red) and
LuaTeX (in darkgreen).
It seems that MkIV is doing fine, but LMTX isn’t aligning the dots (for
some reason unknown to me).
Latest from 2022.10.14 10:16 gives exactly the same result for LMTX, and
Mk
4 10:16)
\stopsection
\stoptext
If I try to compile with LuaTeX (after deleting the cache), I get the
following error:
lua error > lua error on line 1 in file a.tex:
...tex/texmf-context/tex/context/fonts/mkiv/common-math.lfg:100: attempt
to index a nil value (field 'subsets'
.
The log tells me:
This is LuaTeX, Version 1.13.0 (TeX Live 2021)
Compiling with LMTX, i read:
ConTeXt ver: 2022.09.11 20:44 LMTX
And compiling with MkIV (of the TeX Live 2022):
This is LuaTeX, Version 1.15.0 (TeX live 2022)
in a setup where lmtx is leading mtxrun/context will use luametatex
While waiting for Mojca's attempts, for the moment I solved it by simply
copying the folder of the old Mac in which I had installed the Standalone
to the Mac M2.
I have slightly modified the TeXShop scripts and everything works.
The log tells me:
This is LuaTeX, Version 1.13.0 (TeX Live 2021
odules = all --fonts = all --goodies = all --context
> = latest --engine = luatex
>
> Where am I wrong?
I think that MkIV has been frozen since before macOS ARM was released,
so I wouldn't be surprised if an ARM version just doesn't exist.
I've never used macOS, but if this worke
--engine = luatex
Where am I wrong?
LMTX installation, on the other hand, should be successful (the folder
weighs 297.8 MB, as much as the Standalone one should weigh).
Thanks in advance.
Tommaso
___
If your question
er bisecting the snapshot-repo would work.
>> But I only have one LMTX binary; this font handling should be all in
>> lua code tho?
>
> It makes no sense to compare luametatex and luatex .. it's different
> machinery.
>
> Btw, some in the thread mention issues (
in
lua code tho?
It makes no sense to compare luametatex and luatex .. it's different
machinery.
Btw, some in the thread mention issues (like bad looking heros shapes)
but in your case there is no print at all, so that is different. Isn't
there some error log in these printer?
Hans
gt;>> for some built-in PDF interpreter?
>>
>>> we basically use the old pre 1.6 embedding, same as luatex
>> I saw that the new code renumbers the glyphs, so it uses 0001, 0002
>> etc instead of the mix of various slot numbers in luatex. Perhaps
>> the pri
as luatex
I saw that the new code renumbers the glyphs, so it uses 0001, 0002
etc instead of the mix of various slot numbers in luatex. Perhaps
the printers don't like that.
indeed, soem control code confusion; a few days ago i suggested a test
for that and got no response yet
Hans
Am Tue, 4 Oct 2022 18:09:28 +0200 schrieb Hans Hagen via
ntg-context:
>> Hans, is it possible that LMTX uses some technique that is “too modern”
>> for some built-in PDF interpreter?
> we basically use the old pre 1.6 embedding, same as luatex
I saw that the new code renumbers
On 10/5/2022 6:02 PM, Pablo Rodriguez via ntg-context wrote:
It happens both with LuaMetaTeX and LuaTeX. When playing with certain
levels of zooming, some blank spots are displayed inside the characters
(printing is fine).
Such artifacts can result from operating in the extremes and one has
\stopTEXpage
\stoptext
It happens both with LuaMetaTeX and LuaTeX. When playing with certain
levels of zooming, some blank spots are displayed inside the characters
(printing is fine).
BTW, as Hans explained
(https://mailman.ntg.nl/pipermail/ntg-context/2022/106840.html), the
following top line avo
thoroughly since I
assumed I couldn’t help anyway.
Hans, is it possible that LMTX uses some technique that is “too modern”
for some built-in PDF interpreter?
we basically use the old pre 1.6 embedding, same as luatex ... mayeb
some other object is too modern (maybe some indirect reference is not
seen
ted out,
but nothing else does.
Another data point: Brother B205 doesn't print it either.
But would all of these use the same licensed PDF renderer...
The PDFs render fine on every PDF reader I could find.
Same here.
PDFs generated directly from Context MKIV from TeXLive 2022 using
Lu
me grids on my document, which gets printed out,
>> but nothing else does.
Another data point: Brother B205 doesn't print it either.
But would all of these use the same licensed PDF renderer...
>>> The PDFs render fine on every PDF reader I could find.
>> Same he
ld find.
Same here.
PDFs generated directly from Context MKIV from TeXLive 2022 using
LuaTeX 1.5 render fine on these printers.
I've also printed PDFs from pdfTeX in the past fine.
Same here.
Any ideas what I should try to help debug this?
I was told that this is the default now, that i
IV from TeXLive 2022 using
LuaTeX 1.5 render fine on these printers.
I've also printed PDFs from pdfTeX in the past fine.
Same here.
Any ideas what I should try to help debug this?
I was told that this is the default now, that isn't going to change, and
that I could always use LuaTeX instead. I
y page.
>> The PDFs render fine on every PDF reader I could find.
>> Conversion to PostScript with pstopdf (poppler-22.07.0) and then
>> sending the PS renders the document correctly on the printer.
>> PDFs generated directly from Context MKIV from TeXLive 2022 using
&g
ing the PS renders the document correctly on the printer.
PDFs generated directly from Context MKIV from TeXLive 2022 using
LuaTeX 1.5 render fine on these printers.
I've also printed PDFs from pdfTeX in the past fine.
I attached the non-working 'foo.pdf.mkix'
and the working 'foo.pdf.mkiv' file
generated directly from Context MKIV from TeXLive 2022 using
LuaTeX 1.5 render fine on these printers.
I've also printed PDFs from pdfTeX in the past fine.
I attached the non-working 'foo.pdf.mkix'
and the working 'foo.pdf.mkiv' file.
I tried to disable font subsetting to debug this further, but
tribution,) sometimes, for some people or for some of
> their files.
Hi Ángel,
there is nothing that prevents this to be fixed (as far as I know).
TeXLive is still using LuaTeX as default for ConTeXt. This will be
hopefully changed in next release of TeX Live (according to
https://mailman.ntg.
On Wed, Sep 28, 2022 at 03:59:07PM +0200, Hans Hagen via ntg-context wrote:
changed to have 'context file.txt' to compile using luatex instead of
LuaMetaTeX?
top line:
% engine=luatex
Thank you, I'll add that to my source files from now on.
but lmtx is and will stay as default
To bad
On 9/28/2022 5:10 PM, Pablo Rodriguez via ntg-context wrote:
Well, that is probably too much to say (I mean, that "--luatex"
generates more accurate PDF documents).
depends on how one defines accurate
The main issue would be pretending to use with LuaTeX some features
avai
oblem. Thank you!
Glad to read it helped, Ángel.
I had the suspicion, because font embedding seems to be changed in LMTX.
There have been minor issues in the past with this (I cannot recall
whether I experienced one or two myself).
> If compiling with --luatex option seem to have more chan
On 9/28/2022 3:30 PM, Angel M Alganza via ntg-context wrote:
On Tue, Sep 27, 2022 at 04:03:06PM +0200, Pablo Rodriguez via
ntg-context wrote:
In that case, run "context --luatex --generate" first and then "context
--luatex a6lua.tex".
This would give you a pure LuaTeX-c
On Tue, Sep 27, 2022 at 04:03:06PM +0200, Pablo Rodriguez via ntg-context wrote:
In that case, run "context --luatex --generate" first and then "context
--luatex a6lua.tex".
This would give you a pure LuaTeX-compiled PDF document.
I think that this PDF document will be fi
On Tue, Sep 27, 2022 at 04:03:06PM +0200, Pablo Rodriguez via ntg-context wrote:
Producer: LuaMetaTeX-2.09
No, this was compiled with LuaMetaTeX.
It looks so obvious now, but it didn't (to me) before. :-)
In that case, run "context --luatex --generate" first and the
installing from the garden (or from a git clone) will also be supported
(basically anyone can host a lmtx install).
For the next texlive we hope to switch to lmtx as default and that also
means that luametatex is the runner then. One can (as currently in lmtx)
always run luatex with "--l
On 9/26/22 20:26, Angel M Alganza via ntg-context wrote:
> On Mon, Sep 26, 2022 at 07:10:40PM +0200, Pablo Rodriguez via ntg-context
> wrote:
> [...]
>> There might be a workaround (or a way of testing this), compiling the
>> PDF document with LuaTeX instead of with Lua
3 0
VGDDRM+LMRoman12-Regular CID Type 0C Identity-H yes yes
yes 9 0
BBBAHN+LMMono8-Regular CID Type 0C Identity-H yes yes
yes 10 0
There might be a workaround (or a way of testing this), compiling the
PDF document with LuaTeX
f your PDF document?
I think that your printer is having issues with the embedded font in
your PDF document.
There might be a workaround (or a way of testing this), compiling the
PDF document with LuaTeX instead of with LuaMetaTeX.
If you compile it invoking "context source.tex", use &quo
ocuments, in this case one can think of embedding a
small luatex (no harms, after all mupdf it's already a big binary) and add
(pdf)objects by scripting.
--
luigi
___
If your question is of interest to others as we
\stoptikzcd
\stoptext
This builds fine on MkIV from TeXLive 2022 with LuaTeX, but on LMTX I get:
system > ConTeXt ver: 2022.09.11 20:44 LMTX fmt: 2022.9.20 int:
english/english
...
close source> level 2, order 63, name 'tikzlibrarycd.code.tex'
fonts > preloading lat
with LuaTeX, but on LMTX I get:
system > ConTeXt ver: 2022.09.11 20:44 LMTX fmt: 2022.9.20 int:
english/english
...
close source> level 2, order 63, name 'tikzlibrarycd.code.tex'
fonts > preloading latin modern fonts (second stage)
fonts > 'fallback moder
able
to find the font.
There seems to be an issue with the typescript file type-imp-lato.mkiv.
MWE:
\setupbodyfont[lato,12pt]
\starttext
Hello World!
\stoptext
---
ConTeXt ver: 2022.09.11 20:44 MKIV - luatex version: 1.1501, functionality
level: 7539:
mtxrun --script fonts --list --all --pattern
xmf-linux-64/bin
>resolvers | formats | format path :
> /home/max/luametatex-cache/context/5fe67e0bfe781ce0dde776fb1556f32e/formats/luametatex
>resolvers | formats | luatex engine: luametatex
>resolvers | formats | lua startup file :
> /opt/contex
:
/opt/context/tex/texmf-linux-64/bin
resolvers | formats | format path :
/home/max/luametatex-cache/context/5fe67e0bfe781ce0dde776fb1556f32e/formats/luametatex
resolvers | formats | luatex engine: luametatex
resolvers | formats | lua startup file :
/opt/cont
though; it's not something that I personally
need, although I see how it could be potentially valuable for others.
At some point binaries won't change much. After all, we don't package
the luatex binaries either and they also can relate to versions of tex
code (in the early days of luatex dev
;
>
> which on my machine gives
>
> system | resolved | file :
> c:/data/develop/tex-context/tex/texmf-local/web2c/texmfcnf.lua
> system | resolved | file :
> c:/data/develop/tex-context/tex/texmf/web2c/texmfcnf.lua
>
> indicating that i use an additional configuration fil
ary conditions:
- we use mtxrun as runner and that one used luatex as lua engine
- this means that mtxrun[.lua] has to be in the same path as the binary
in lmtx we even go a bit further:
- in lmtx there is mtxrun.lua
- as well as context.lua
- there are 'mtxrun' and 'context' binaries that are either cop
l LMTX for a system-wide use in some commonly
> accessible location. This is totally portable: only the PATH needs to be
> set to find the correct context executable.
>
> LMTX does not go the route of system packages as this relies on package
> maintainers. ConTeXt mkiv with luatex conti
Hi Hans,
> > First, how do I get an insert's class/type from the "insert" nodes on
> > the page? With LuaTeX, the insert's class/type is the same as the
> > subtype of the "ins" nodes, but the subtype of the "insert" nodes is
> > always ze
does not go the route of system packages as this relies on package
maintainers. ConTeXt mkiv with luatex continues to be made available and
updated with TeXlive, so any system packages that provide TeXlive can
provide ConTeXt.
Alan
On 15/08/2022 07:54, amano.kenji via ntg-context wrote
On 8/15/2022 8:18 AM, Max Chernoff via ntg-context wrote:
Hi all,
I'm trying to manipulate some inserts from Lua in LuaMetaTeX, and I'm
having some problems that I'm not having with LuaTeX.
First, how do I get an insert's class/type from the "insert" nodes on
the page? W
Hi all,
I'm trying to manipulate some inserts from Lua in LuaMetaTeX, and I'm
having some problems that I'm not having with LuaTeX.
First, how do I get an insert's class/type from the "insert" nodes on
the page? With LuaTeX, the insert's class/type is the same as the
subtype of the &
pfr.stretchorder = 0
> pfr.stretch = 0
>
Ah, that's quite convenient. I'm still supporting LuaTeX, so
unfortunately I'm somewhat limited with which helpers I can take
advantage of.
> as well as use
>
> tex.show(broken)
>
> to see the result
That w
On 7/25/22 20:19, luigi scarso via ntg-context wrote:
> On Mon, Jul 25, 2022 at 7:52 PM Pablo Rodriguez via ntg-context
> wrote:
>
> Sadly, as already reported, LuaTeX doesn’t work on Linux anymore.
>
> hm.... at least luatex on x86-64 is still ok, as far as I know.
L
optext
I would expect that pages 1 and 3 would be identical, and that pages 2
and 4 would be identical. However, page 4 is the same as pages 1 and 3,
which isn't what I'd expect. I can do a similar idea in LuaTeX/MkIV and
get the expected results, so I'm not too sure what I'm doing wrong here.
I'm probably ju
wever, page 4 is the same as pages 1 and 3,
which isn't what I'd expect. I can do a similar idea in LuaTeX/MkIV and
get the expected results, so I'm not too sure what I'm doing wrong here.
I'm probably just missing something ob
On Mon, Jul 25, 2022 at 7:52 PM Pablo Rodriguez via ntg-context <
ntg-context@ntg.nl> wrote:
>
> Sadly, as already reported, LuaTeX doesn’t work on Linux anymore.
>
>
hm.... at least luatex on x86-64 is still ok, as far as
iscussion here.
I would like to compare the LMTX output with the one from LuaTeX.
Sadly, as already reported, LuaTeX doesn’t work on Linux anymore.
> https://bugzilla.mozilla.org/show_bug.cgi?id=1781022
From the two questions from Jonathan Kew, HTML with TeX Gyre Heros is
displayed fine.
hould not run/mix lmtx with texlive
- we use luametatex as runner for both luametatex and luatex runs
- mtxrun.lua and context.lua are both in the bin path (as usual)
- mtxrun.exe and context.exe are symlinks to luametatex.exe
that is the same for all platforms but in tex live on windows there is
eporting the issue when I tried to typeset the example file with LMTX
>> (version 2022.07.06 21:42).
>
> I have no problems with the examples at the end of the module and LMTX, only
> when I use LuaTeX a error appears.
>
>> As a matter of fact I am far from underst
with LMTX (version
2022.07.06 21:42).
I have no problems with the examples at the end of the module and LMTX,
only when I use LuaTeX a error appears.
As a matter of fact I am far from understanding what the « arguments = { « hash
» } » is supposed to do in interfaces.implement in the code you sent
I just updated my ConTeXt to
system > ConTeXt ver: 2022.07.06 21:42 LMTX fmt: 2022.7.12
int: english/english
yesterday and got a error message in using tex.linebreak(head) as follow:
luatex warning > linebreak: no [ leftinit | rightinit | leftfill |
rigthfill] expected
I c
I just updated my ConTeXt to
system > ConTeXt ver: 2022.07.06 21:42 LMTX fmt: 2022.7.12
int: english/english
yesterday and got a error message in using tex.linebreak(head) as follow:
luatex warning > linebreak: no [ leftinit | rightinit | leftfill |
rigthfill] expected
I c
MTX fmt: 2022.7.12 int:
english/english
yesterday and got a error message in using tex.linebreak(head) as follow:
luatex warning > linebreak: no [ leftinit | rightinit | leftfill |
rigthfill] expected
I can't get any information about them. The head and the list going to
tex.linebreak(
could benefit from, and we do. One distinction
between luatex and luametatex is that we delegate some more to lua.
The reworked math engine is something that is probably very contextisch
if only because other macro packages are locked into "chisseled in stone
ams (and alike) math as the
if LuaTeX is better than
pdfTeX/XeTeX, and some are complaining that LuaLaTeX is too slow, of
course...)
HR
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context
ub.com/gucci-on-fleek/lua-widow-control/blob/master/source/lua-widow-control.lua;.
It's pretty long though, so I'm just trying to summarize here.)
This works pretty well with Plain LuaTeX, LuaLaTeX, OpTeX, MkIV, and
MkXL before the latest upload, but something broke with the latest
upload in MkXL. I
lua-widow-control.lua;.
It's pretty long though, so I'm just trying to summarize here.)
This works pretty well with Plain LuaTeX, LuaLaTeX, OpTeX, MkIV, and
MkXL before the latest upload, but something broke with the latest
upload in MkXL. I understand that I'm mucking around with volatile
est")
\stopluacode
\starttext
Hello!
\stoptext
with the latest upload I get (also note the small typo in "rigthfill"):
luatex warning > linebreak: no [ leftinit | rightinit | leftfill |
rigthfill] expected
2353 : par vmodepar>
userda
text
with the latest upload I get (also note the small typo in "rigthfill"):
luatex warning > linebreak: no [ leftinit | rightinit | leftfill |
rigthfill] expected
2353 : par vmodepar> userdatanil
nil
!!! info is nil !!!
d t :help "Run context (MarkIV)")
("luametatex"
"context --purgeall %t"
TeX-run-command t :help "Run context (LMTX)")
) TeX-command-list
)
)
)
--
Assuming that the runner (mtxrun or context) is an alias to luametatex,
y
ge line 81 of
texmf-context/scripts/context/lua/mtx-cache.lua
from
if find(filename,"luatex%-cache") then
to
if find(filename,"luametatex%-cache") then
the problem appears to be fixed.
maybe can you test with
LUATEXENGINE .. "
.lua
from
if find(filename,"luatex%-cache") then
to
if find(filename,"luametatex%-cache") then
the problem appears to be fixed.
-- Max
___
If your question is of interest
On 6/24/2022 8:28 AM, Max Chernoff wrote:
2. The LuaMetaTeX manual says that "pre_linebreak_filter" is called
_after_ the parfillskip glue has been added, but this doesn't seem
to be the case. With LuaLaTeX/Plain LuaTeX/MkIV, this is true, but
the node l
is mostly copied from an earlier email, "Callbacks (and
nodes) in LuaMetaTeX")
1. In LMTX, calling "tex.linebreak" produces a
luatex warning > tex: left parfill skip is gone
warning. I don't get this warning in Plain LuaTeX, LuaLaTeX, or
MkIV, so I t
haracters. Therefore lpeg.R('aä') results in the message bad
argument #1
to 'R' (range must have two characters), since to lpeg, ä is two ’characters’
(bytes), so
aä totals three. (https://texdoc.org/serve/luatex/0##680)
The easiest way that I found was to just cheat and use everything with
a T
gt; 'widg_editBezier.py', lower: 'widg_editbezier.py', already:
> 'Widg_editBezier.py'
> resolvers | expansions | 126789 files found on 6128 directories
> with 72213 uppercase remappings
> resolvers | resolving |
> resolvers
be greatly appreciated. I've updated my
ConTeXt installation to the latest version (mkxl 2022.05.11 11:36), but
this doesn't seem to have changed anything.
Further to the previous email, I have one (semi-related) additional
question:
6. The LuaTeX manual says that the subtype of "ins&q
, hash
'5058f1af8388633f609cadb75a75dc9d'
resolvers | caches | hashing tree
'selfautodir:/share/texmf-dist/web2c/texmfcnf.lua', hash
'0399a8df3aef8d154781d0a9c2b8e28d'
resolvers | caching | preparing 'files' for '.'
resolvers | caching | category 'files', cachena
break" produces a
luatex warning > tex: left parfill skip is gone
warning. I don't get this warning in Plain LuaTeX, LuaLaTeX, or MkIV,
so I think that it's specific to LuaMetaTeX. The LuaMetaTeX manual
hardly mentions "left parfill skip"/"parfillleftskip",
> lua error on line 112 in file de/c_intro.tex:
callback error:
...local/tex/luatex/lua-widow-control/lua-widow-control.lua:510:
attempt to perform arithmetic on a nil value (field 'height')
stack traceback:
...local/tex/luatex/lua-widow-control/lua-widow-control.lua:510:
in funct
n file de/c_intro.tex:
callback error:
...local/tex/luatex/lua-widow-control/lua-widow-control.lua:510: attempt
to perform arithmetic on a nil value (field 'height')
stack traceback:
...local/tex/luatex/lua-widow-control/lua-widow-control.lua:510: in
function <...local/tex/luatex/lua-widow-contr
intro.tex:
callback error:
...local/tex/luatex/lua-widow-control/lua-widow-control.lua:510: attempt
to perform arithmetic on a nil value (field 'height')
stack traceback:
...local/tex/luatex/lua-widow-control/lua-widow-control.lua:510: in
function <...local/tex/luatex/lua-widow-contr
'
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 >
pen 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 > l
. 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.
I can see "modules > 'lua-widow-control' is loaded".
But, luckil
Hi:
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 g
corresponding folder. That's what
I was missing, and, logically, what made my compilation crash.
Yeah, it's a pretty easy mistake to make. For Knuth TeX, shared files go
in texmf/tex/generic and Plain-specific files go in texmf/tex/plain, but
with LuaTeX there's just texmf/tex/luatex so it gets
lua yields what you
would expect:
/opt/luametatex/texmf-modules/tex/luatex/lua-widow-control/lua-widow-control.lua
Thanks again for your work and yours observations.
Edu.
El 25/4/22 a las 22:00, Max Chernoff escribió:
(Please keep me CC'd as I'm not subscribed to the list)
Hi, I'm the
a-widow-control file is empty.
The \setuplwc command ends on line 74, which then triggers
\everysetuplwc which then calls \ctxlua{lwc.enable_callbacks()}. This
fails since lwc is undefined because the Lua file isn't loaded because
ConTeXt can't seem to find the file.
In Plain LuaTeX and LuaLaTeX
to the parameter
FractionNumeratorDisplayStyleShiftUp in lm.lfg. If you always set it
to 600, it seems to work also for luatex. (This will be fixed.)
Another thing: Instead of using \over, I suggest that you use \frac
(less surprises). Something like:
\starttext
\startformula
a=b + 1
\stopformula
g. If you always set it
> to 600, it seems to work also for luatex. (This will be fixed.)
>
> Another thing: Instead of using \over, I suggest that you use \frac
> (less surprises). Something like:
>
> \starttext
> \startformula
> a=b + 1
> \stopformula
>
>
standalone installation and
> >do a fresh install
>
> I don’t think it would work, since it only works with LuaMetaTeX.
>
> I got the same results (in Windows [because I cannot make it work in
> Linux]) with LuaTeX 1.15 (the one that comes with ConTeXt LMTX).
>
n Windows [because I cannot make it work in
Linux]) with LuaTeX 1.15 (the one that comes with ConTeXt LMTX).
My suggestion would be a fresh install (in a different directory, no
need to remove anything) of ConTeXt LMTX.
> - What else i would have to check and probably fix to make the math
==
LuaTeX 1.15.0 2021-12-31
==
New primitive \matheqdirmode.
By default the short skip detection is not adapted to r2l typesetting and
that
hasn't been the case since the start
On 4/2/22 09:40, Hans Hagen via ntg-context wrote:
> [..]
> and how about
>
> context --luatex --generate
Many thanks for your reply, Hans.
I’m afraid it doesn’t work. It still generates data under
$HOME/.texlive2021/, but it tries to read data (to generate the format
file) from
20:37:30
An: Hans Hagen via ntg-context
Cc: Pablo Rodriguez
Betreff: Re: [NTG-context] mkiv
On 4/1/22 18:20, Hans Hagen via ntg-context wrote:
[...]
So, today is the day we kind of formally freeze MKIV.
Just a comment on MkIV.
I don’t remember exactly, but I’m afraid that "context --l
Betreff: Re: [NTG-context] mkiv
On 4/1/22 18:20, Hans Hagen via ntg-context wrote:
> [...]
> So, today is the day we kind of formally freeze MKIV.
Just a comment on MkIV.
I don’t remember exactly, but I’m afraid that "context --luatex
document" hasn’t been working on my computers
On 4/1/22 18:20, Hans Hagen via ntg-context wrote:
> [...]
> So, today is the day we kind of formally freeze MKIV.
Just a comment on MkIV.
I don’t remember exactly, but I’m afraid that "context --luatex
document" hasn’t been working on my computers (either running Linux or
Win
sample works in the same way for both MKIV and LMTX:
zint-test.tex
---
\usemodule[zint]
\starttext
\barcode[alternative=isbnx, text=9783865419026, width=4cm]
\stoptext
---
context zint-test.tex
context --luatex zint-test.tex
Adam
On Wed, Mar 16, 2022 at 9:39 PM Pablo Rodriguez via ntg-context &l
es the file
> (with object=no).
> >
> > At the next \startgraphviz .. \stopgraphviz, the same process is repeated.
> The `\jobname-temp-graphviz.pdf` file is overwritten and the new file should
> have been included. But it is not. The output contains the first image twi
should have
been included. But it is not. The output contains the first image twice.
I thought that object=no should have prevented the reuse. In fact, if I compile
the file with luatex, I get an error message:
! error: (pdf inclusion): file has changed '12-two-outputs-temp-graphviz.pdf'
mtx
.
I thought that object=no should have prevented the reuse. In fact, if I compile
the file with luatex, I get an error message:
! error: (pdf inclusion): file has changed '12-two-outputs-temp-graphviz.pdf'
mtx-context | fatal error: return code: 256
Any idea why object=no is not working
AUTHOR
TITLE
http://ns.adobe.com/pdfx/1.3/; rdf:about="">
out | 2022-02-02T21:34:48+01:00
out
2022-02-02 21:34
www.pragma-ade.com
c
is definitely the correct approach.
That's what the rest of the TeX world already does (at least LuaTeX
and XeTeX; pdfTeX not of course), see
https://github.com/hyphenation/tex-hyphen/blob/master/hyph-utf8/tex/generic/hyph-utf8/loadhyph/loadhyph-sr-latn.tex
We have two sets of Cyrillic
201 - 300 of 10536 matches
Mail list logo
