Support for the .sty files already included in the directory

[sherlcok314159]

When using latexml to convert arXiv paper to HTML, it is common to face problems that something is undefined due to the miss of sty files. However, the author includes all the sty files just in the same directory.

Are there any method to preload sty files which are already included in the input directory? IMHO, latexml can be more flexible in this way and does not have to adapt to many sty files by hand.

[dginev]

@sherlcok314159 tthis is already available in LaTeXML as an experimental switch through latexml.sty.ltxml. It is used in both ar5iv and today's native arXiv HTML.

The feature can be activated with passing an option through the --preload command-line option. The used variant is essentially:

latexmlc --preload=[localrawstyles]latexml.sty ...

There are several variations:

• default: norawstyles and norawclasses.
  • That means.sty or .cls files are not loaded unless explicitly requeted by a .ltxml binding.
• localrawstyles - allow detecting and loading raw .sty files found in the local searchpaths available to LaTeXML (either via the source directory, or the --path additions).
• localrawclasses - same as localrawstyles, but targeting .cls files.
• rawstyles - same as localrawstyles but allows global search via kpsewhich, so also permits using a texlive installation
• rawclasses - same as localrawclasses but allows global search via kpsewhich, so also permits using a texlive installation

It is often the case in recent arXiv conversions with LaTeXML that some of the (many) subtle differences in implementation between LaTeXML and the native latex.ltx machinery leads to fragility in the internal expansion mechanics. Which can cascade into undefined macros, or at aworst even infinite loops. To that end there is an active project targeting loading the native latex.ltx in its entirety, and we are cataloging all cases where today's latexml hits issues to also improve the binding code. You are always welcome to report those in the arXiv/html_feedback or ar5iv repositories.

Source link:

LaTeXML/lib/LaTeXML/Package/latexml.sty.ltxml

Lines 60 to 66 in 40e9fa8

	# Finer control over which (if any) raw .sty/.cls files to include
	DeclareOption('rawstyles', sub { AssignValue('INCLUDE_STYLES' => 1, 'global'); });
	DeclareOption('localrawstyles', sub { AssignValue('INCLUDE_STYLES' => 'searchpaths', 'global'); });
	DeclareOption('norawstyles', sub { AssignValue('INCLUDE_STYLES' => 0, 'global'); });
	DeclareOption('rawclasses', sub { AssignValue('INCLUDE_CLASSES' => 1, 'global'); });
	DeclareOption('localrawclasses', sub { AssignValue('INCLUDE_CLASSES' => 'searchpaths', 'global'); });
	DeclareOption('norawclasses', sub { AssignValue('INCLUDE_CLASSES' => 0, 'global'); });

Edit: I see we've added these in 2020. I recall we followed the same reasoning that led you to opening this issues.

[sherlcok314159]

Thanks so much for the detailed explanation. Maybe you can add an external docker run argument for supporting local sty files if you have time. @bfirsh

[dginev]

I think the latest ar5ivist Dockerfile should already allow for modding these options, as it uses a base image. And a user ought to be able to override via calling with a different --preload from outside, as later option values can override earlier ones (at least in this specific case).

Code here:

https://github.com/dginev/ar5ivist/blob/main/ar5ivist/Dockerfile#L19

[sherlcok314159]

Thanks for your quick reply. But I am using engrafo. It will be much more convenient if engrafo also accepts preload argument or automatically scans the folder to add the external sty files. Can you help to do this?

[dginev]

@sherlcok314159 sorry, I am not a maintainer of engrafo. There is a natural continuation between the projects as you can read at the present day page of https://www.arxiv-vanity.com/

I suspect eventually arXiv may maintain their own official latexml Dockerfile. We have an open issue about doing this on the latexml side ( #1178 ), which is still pending some resolution.

For the moment I plan on maintaining ar5ivist, as long as ar5iv keeps getting actively updated.
So we should probably close this issue if there is nothing else to do on the latexml side of affairs.