--includestyles fix for latexmlc and 1011.5551 fixes #873
Conversation
Another observation related to Fatals, on example I think we can seriously consider turning the |
Thinking out loud... I've been wondering what would happen if we processed latex.ltx. How slow? Errors? At least at the end all expected macros would be defined :> |
Oh wow. That should be rather turbulent. But would be pretty darn awesome if we could claim we have all of LaTeX's internals actually loaded. Would worry about coverage/errors more than speed for the moment, I think we have more high level solutions for performance now. |
b1cf693
into
brucemiller:master
Sorry... it's about time... |
I was investigating a Fatal conversion job from the cortex report over arXiv for a change, which happened to be a very impressive 85 manuscript:
https://arxiv.org/abs/1011.5551
They use a custom documentclass, and rather advanced latex, so we're far from "no problem" land, but can find interesting low-level fixes:
I wanted to quickly check if running with
--includestyles
helps, and noticed that a) latexmlc does not enable the behavior when given the option, and b) the option doesn't propagate toLoadClass
in general.Since enabling includestyles didn't really help (the loading got stuck in an infinite loop!), I next tried gradually improving coverage to avoid the Fatal error in the regular conversion pass from cortex, which is:
It is related to a curious issue with using
\sfcode
.=1000` I think (at least that is the first obvious error), so I started adding small patches along the way. I haven't yet escaped the Fatal, so this PR may stay open for a little.