Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

--mathsvg for latexmlc, math whatsout #883

Merged
merged 3 commits into from Nov 15, 2017

Conversation

@dginev
Copy link
Collaborator

dginev commented Nov 14, 2017

My exact need was to run an equivalent of:

latexmlc --preload=article.cls --preamble='literal:\usepackage{bm}\begin{document}' --mathsvg 'literal:\(\bm{x}\)' --noparse --whatsout=math

And get back an SVG string literal.

This PR adds that - it is in fact a minor modification to the math whatsout, as the rest of the code was already active.

I also fixed a minor oversight where the format could be left unset (should be "xml").

One idea that came to mind is that if we want to get serious about mathsvg, we could also disable math parsing entirely when that is the only math output - from what I understand we use the TeX directly, so no need to spend time in MathParser when the mathml isn't requested back out. But that's for another day.

$serialized = $result->toString(1); }
elsif ($$opts{format} =~ /^html/) {
if (ref($result) =~ '^LaTeXML::(Post::)?Document$') { # Special for documents
if (ref($result) =~ /^LaTeXML::(Post::)?Document$/) { # Special for documents

This comment has been minimized.

Copy link
@dginev

dginev Nov 14, 2017

Author Collaborator

cosmetic change, the string literals were bugging me

@dginev

This comment has been minimized.

Copy link
Collaborator Author

dginev commented Nov 14, 2017

I have a related question about --mathimagemagnification . I am currently wondering why setting that option does not in any way alter the SVG -- I am getting the exact same snippet back irrespective of whether I set it to 0.1 or 5.0. Is this another latexmlc bug?

@dginev

This comment has been minimized.

Copy link
Collaborator Author

dginev commented Nov 14, 2017

Double-checked, the options is passed in all the way to the --mag parameter of dvisvgm, I guess it just has no effect. Would love to be able to find the right rules to have both 1D single-line equations and heavily 2D (e.g. nested fraction) equations have the accurate font size and height on the same web page... Is there a known trick to nail that down? I played around with the SVG result using javascript on the final webpage - overriding the root <svg> height to 0.9em for 1D equations works wonders, but performs (obviously) terribly for 2D math.

It feels like it should be solved differently, before it ever lands on the page, e.g. via this magnification parameter.

@brucemiller

This comment has been minimized.

Copy link
Owner

brucemiller commented Nov 15, 2017

Confused: Did you inadvertently move lib/LaTeXML.pm to lib/LaTeXML/LaTeXML.pm, or what happened?

@dginev

This comment has been minimized.

Copy link
Collaborator Author

dginev commented Nov 15, 2017

That is exactly what happened sigh. The reason is that I added the commit in the Authorea fork, which is too weirdly ahead of master, so then I went to my own personal fork and did a clumsy cp of the files -- and got the directory wrong!!

@dginev

This comment has been minimized.

Copy link
Collaborator Author

dginev commented Nov 15, 2017

I promise that "squash and merge" deletes all traces of such stupidity, so you will never be able to tell in master

@brucemiller

This comment has been minimized.

Copy link
Owner

brucemiller commented Nov 15, 2017

Naturally, dvisvgm writes an svg file, and naturally latexmlmath should return the svg data, rather than drop a file somewhere. I was less clear about the more conventional usage; should an html page contain the embedded svg or a reference to a file? Both seem desirable options. I left it alone for now, particularly since the svg's are rather large with font info. Maybe when that issue is clarified.

As for when we get "serious" about svg, my take is that it would always be included within a mathml annotation (whether literal or as a file), so we'd still want the math parsing :>

@brucemiller

This comment has been minimized.

Copy link
Owner

brucemiller commented Nov 15, 2017

Oh, and it would be nice if --mag worked as expected (never really checked it). I suppose that if dvisvgm ignores that flag, there're probably ways to work around it. One would be to embed it into the tex code that latex runs (may cause font issues, though); another alternative would be surgery on the svg to wrap an appropriate `svg:g' element... sounds unpleasant.

@dginev

This comment has been minimized.

Copy link
Collaborator Author

dginev commented Nov 15, 2017

Thanks for the info. I guess I'll come back to this a bit later this week and play around with the options to see if I can find a sweetspot that guesses the ideal font values -- there seem to be a range of options http://dvisvgm.bplaced.net/Manpage

It is quite likely that simply having the actual text characters preserved in SVG and styling them via font-size CSS may be saner, but I am not privy to the font madness involved in turning that off.

@brucemiller

This comment has been minimized.

Copy link
Owner

brucemiller commented Nov 15, 2017

CSS probably is not the answer: I doubt it would affect the layout, just put bigger glyphs in the same small places.

I just looked at dvisvgm manpage, and although it does take the --mag option, it seems to be only about the font magnification used in tracing glyphs. There is a --scale option which sounds like the right thing... worth a try, anyway.

@dginev

This comment has been minimized.

Copy link
Collaborator Author

dginev commented Nov 15, 2017

Strangely enough changing the scale value also doesn't modify it at all... I think I am making a fatal mistake - could the old results remain cached? I think I need to hard remove mi/ and LaTeXML.cache to get a fresh result. Luckily this is an issue only for development but confused me quite a way. Retrying now...

@dginev dginev force-pushed the dginev:mathsvg-for-latexmlc branch from 19a09eb to 872616c Nov 15, 2017
@dginev

This comment has been minimized.

Copy link
Collaborator Author

dginev commented Nov 15, 2017

Great, scale works exactly as I would expect it, a value of --mathimagemagnification=2 adds a nice matrix transform to my example that looks like:

<g id="page1" transform="matrix(2 0 0 2 0 0)">
<use x="63.6434" xlink:href="#g0-120" y="62.7646"/>
</g>

I added the change to this PR, let me know if it looks good!

@dginev

This comment has been minimized.

Copy link
Collaborator Author

dginev commented Nov 15, 2017

Here is an example of something I managed to put together on the same (Authorea) web page with --mathimagemagnification=1.4 and this PR (the katex rendering uses a 19.36px; font-size, for reference).

So I think the --scale switch is a very usable upgrade, and welcome merging here 👍

selection_999 016

Figure legend: same equations, each katex version has a plain x, while the latexml version has a \bm{x} relying on the bm package.

@brucemiller brucemiller merged commit 998d7a3 into brucemiller:master Nov 15, 2017
1 check passed
1 check passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@brucemiller

This comment has been minimized.

Copy link
Owner

brucemiller commented Nov 15, 2017

OK, looks to be a definite improvement and a small step towards Proper MathML & SVG!

@dginev dginev deleted the dginev:mathsvg-for-latexmlc branch Feb 25, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.