How to Contribute

Join the community

You might enjoy the low traffic LaTeXML mailing list for general discussions about LaTeXML.

Add to the Wiki

If you have helpful tips & tricks that other users could benefit from, consider adding content to the LaTeXML Wiki.

Open an Issue

If you encounter bugs, problems, missing features... consider opening an issue in the issue tracker.

General Guidelines for Issues

• Provide a minimum working example; typically a short TeX/LaTeX file that demonstrates the problem;
• describe what the problem is: what happened that you didn't expect or what didn't happen that you did expect.
• Mention what version of LaTeXML you're using (released version or the development version from github; in the latter case, please use git pull to update your local copy). It could also be helpful to name your Operating System.

Guidelines for Missing Package Issues

On the other hand, if the issue involves a missing package, it will be helpful if you try to process your file using the --includestyles option, to determine if the 'raw' TeX of the style or class file can be interpreted successfully.

If that doesn't work, then the minimum working example should perhaps be not so minimal. Since we're not familiar with all the LaTeX packages out there, having a sample that exercises the package greatly helps testing and developing a binding for the package.

If --includestyles does work, please open an issue and let us know, so that we do a test drive ourselves and add the package to the official list of LaTeXML-supported ones.

Submit code or Pull Requests

Now it gets fun! We'll assume that you've checked out the development version from github. In simple cases, like a typo, you can file an issue with the pointer to where in the code (file, line number) the change needs to be made. For anything non-trivial, however, opening a Pull Request is the best. Note that there are a few utilities in the tools subdirectory of LaTeXML that can be helpful.

If you are patching (or creating) a Perl file, it's nice to be consistently style & formatting (such as it is): use tools/latexmllint to check & reformat (you'll need the Perl::Critic module installed).

After developing your code/patches (and maybe even during the coding), run make test to verify that the changes haven't introduced any unexpected side effects. If a test case fails, say t/suite/case, you can use

tools/maketests --compare t/suite/case

to see the diffs between the (presumably) correct xml and your current output.

If you create a new binding, see the Bindings page for more information. You may want to create a new test case, say newtest.tex. Usually, I develop the binding & test file together, continually examining the xml output from latexml to see that it is as desired. Once it is, please add the tex file, to an appropriate subdirectory under t, say t/mypackage, and use

tools/maketests t/mypackage/newtest

to create the corresponding XML and PDF files.