Added bindings for the iTex commands that are used in the nLab Harvester

[typohnebild]

This includes the nlab.sty.ltxml, that includes the bindings for the iTex commands that weren't supported out of the box and the nlab.opt I used while harvesting. I also added some preloads to the mwsq profile so that the iTex commands can be used while search

[dginev]

Pretty neat bindings! I am particularly happy about the test, and Travis passing.

I was wondering if you'd prefer to use the latexml approach to testing TeX, (one example ) so that you also deposit the expected XML from the tex, and have the test suite immediately catch regressions in the markup.

It's a bit bigger of maintenance burden, but it also gives you more transparency on what is being tested.

In latexml, you can auto-generated the XML for a tex test via:

perl tool/maketests t/expansion/toks.tex

and that script should be callable into side-projects as well, it just runs latexml with the test-friendly parameters set. You'd need to change your itex_test file into a itex/formulas.tex or similarly named file, and have the test as (still named t/2_itexcommands.t):

use LaTeXML::Util::Test;

latexml_tests("t/itex");

[dginev]

Apart from that, happy to merge here, and let you test this in the real world.

[kohlhase]

I am also happy to see that there is progress on this. But I am not sure that the MWS plugin is the right final resting place. I have the feeling that there should maybe be a separate plugin for iTeX2MML. After all, iTeX2MML is a standalone library and there are MWS installations that do not need iTeX2MML (on the contrary, nlab is the only one). @dginev, how much work would it be to have a separate plugin? In fact, the iTeX plugin might be a good possibility for the LaTeXML distribution.

[dginev]

Oh, making a new standalone repository is simple, just copy the directory structure of this plugin, rename to the new name, and only keep the newly added files here. And update the makefile.

[kohlhase]

But do you agree that having a separate plugin is the right way to go?

[dginev]

It can certainly be a separate plugin if it is not a requirement for MWS, yes. Since plugins are somewhat fluid in scope, there is more flexibility, so I am happy either way.

[typohnebild]

I also think it is reasonable to have this in a separate Plugin hence I will try to create one and move all that stuff into it. Regarding the test I have two questions:

1. Is it possible to use a specific profile (like my nlab.opt) while auto generating the xml files?
2. How can I tell in the latexml_tests("t/itex"); call that it should use my profile?

[dginev]

By default the latexml_tests method does not use a profile, instead you need to provide a fully formed .tex source with all \usepackage options - and they only produce latexml's XML flavor in an .xml file of the same name.

But we also support more, if you instead write the test as a .spec file. For example 92_profiles.t looks like an ordinary test, but it finds and uses the .spec test specification. For instance fragment.spec just specifies using the fragment profile on a given source file.

You can still use the maketests utility, though it is missing a default check (just opened a PR triggered by this discussion https://github.com/brucemiller/LaTeXML/pull/1126 ). For now you can use:

perl tools/maketests --xml t/daemon/profiles/fragment.spec

[kohlhase]

I also think it is reasonable to have this in a separate Plugin hence I will try to create one and move all that stuff into it.

I think it should be in the MathWebSearch namespace and have the name LaTeXML-plugin-iTeX2MML. I will make such a repository and give you access.

[kohlhase]

I made the repository and gave you access. You should have gotten an e-mail. we should (eventually) close this merge request and build the plugin there.

[typohnebild]

Ok, I've pushed everything to the new repository