On 8/8/2025 9:21 PM, user691586 via ntg-context wrote:
I meant of course "natively active in Plain TeX". I was referring to the
format, and applies to the pdftex, xetex, luatex engines too.
it is unrelated to engines: any can define any character active
what luametatex adds is mor
matters, and I was
aiming at re-using code as is in context.
in what sense natively .. all characters can be active and i bet that in
plain (and maybe also latex) the quite (') is active in math
in context | is actuallly active
side note:
- in mkii (pdftex,xetex) we use what we call
I meant of course "natively active in Plain TeX". I was referring to the
format, and applies to the pdftex, xetex, luatex engines too.
___
If your question is of interest to others as well, please add an en
or claim that it was
unintended usage. But I admit that one should say that beforehand, not
when a user runs out of luck. Normally we try to solve it, avoid loose
ends. Try to predict extreme usage patterns (comes with age I guess).
Hans
ps. Sorry, too long and too many typos (working on large
hared partials, 0
> partial entries
> mkxl run stats > used platform: win64, type: windows, binary subtree: bin
> mkxl run stats > used engine: luametatex version: 2.11.07, functionality
> level: 20250609, format id: 720, compiler: gcc
> mkxl run stats > tex properties:
ntries
> mkxl run stats > used platform: win64, type: windows, binary subtree: bin
> mkxl run stats > used engine: luametatex version: 2.11.07, functionality
> level: 20250609, format id: 720, compiler: gcc
> mkxl run stats > tex properties: 93
On 6/14/25 16:03, Wolfgang Schuster wrote:
> [...]
> pstricks uses postscript which isn't supported with pdftex, luatex etc.
Just as a general comment, Taco developed Escrito
(https://escrito.luatex.org/) in order to have pstricks in LuaTeX
(https://escrito.luatex.org/bt10/escritotalk
ample from
> >
> https://mailman.ntg.nl/archives/list/ntg-context@ntg.nl/message/RJR7MRTPR7S35OH4KWAWIOAMY3CRF5UB/
> ).
>
> pstricks uses postscript which isn't supported with pdftex, luatex etc.
>
> > edmac is almost three decades old. If you want
> >
> http
taTeX.
I couldn’t make it work with LuaTeX either (sample from
https://mailman.ntg.nl/archives/list/ntg-context@ntg.nl/message/RJR7MRTPR7S35OH4KWAWIOAMY3CRF5UB/).
pstricks uses postscript which isn't supported with pdftex, luatex etc.
edmac is almost three decades old. If you
Hi Hans,
On Sat, 2025-06-14 at 11:45 +0200, Hans Hagen wrote:
> > in this past week. Even the perpetually-stable pdfTeX had a few bugs
> > earlier this year.
>
> oh ... i thought that pdftex was very stable and admit that i never
> check mkii with that (i just assume that wh
while latex is guaranteed stable due to
regression testing but i didn't keep up with the latest perceptions)
in this past week. Even the perpetually-stable pdfTeX had a few bugs
earlier this year.
oh ... i thought that pdftex was very stable and admit that i never
check mkii with that (i j
expected output, so the TL version
should never be *completely* broken. And it's pretty common for new
LaTeX releases to break lots of documents; people have posted tons of
duplicates of this question
https://tex.stackexchange.com/q/735500
in this past week. Even the perpetually-stable
e is an old perl script `pdftrimwhite` which will do the calculations for
you.
mtxrun --script pdftrimwhite
I hadn't used it for a while and I tried it and it fails because it is still
calling context using texexec:
sub RunTeX
{ if ($UsePlain)
{ $result = `pdftex -prog=pdftex -fmt=p
https://tex.stackexchange.com/questions/724568/how-to-invoke-italic-correction-in-context-lmtx
Here is what I observed:
Compare the kerning produced in between 'r' and 'p' in the word "airport" when
italic correction is applied in plain TeX (compiled with `pdftex`) and in
ConT
https://tex.stackexchange.com/questions/724568/how-to-invoke-italic-correction-in-context-lmtx
Here is what I observed:
Compare the kerning produced in between 'r' and 'p' in the word "airport" when
italic correction is applied in plain TeX (compiled with `pdftex`) and in
ConT
On Tue, 6 Aug 2024, Shiv Shankar Dayal wrote:
> Hi,
>
> I do not remember where it came from, probably AMS Math or something like
> that.
It comes from plain:
❯ pdftex
This is pdfTeX, Version 3.141592653-2.6-1.40.26 (TeX Live 2024/Arch Linux)
(preloaded format=pdftex)
restric
output was handled by the PdfTeX engine
in MKII in 2005. What sort of output did the software produce before
PdfTeX was introduced? Was this the same as the output produced by the
software before the publication of the PDF specification?
2005 is when we started with luatex which is a follow up on
Hello,
I was reading about the history of ConTeXt in the Not So Short Introduction
To ConTeXt and I have a historical question. I noticed that the PDF
specification was published in 1993 yet ConTeXt was invented in 1991. The
book suggests that PDF output was handled by the PdfTeX engine in MKII
what you intend.
Since you have TeX Live, I recommend you get the ConTeXt in TeX Live working
first, then decide if you need the latest ConTeXt from the garden.
> On Feb 20, 2024, at 7:21 AM, Pablo Rodriguez via ntg-context
> wrote:
>
> The engine you are using is pdfTeX (from TeX Li
ption too).
Reading your log (which I simply ignored and Gavin took care to read it
[totally my fault]), the first line you get is:
This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023)
(preloaded format=pdflatex 2024.2.6) 19 FEB 2024 12:41
The engine you are using is pdfTeX (from TeX
tried to typeset your file, context-test.tex, your computer
attempted to use pdftex rather than ConTeXt. To figure out why it did that, we
need to know how you are doing the typesetting. Do you use a command on the
command line? Are use using an editor that has a “typeset” button? Something in
that
uitting
I wrote on Wednesday last week. I also did an download of cont- lmt and cont-
tmf. Don't know if there is a mistake which is my fault?
I don't know, maybe important:
The log file says:
This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023) (preloaded
format=pdflatex 2024.
Rephrasing the question, can
> > LuaMetaTeX/ConTeXt compile
> > plain TeX files. If yes, how can I do that?
>
> You mix up two different things here.
>
> 1. Plain TeX is a collection of TeX macros like ConTeXt or LaTeX.
>
> 2. LuaMetaTeX is a program like pdfTeX or LuaTe
LaTeX.
2. LuaMetaTeX is a program like pdfTeX or LuaTeX which provides commands
which are used by above mentioned collections to create macros.
Even though ConTeXt provides some commands which available in plain TeX
not all of the are supported which means you can't process plain TeX
docu
of assume that we're stuck with cpu performance but
nevertheless luametatex became faster. It helps to develop on an older
machine and not on a yearly updated one as that obscures matters. (Not
that I'd not like a faster machine, but that comes at a steep price.)
Hans
ps. In the tr
set any gain in engine.
One thing to keep in mind is that tex is an interpreter and all gets
tokenized which is more costly in a 32 bit engine than in an 8 bit one
(like pdftex). And although luametatex is more efficient than luatex
that gets offset by more features that come at a price, but we
ing is abit special in te xdue to the fact thet some numbers
en dup in registers and others as token list (string). I have considered
changing that but it would also break some 'testing for tex version' so
for now we have to accept this mix of
I know the code quite wel now and refactoring is for me
counter productive. These are projects running for decades and engines
need to be stable so changes come slow.
You can compare the luanmetatex source to luatex and pdftex to see how
we p
5 sec) but LMTX generates more pages so it is
> > faster.
>
> puzzling
>
> > Of course, this is a meaningless experiment from a practical point of view
> > as a 1000 page document will be more complex than just text.
> % engine=pdftex 1.2
> % engine=luatmetate
iment from a practical point of view as a
1000 page document will be more complex than just text.
% engine=pdftex 1.2
% engine=luatmetatex 1.6
% engine=luatex 1.8
% engine=xetex 2.4
\starttext
\dorecurse{500} {
\input knuth \par
}
\stoptext
125 pages, so how does your test
in almost an instant using PDFTeX which is about 450+
> pages but my math book takes around 30 seconds averaging ~40 pages/second.
>
> Why LuaMetaTeX is so slow? How can I speed it up?
> --
> Re
On 1/18/2024 7:56 PM, Shiv Shankar Dayal wrote:
In comparison to LaTeX with LuaHBTeX, ConTeXt with LuaMetaTeX is
lightning fast.
pdfTeX is 8bit, and Knuth’s plain TeX is very low level – for a fairer
comparison, try the TeXbook on LuaMetaTeX (I don’t know if “plain”
works
Hi,
On Thu, Jan 18, 2024 at 7:58 PM Shiv Shankar Dayal
wrote:
>
>
>
>
>> In comparison to LaTeX with LuaHBTeX, ConTeXt with LuaMetaTeX is
>> lightning fast.
>>
>> pdfTeX is 8bit, and Knuth’s plain TeX is very low level – for a fairer
>> comparison, try
In comparison to LaTeX with LuaHBTeX, ConTeXt with LuaMetaTeX is
> lightning fast.
>
> pdfTeX is 8bit, and Knuth’s plain TeX is very low level – for a fairer
> comparison, try the TeXbook on LuaMetaTeX (I don’t know if “plain” works
> though).
>
I understand that why it is slo
Am 18.01.24 um 18:47 schrieb Pablo Rodriguez via ntg-context:
On 1/18/24 18:24, Shiv Shankar Dayal wrote:
I can process TeXBook in almost an instant using PDFTeX which is about
450+ pages but my math book takes around 30 seconds averaging ~40
pages/second.
Hi Shiv Shankar Dayal,
I guess that
On 1/18/24 18:24, Shiv Shankar Dayal wrote:
> I can process TeXBook in almost an instant using PDFTeX which is about
> 450+ pages but my math book takes around 30 seconds averaging ~40
> pages/second.
Hi Shiv Shankar Dayal,
I guess that “The TeXbook” (having been written by Knuth himsel
I can process TeXBook in almost an instant using PDFTeX which is about 450+
pages but my math book takes around 30 seconds averaging ~40 pages/second.
Why LuaMetaTeX is so slow? How can I speed it up?
--
Respect,
Shiv Shankar Dayal
rn anything useful. Nor
>> does the okular example in the wiki (https://wiki.contextgarden.net/SyncTeX)
>> work for me. Ocular starts, but always on the first page, regardless of
>> what line number I give it.
>> On the other hand, pdftex creates a .synctex file which my
some information
in it,
but I can't find any invocation of synctex to return anything useful.
Nor
does the okular example in the wiki
(https://wiki.contextgarden.net/SyncTeX)
work for me. Ocular starts, but always on the first page, regardless of
what line number I give it.
On the other ha
ocation of synctex to return anything useful. Nor
does the okular example in the wiki (https://wiki.contextgarden.net/SyncTeX)
work for me. Ocular starts, but always on the first page, regardless of
what line number I give it.
On the other hand, pdftex creates a .synctex file which my copy of sy
eful. Nor
does the okular example in the wiki (https://wiki.contextgarden.net/SyncTeX)
work for me. Ocular starts, but always on the first page, regardless of
what line number I give it.
On the other hand, pdftex creates a .synctex file which my copy of synctex
find useful.
I am using the syncte
is by default in the distribution?
I'll check it but no time today.
btw ... as you like low level hacking ...
pdftex has a mechanism called pgc (pdf glyph containers) and these are
used when no pk font is found (which also means: no map entry)
\pdffont ... =
\pdfscale 1000
\pdfglyph 1 100
tfmdata,
{ code = spec },
codepoint
)
fonts.constructors.addcharacters(
font.current(),
{ characters = { [codepoint] = spec } }
)
end
I specifically need something that writes out a raw PDF stream. I'm
using this to write a 400
t; > $pdf_mode=1;
> I found back this link:
>
> https://davidcarlisle.github.io/latexcgi/testc
>
>
> % !TEX mtxrun --script context
>
> \starttext
>
> \dorecurse{500}{\samplefile{tufte}\par}
>
> \stoptext
>
> Runs 113 pages in 1.13 sec so
tufte}\par}
\stoptext
Runs 113 pages in 1.13 sec so quite ok for a remote un I guess.
I'm not sure how up to date it is.
(The default is some old tex document using pdftex.)
Hans
-
Hans
d plans at
meetings.
Also keep in mind that we're talking frontend here; omega is dvi based
so like regular tex and etex whatever it does with fonts is not really
related to the engine bu tup to the backend: the engine only needs
metrics (omega extended tfm into ofm for that).
pdftex brought
rbon footprint lasted more
on books than on shelves really, not for selling out fast but rather
discontinued quickly) and that its goal was solely within this input
processing spectrum. Because it wasn't.
Or heck
or heck. Let's go even further. By making the dubious assertion
that we'
processing
and th efont part was mostly going beyond 8 bit fonts but i might have
missed something (omega was never productin ready).
It is xetex that hooked into opentype although pdftex can actually deal
with truetype fonts to some extend. Before there was something
'opentype
trigonometric circle from the pgf manual,
quoted in https://wiki.contextgarden.net/TikZ , does not compile
unless you also comment out
or find(n,"pdftex")
in line 181 of the mtx-install-modules.lua file
before doing mtxrun --script install-modules --install tikz
but I could guess that from a
ric circle from the pgf manual,
> > quoted in https://wiki.contextgarden.net/TikZ , does not compile
> > unless you also comment out
> > or find(n,"pdftex")
> > in line 181 of the mtx-install-modules.lua file
> > before doing mtxrun --script install-modu
works.
> >> The more complex example with the trigonometric circle from the pgf
> >> manual,
> >> quoted in https://wiki.contextgarden.net/TikZ , does not compile
> >> unless you also comment out
> >> or find(n,"pdftex")
> >> in lin
://wiki.contextgarden.net/TikZ , does not compile
unless you also comment out
or find(n,"pdftex")
in line 181 of the mtx-install-modules.lua file
before doing mtxrun --script install-modules --install tikz
but I could guess that from a:
Driver file ``pgfsys-pdftex.def'' not found..
message
t; unless you also comment out
> or find(n,"pdftex")
> in line 181 of the mtx-install-modules.lua file
> before doing mtxrun --script install-modules --install tikz
> but I could guess that from a:
> Driver file ``pgfsys-pdftex.def'' not found..
> message
Ah so t
Thanks a lot Aditya.
The very simple TikZ example with the cross works.
The more complex example with the trigonometric circle from the pgf manual,
quoted in https://wiki.contextgarden.net/TikZ , does not compile
unless you also comment out
or find(n,"pdftex")
in line 181 of the m
gt;
> > mtxrun --script install-modules --install --all
> >
> > doing exactly that?
> >
>
> Okay Floris. I see Aditya nearby. He'll take over from now on :) stand
> by please. I know you didn't ask the original question but this is over
> t
rom now on :) stand
by please. I know you didn't ask the original question but this is over
the pgfsys-pdftex and the pgfsys-luatex. It's a race between them !!
sort of
The solutions are a few if any really, either as I suggested first and update
afterwards or install tikz
if the dri
g the macro \pgfsysdriver to an appropriate value
> before you load pgf.
> If you are going to use the dvips program, you set this macro to the value
> pgfsys-dvips.def;
> if you use pdftex or pdflatex, you set it to pgfsys-pdftex.def; and so on.
> In the following, details of the s
ned during the presentation, adding units to luametatex is not
really putting a (performance) burden on this engine. In pdftex and
luatex it would have an impact, although in luatex somewhat less because
we prioritize our favourite units anyway.)
nctional context
> > standalone
> >
> > Now let's take a peek instide and see the binaries
> >
> > afm2tfm etex kpsereadlink mfmtxrun.lua texluac
> > bibtex extractbb kpsestat mf-nowin pdfetex tlmgr
&g
ext.lua fmtutil-sys latex mkindex pdftex updmap
dvilualatex fmtutil-user luahbtex mktexfmt pktogf updmap-sys
dviluatexgftodvi lualatex mktexlsr pktype updmap-user
dvipdfm gftopkluametatex mktexmf rungs xdvi
kpsereadlink mfmtxrun.lua texluac
bibtex extractbb kpsestat mf-nowin pdfetex tlmgr
context fmtutil kpsewhichmft pdflatextlshell
context.lua fmtutil-sys latexmkindex pdftex updmap
dvilualatex fmtutil-user l
t; chatgpt would come up with it, it would do so by having parsed plenty of tex
> sources instead of inventing it (and when it comes to answering tex related
> questions chargpt is pretty unreliable, but that's another topic)
>
> > But instaed I looked at it and though to myself
) but I can still type
> \par
> $test$
> \end
and it'll produce a dvi file in return.
a lot has changed: opentype math, unicode, more demands but indeed there
is nothing against using plain tex with cmr and dvi fonts if that suits
well; and plain tex will always
ansi]
> >
> > \definefontsynonym[LucidaBrightDemiItalic][texnansi-lucidabrightdemiitalic][encoding=texnansi]
> >
> > \definefontsynonym[LucidaBrightItalic][texnansi-lucidabrightitalic][encoding=texnansi]
> >
> > \definefontsynonym[LucidaBrightRegular][
alic][encoding=texnansi]
\definefontsynonym[LucidaBrightItalic][texnansi-lucidabrightitalic][encoding=texnansi]
\definefontsynonym[LucidaBrightRegular][texnansi-lucidabrightregular][encoding=texnansi]
\stoptypescript
these encodings only make sense with mkii (in which case the ma
otf rather than going
through the ttf as it may be deprecated works. No doubt.
But look at the output of only a few lines.. This is exactly what I wanted to
see!:
system >6: filename=texnansi-bandh-lucida.map filetype=map
format=map
foundname=/usr/local/texlive/2023/texmf-local/font
ig, home:texmf,
!!selfautoparent:texmf-config, !!selfautoparent:texmf-var,
!!selfautoparent:texmf-project, !!selfautoparent:texmf-fonts,
!!selfautoparent:texmf-local,
!!selfautoparent:texmf-dist}/fonts/data//\{home:.texlive2023/texmf-config,
home:texmf, !!selfautoparent:texmf-config, !!selfautoparent
/internal/telecom/
itdemos/internal/travel/
pdftex/
pragma/
present/euronts/
present/road/
present/talks/
present/tug-2000/
specials/fonts/
texdemos/suite/
sent 204 bytes received 17,573 bytes 11,851.33 bytes/sec
total size is 449,010,176 speedup is 25,257.93
/internal/telecom/
itdemos/internal/travel/
pdftex/
pragma/
present/euronts/
present/road/
present/talks/
present/tug-2000/
specials/fonts/
texdemos/suite/
sent 196 bytes received 13,933 bytes 28,258.00 bytes/sec
total size is 449,010,176 speedup is 31,779.33
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 could also use LaTeX,
>>
>>> 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
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 in
et an empty 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 202
then
sending 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 worki
ter.
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.
I tried to disable font sub
gt; the mkii greek pattern file?
>
> Actually, we never had a greek hyphenation pattern file, only for
> ancient greek. Modern greek in mkii has not encoding defined (we're
> talking 2005 and before when Tomas made the greek encoding that dealt
> with utf in pdftex). It has to do w
ually, we never had a greek hyphenation pattern file, only for
ancient greek. Modern greek in mkii has not encoding defined (we're
talking 2005 and before when Tomas made the greek encoding that dealt
with utf in pdftex). It has to do with 'setting what are letters' and
these mod
ng 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-co
ns at once 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 s
Yes, loading both patterns at once 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
On 12/21/2021 10:50 AM, hanneder--- via ntg-context wrote:
I just started switching after long years of typesetting with
La-/Omega-/pdfTeX to Context and was exploring the capabilities of the
program for typesetting critical editions. So I was
wondering whether there is any updated
..@staff.uni-marburg.de
> Betreff: [NTG-context] Critical Editions?
>
>
> I just started switching after long years of typesetting with La-/Omega-
> /pdfTeX to Context and was exploring the capabilities of the program for
> typesetting critical editions. So I was wondering whether
I just started switching after long years of typesetting with
La-/Omega-/pdfTeX to Context and was exploring the capabilities of the
program for typesetting critical editions. So I was
wondering whether there is any updated information on how to produce
critical editions?
Details:
I was
boxwidth : the local box width
> \localboxoffset : the total distance to the edge
> \localboxleftskip : the effective leftskip
> \localboxrightskip : the effective rightskip
> \localboxlefthang : the current shape related value
> \localbo
most of these relate to normalized lines and as such there is plenty to
play with. Others can be seen in the examples.
I might add some more control to both these 'injection' mechanism
because directly out of the (pdftex/omega/luatex) they are not that
useful (which is probably also
/sbin:/Users/rjhb/doc/cvs/rjhb/perl5/bin:.:/Applications/Qt/current/clang_64/bin:/usr/X11/bin
dvipdfmx: /opt/local/bin/dvipdfmx
dvips: /opt/local/bin/dvips
fmtutil: /opt/local/bin/fmtutil
kpsewhich: /opt/local/bin/kpsewhich
luatex:/opt/local/bin/luatex
mktexpk
\skip0=10pt plus 10pt minus 10pt plus 20pt
test \skip0=10pt plus 10pt plus 20pt minus 10pt
test \vrule width 10pt height 10pt depth 10pt depth 10pt height 10pt
% test \hbox to 10pt to 10pt {x}
\stoptext
compare pdftex and luametatex.
ok. but why does this run fine
\starttext
Test
>>> values?
>> I think the only examples are in mails from Hans. When you set multiple plus
>> or minus values (as far as i remember) only the last setting is used and all
>> previous ones are ignored.
> Maybe in some article. Anyway, here is an example:
>
> \starttex
10pt
test \vrule width 10pt height 10pt depth 10pt depth 10pt height 10pt
% test \hbox to 10pt to 10pt {x}
\stoptext
compare pdftex and luametatex.
Hans
-
Hans Hagen | PRAGMA ADE
e are implemented and the way
TeX (the engine) works when it reads arguments.
and, also in mkiv \dofmode is unexpandable so cannot act as keyword
(it might not crash but also doesn't work)
Here is a short example which demonstrates the differences between
LuaTeX (eTeX, pdfTeX etc.) and
early in
\MKII\ we had a positioning mechanism available. At that time we had
\DVI\ output and specials were used to track positions. A script
calculated the positions that were then fed back into the second run.
Later Taco wrote \DVIPOS\ which sped up the analysis between runs. When
\PDFTEX
;home:Library/texmf" or
"home:texmf",
-- We need texmfos for a few rare files but as I have a few more
bin trees
-- a hack is needed. Maybe other users also have texmf-platform-new
trees.
TEXMF =
"{$TEXMFCONFIG,$TEXMFHOME,!!$TEX
implemented in pdftex and xetex.
Two TeX January 2021 DEK buglet fixes (H.Hagen)
Mark math glyphs as protected (in order to prevent processing
as text in base mode).
Removed width/ic compensation for traditional math code path.
When restricted system commands is enabled os.setenv has no effect
Hi,
The 2021 texlive code is currently being frozen. This means that Mojca
will check-in the current context release right before tl gets deep frozen.
The MKII code (mkii and mpii files) hasn't changed so it should still
work well with pdftex and xetex although I admit that I haven'
r.otf
usedmethod=database
system > 10: filename=latinmodern-math.otf filetype=opentypefonts
foundname=d:/Ctx-Beta/tex/texmf/fonts/opentype/public/lm-math/latinmodern-math.otf
fullname=d:/Ctx-Beta/tex/texmf/fonts/opentype/public/lm-math/latinmodern-math.otf
usedmethod=database
syste
: new method (more lmtx-ish)
(actually with mkii in pdftex we need .3 seconds, xetex freezes with
100K but needs 0.53 for 10K, luatex needs 0.18)
but I'm sure you don't care much about that so I just implements a
variant with warning which takes .19 seconds per 100K so it's a nic
and nilled some prefixes that we never used in
context anyway), some etex enhancements brought new primitives (some
make no sense in the luametex universe but one can always fake
something), some auxiliary pdftex primitives never were available in
lua(meta)tex because we have lua, and from omeg
l? Because it seems it's there.
depends on what you consider (non) hdpi ... the positioning of glyphs
depends on font scale, rounding of stems and such (hints in fonts but
these get less relevant with high res displays), caching, inter glyph
corrections (that pdftex/luatex/...) put in the
as well? Because it seems it's there.
>
> depends on what you consider (non) hdpi ... the positioning of glyphs
> depends on font scale, rounding of stems and such (hints in fonts but
> these get less relevant with high res displays), caching, inter glyph
> corrections (that pdft
1 - 100 of 4117 matches
Mail list logo
