Hi David,
> ....
While log compatibility clearly isn't a top priority for you,
I would ask you again if you could consider this.
luatex is getting increasing use with latex but it is very hard to
support those users
if we can not somehow arrange the regression tests to give reliable
information about what does and does not work.
well, cleaning up (error) messaging will lead to small changes (in
spacing for instance) so you probably have to adapt a bit again later
It has already shown up several problems in luatex, and in our macro
level support for luatex, but currently the test failures are swamped
by this font logging difference.
it would be limiting if we would make 'comparing different engines to
behave the same using the log' one of the boundary conditions for
developments; of course we aim at compatibility when no callbacks are
used but logging is an exception (we might for instance run into cases
where info is simply not available or more info is available due to a
different implementation); also, we're not yet completely done with
providing hooks into each log message (i once played with an overload
that output very structured xml in context but i kicked out that code
because we still need to do some more work)
(btw, for years i have been working on the luatex variant of context and
i explicitly don't pose limitations on the development of luatex by
context compatibility demands .. which also means that i have to keep
adapting code while we further develop luatex; imo, if someone really
wants detailed compatibility, one should stick to pdftex or xetex; in
fact, i expect that it will take many years before the context version
of luatex will be stable and even then it's a somewhat different engine
than pdftex or xetex)
We are not asking that luatex produce the same output as pdftex or
that it always produce the same log, even if the visible output is the
same, but just, where possible, and in particular on input that is
valid with both engines, it is massively helpful if the logs differ in
predictable ways that can be normalised during diff.
sure, but fonts is one of these areas where the engines can differ
anyway, when I run this with context
\starttext
\font\a=cmr10
\font\b=cmr10
\setbox0\hbox{\a x\b y}
\scrollmode
\tracingonline1
\showbox0
\stoptext
i get
> \box0=
\hbox(4.30554+1.94444)x10.5556, direction TLT
.\b x
.\b y
and when i run this with (my version of) plain for luatex
\font\a=cmr10
\font\b=cmr10
\setbox0\hbox{\a x\b y}
\scrollmode
\tracingonline1
\showbox0
\bye
i get
> \box0=
\hbox(4.30554+1.94444)x10.5556, direction TLT
.\b x
.\b y
! OK.
l.7 \showbox0
but as said, because in luatex font loading is not something fixed and
can be driven by the "define_font" callback and/or the "font.define"
function and it's hard to say what you get without knowing in what way
these are used (a macro package can even redefine \font and mess with
the following \cs) ... do you test with the built-in fontloader or do
you use a lua variant?
(in principle you can redefine \font to store the \cs and the callback
to register names and that way make variants)
Hans
-----------------------------------------------------------------
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
| www.pragma-pod.nl
-----------------------------------------------------------------
