Open kohlhase opened 6 years ago
Actually, this sounds a lot like the New Improved Strategy for writing bindings: Leverage the existing TeX implementation as much as possible (to the extent the TeX source is available w/o introducing unwanted dependencies).
The basic idea is to start the binding foo.sty.ltxml
with something like
InputDefinitions('foo',type=>'sty',noltxml=>1)
|| Warn('missing_file', 'foo.sty', undef, "Couldn't find foo.sty");
(or Error or whatever). Then you adapt by adding definitions according as LaTeXML either fails to understand the TeX, or fails to preserve the semantics. You can place the new definitions either before or after the InputDefinitions
. Placing definitions after is the simplest case when you just want to provide your own redefinitions of the style file's macros, but they aren't actually executed by loading the style file. For cases where the style file actually uses those macros, you'd place them before the InputDefinitions
, and add locked=>1
to those definitions, so that they style file doesn't redefine them.
Grep for InputDefinitions
in the distribution's Package directory to see a variety of examples of this approach; some requiring only minimal redefinitions, others massive.
I have actually started working on this on the simplify
branch. The change is rather minor at the moment, and I will hold off from larger work until the tests are starting to work and we are safer against regressions.
Currently the LaTeX implementation of sTeX has a lot of convenience macros that are purely abbreviative. The LaTeXML implementation redoes these natively (ie. with
DefConstructor
), and this creates a change management hassle (see e.g. #117). In particular, there is some (but not enough still)RawTeX
ing going on.I would rather do the implementation
xxs.sty.ltxml
forxxx.sty
the following way (if that is possible)xxx.sty
and interpret all the macros nativelyDefconstructor
those that need a special XML treatment.That would drastically improve coverage and change management almost immediately that the cost that some internal macros pollute the LaTeXML heap.
@brucemiller I would be very grateful for your insights on this. @tkw1536 you should only start really thinking about this when your thesis is submitted.