Can MathJax use font xxxx in March 2018 with a specific use case?

[Daniel]

Hi,

I try to use a user font for the MathJax typesetting. I have read

https://github.com/mathjax/mathjax-docs/wiki/Can-MathJax-use-font-xxxx%3F

However, it is rather old and mentions at several places reasons not to use a user font that do not apply to my specific use case.

Use case:

• MathJax is used to generate SVG output that the user exports to a bitmap for use in other documents, like word processors.
  
• Ideally, the user should be able to select any of his installed fonts for the export to match the font used in another document.

So, one important argument for why not to use user fonts, i.e. it could lead to different rendering for different users, does not apply since a particular output is only rendered for a particular user.

Under these circumstances, what would be the currently best way to achieve my aim?

Best regards,
Daniel

[Davide Cervone]

Use case:

• MathJax is used to generate SVG output that the user exports to a bitmap for use in other documents, like word processors.
  

In general, this will produce low-quality results.  The first problem you will face will be the baseline alignment problem (you have to position the image vertically at the proper place, and that is not easy, and will have to be different for each image).  Then even if you get that right, the print quality will be low unless you use large images and scale them down on screen, in which case the screen versions will be harder to read, and the file sizes will be quite large.  Also, if you are presenting these in electronic form, they will not be accessible to those with screen readers, for example.

You would be better off using MathML if you can (e.g., that works in MS Word), or SVG images rather than bitmaps, though you all still have the baseline alignment issue.

• Ideally, the user should be able to select any of his installed fonts for the export to match the font used in another document.

That is not going to be possible with MathJax.  As discussed on the site you linked to, MathJax needs to know the bounding box information and other data about every glyph in the font in order to properly typeset the mathematics.  This information simply isn't available to javascript about arbitrary fonts.  The data for the limited number of fonts that MathJax supports has been converted into data tables in javascript files so that MathJax can have this data.  That conversion process is done once outside of MathJax to make that data available, and is not something that can be done effectively from within the browser.  (There are libraries that can do that in the browser for web-based fonts, but not for system-installed fonts, though they were not available when MathJax was developed.)

In addition to the bounding box information, MathJax's SVG output does not use actual fonts for the characters that appear in the MathJax fonts themselves.  Instead, it uses SVG paths directly.  This is to avoid the fragile font-detection code of the HTML-CSS output, and the differences between system font-rendering engines that caused inconsistencies in the sizes (and so the alignment) of the results across browsers.  The conversion of the font glyphs to these paths also is done outside the browser once and for all, and the results stored as javascript data in files loaded by MathJax.  Without that data, MathJax can't lay out the font.

Finally, most fonts don't include all the glyphs necessary to render mathematics (e.g., the pieces needed to create stretchy characters, multiple sizes of parentheses and other delimiters or multiple sizes of accents like hats and tildes, all the required accents like vector arrows, glyphs for double-struck, script, calligraphic, Fraktur, and the other forms expected in mathematics, not to mention all the various relations, operators, and so on).  Even if they have the characters, most don't have the tables that tell how the stretchy characters are built or what the various sizes of the delimiters are.  So even if MathJax could read the font metrics, most fonts are not appropriate for mathematical typesetting.  Without all the characters, one would have to mix fonts within the mathematics itself, and that generally looks bad (as you know, since you are trying to avoid the change in font from the text to the mathematics -- image how much more jarring it would be to change fonts within the mathematics itself).

So the upshot is, MathJax is unlikely ever to be able to handle arbitrary system fonts.  It might be possible to do something with arbitrary web fonts, provided they have the needed characters, which is unlikely, though the font data used by MathJax still includes some hand-generated data that I won't get into, so the results still might not be perfect.  In any case, we don't have any current plans to support that.

We are working on version 3 of MathJax, and it does have a more flexible internal font format that should allow mixing of fonts (e.g., substituting another font for the letters and numbers while still using the standard ones for everything else), and will include the tools for generating the needed data.  But it will still be about a specific set of fonts that MathJax has the data for, not arbitrary fonts selected by a user.

Davide

[Daniel]

Thanks a lot for the helpful explanation and comments. Some comments and questions below.

Am Montag, 19. März 2018 11:52:55 UTC+1 schrieb Davide Cervone:

Use case:

• MathJax is used to generate SVG output that the user exports to a bitmap for use in other documents, like word processors.
  

In general, this will produce low-quality results.  The first problem you will face will be the baseline alignment problem (you have to position the image vertically at the proper place, and that is not easy, and will have to be different for each image).  

I am not getting this. Maybe it is a misunderstanding. Actually, I am not only exporting the formulas, but diagrams where the formulas are used as labels.
 

Then even if you get that right, the print quality will be low unless you use large images and scale them down on screen, in which case the screen versions will be harder to read, and the file sizes will be quite large.  Also, if you are presenting these in electronic form, they will not be accessible to those with screen readers, for example.

You would be better off using MathML if you can (e.g., that works in MS Word), or SVG images rather than bitmaps, though you all still have the baseline alignment issue.

Yes, I thought about MathML and SVG. However, the problem with the former is that I found no way to get MathML to work within diagrams across word processors. The problem with SVG is that, first, it does not solve the basic problem that the font will likely differ from the font in the document and, second, unbelievable as it is, SVG is not supported by some word processors, like MS Word unless one has the 365 version (I know no one who does), and only with basic functionality in other applications.

• Ideally, the user should be able to select any of his installed fonts for the export to match the font used in another document.

That is not going to be possible with MathJax.  As discussed on the site you linked to, MathJax needs to know the bounding box information and other data about every glyph in the font in order to properly typeset the mathematics.  This information simply isn't available to javascript about arbitrary fonts.  The data for the limited number of fonts that MathJax supports has been converted into data tables in javascript files so that MathJax can have this data.  That conversion process is done once outside of MathJax to make that data available, and is not something that can be done effectively from within the browser.  (There are libraries that can do that in the browser for web-based fonts, but not for system-installed fonts, though they were not available when MathJax was developed.)

In addition to the bounding box information, MathJax's SVG output does not use actual fonts for the characters that appear in the MathJax fonts themselves.  Instead, it uses SVG paths directly.  This is to avoid the fragile font-detection code of the HTML-CSS output, and the differences between system font-rendering engines that caused inconsistencies in the sizes (and so the alignment) of the results across browsers.  The conversion of the font glyphs to these paths also is done outside the browser once and for all, and the results stored as javascript data in files loaded by MathJax.  Without that data, MathJax can't lay out the font.

Finally, most fonts don't include all the glyphs necessary to render mathematics (e.g., the pieces needed to create stretchy characters, multiple sizes of parentheses and other delimiters or multiple sizes of accents like hats and tildes, all the required accents like vector arrows, glyphs for double-struck, script, calligraphic, Fraktur, and the other forms expected in mathematics, not to mention all the various relations, operators, and so on).  Even if they have the characters, most don't have the tables that tell how the stretchy characters are built or what the various sizes of the delimiters are.  So even if MathJax could read the font metrics, most fonts are not appropriate for mathematical typesetting.  Without all the characters, one would have to mix fonts within the mathematics itself, and that generally looks bad (as you know, since you are trying to avoid the change in font from the text to the mathematics -- image how much more jarring it would be to change fonts within the mathematics itself).

So the upshot is, MathJax is unlikely ever to be able to handle arbitrary system fonts.  It might be possible to do something with arbitrary web fonts, provided they have the needed characters, which is unlikely, though the font data used by MathJax still includes some hand-generated data that I won't get into, so the results still might not be perfect.  In any case, we don't have any current plans to support that.

I see. However, maybe there is still hope if the ambitions are limited? I understood that the really nice math output is only available through the predefined fonts. But maybe one can at least produce okay looking SVG graphics where MathJax replaces normal text (placed within \text{}) and only the strictly mathematical content is typeset using another method?
 

We are working on version 3 of MathJax, and it does have a more flexible internal font format that should allow mixing of fonts (e.g., substituting another font for the letters and numbers while still using the standard ones for everything else), and will include the tools for generating the needed data.  But it will still be about a specific set of fonts that MathJax has the data for, not arbitrary fonts selected by a user.

Yes, that sounds like a nice compromise. But it does not work at all in version 2?

I am also curious about version 3: will it produce the exact same SVG output as version 2? I am wondering because I am exporting to bitmap which fixes the output when exporting.

Daniel
 

Davide

[David Farmer]

Dear Daniel,

I don't think you have described your use case.

Do you really need to be able to paste the formula into any word
processor? If you really want that, then there is no uniform solution
that gives good results in all cases.

Do you expect your users to manually position the formula as
an image?

Davide gave a clear explanation for why it is impossible to get
excellent results if you let the user choose any font and also
automate the placement of the formula. I am wondering why you
are still seeking a method that seems destined to give poor results.

If you were more forthcoming about what you actually want to
do, then maybe there is a good solution.

Regards,

David

On Tue, 20 Mar 2018, Daniel wrote:

> Thanks a lot for the helpful explanation and comments. Some comments and questions below.
>
> Am Montag, 19. März 2018 11:52:55 UTC+1 schrieb Davide Cervone:
> Use case:

> o MathJax is used to generate SVG output that the user exports to a bitmap

> for use in other documents, like word processors.
>
>
> In general, this will produce low-quality results.  The first problem you will face will be the
> baseline alignment problem (you have to position the image vertically at the proper place, and
> that is not easy, and will have to be different for each image).  
>
>
> I am not getting this. Maybe it is a misunderstanding. Actually, I am not only exporting the formulas,
> but diagrams where the formulas are used as labels.
>  
> Then even if you get that right, the print quality will be low unless you use large images
> and scale them down on screen, in which case the screen versions will be harder to read,
> and the file sizes will be quite large.  Also, if you are presenting these in electronic
> form, they will not be accessible to those with screen readers, for example.
>
>
> You would be better off using MathML if you can (e.g., that works in MS Word), or SVG images
> rather than bitmaps, though you all still have the baseline alignment issue.
>
>
> Yes, I thought about MathML and SVG. However, the problem with the former is that I found no way to
> get MathML to work within diagrams across word processors. The problem with SVG is that, first, it
> does not solve the basic problem that the font will likely differ from the font in the document and,
> second, unbelievable as it is, SVG is not supported by some word processors, like MS Word unless one
> has the 365 version (I know no one who does), and only with basic functionality in other applications.

> o Ideally, the user should be able to select any of his installed fonts for

> --
> You received this message because you are subscribed to the Google Groups "MathJax Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
> mathjax-user...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>

[Davide Cervone]

Use case:

• MathJax is used to generate SVG output that the user exports to a bitmap for use in other documents, like word processors. 
  

In general, this will produce low-quality results.  The first problem you will face will be the baseline alignment problem (you have to position the image vertically at the proper place, and that is not easy, and will have to be different for each image).  

I am not getting this. Maybe it is a misunderstanding. Actually, I am not only exporting the formulas, but diagrams where the formulas are used as labels.

OK, I misunderstood your intentions.  I thought you were saving the equations to use within the normal text of a document (like for "suppose f(x,y) = 3x + 2y is a function...").  If you used an image in this case, you would have to vertically align it so that the bottom of the image was below the baseline in order to get the equation to line up with the text surrounding it.  If you are using math as labels inside a larger diagram and want to save that diagram as a bitmap, that is at least understandable (although a structured diagram like an SVG would give better results in programs that can use them).

You would be better off using MathML if you can (e.g., that works in MS Word), or SVG images rather than bitmaps, though you all still have the baseline alignment issue.

Yes, I thought about MathML and SVG. However, the problem with the former is that I found no way to get MathML to work within diagrams across word processors.

Right.  I didn't realize you were putting the math into larger diagrams.

The problem with SVG is that, first, it does not solve the basic problem that the font will likely differ from the font in the document and, second, unbelievable as it is, SVG is not supported by some word processors, like MS Word unless one has the 365 version (I know no one who does), and only with basic functionality in other applications.

Sad, isn't it.  Does it support PDF images?  You could convert the SVG to PDF, and (as long as the conversion doesn't go through a bitmap first), that should get better results than a bitmap.

• Ideally, the user should be able to select any of his installed fonts for the export to match the font used in another document.

...

So the upshot is, MathJax is unlikely ever to be able to handle arbitrary system fonts.  It might be possible to do something with arbitrary web fonts, provided they have the needed characters, which is unlikely, though the font data used by MathJax still includes some hand-generated data that I won't get into, so the results still might not be perfect.  In any case, we don't have any current plans to support that.

I see. However, maybe there is still hope if the ambitions are limited? I understood that the really nice math output is only available through the predefined fonts. But maybe one can at least produce okay looking SVG graphics where MathJax replaces normal text (placed within \text{}) and only the strictly mathematical content is typeset using another method?

MathJax already includes a configuration parameter that allows you to specify that the contents of \text{} calls will be in the surrounding font.  Use

MathJax.Hub.Config({

  SVG: {

    mtextFontInherit: true

  }

});

to make that happen.  See

http://docs.mathjax.org/en/latest/options/output-processors/SVG.html

We are working on version 3 of MathJax, and it does have a more flexible internal font format that should allow mixing of fonts (e.g., substituting another font for the letters and numbers while still using the standard ones for everything else), and will include the tools for generating the needed data.  But it will still be about a specific set of fonts that MathJax has the data for, not arbitrary fonts selected by a user.

Yes, that sounds like a nice compromise. But it does not work at all in version 2?

Version 2 is not set up to allow for that/

I am also curious about version 3: will it produce the exact same SVG output as version 2? 

We currently are implementing the CommonHTML output first, and haven't started the SVG output yet.  Because this is a complete rewrite, I expect that we will take this opportunity to improve some of the features of the SVG output, and so I would not expect it to be exactly the same output.  I'm not sure how exact you need the similarity to be.  it should be basically the same.

Davide

[Daniel]

Am Dienstag, 20. März 2018 14:20:36 UTC+1 schrieb Davide Cervone:

Use case:

• MathJax is used to generate SVG output that the user exports to a bitmap for use in other documents, like word processors. 
  

In general, this will produce low-quality results.  The first problem you will face will be the baseline alignment problem (you have to position the image vertically at the proper place, and that is not easy, and will have to be different for each image).  

I am not getting this. Maybe it is a misunderstanding. Actually, I am not only exporting the formulas, but diagrams where the formulas are used as labels.

OK, I misunderstood your intentions.  I thought you were saving the equations to use within the normal text of a document (like for "suppose f(x,y) = 3x + 2y is a function...").  If you used an image in this case, you would have to vertically align it so that the bottom of the image was below the baseline in order to get the equation to line up with the text surrounding it.  If you are using math as labels inside a larger diagram and want to save that diagram as a bitmap, that is at least understandable (although a structured diagram like an SVG would give better results in programs that can use them).

You would be better off using MathML if you can (e.g., that works in MS Word), or SVG images rather than bitmaps, though you all still have the baseline alignment issue.

Yes, I thought about MathML and SVG. However, the problem with the former is that I found no way to get MathML to work within diagrams across word processors.

Right.  I didn't realize you were putting the math into larger diagrams.

Yes, sorry. I often forget what uncommon use case I have...
 

 

The problem with SVG is that, first, it does not solve the basic problem that the font will likely differ from the font in the document and, second, unbelievable as it is, SVG is not supported by some word processors, like MS Word unless one has the 365 version (I know no one who does), and only with basic functionality in other applications.

Sad, isn't it.  Does it support PDF images?  You could convert the SVG to PDF, and (as long as the conversion doesn't go through a bitmap first), that should get better results than a bitmap.

Indeed, there seems to be some support for PDF images. I haven't thought about this option before. I am using Imagick (php) for conversions. However, that gives rasterized conversion only. Do you happen to know a way to convert from SVG to PDF within the browser (client or server side doesn't matter, I guess)? If not, I'll try to find a way.

• Ideally, the user should be able to select any of his installed fonts for the export to match the font used in another document.

...

So the upshot is, MathJax is unlikely ever to be able to handle arbitrary system fonts.  It might be possible to do something with arbitrary web fonts, provided they have the needed characters, which is unlikely, though the font data used by MathJax still includes some hand-generated data that I won't get into, so the results still might not be perfect.  In any case, we don't have any current plans to support that.

I see. However, maybe there is still hope if the ambitions are limited? I understood that the really nice math output is only available through the predefined fonts. But maybe one can at least produce okay looking SVG graphics where MathJax replaces normal text (placed within \text{}) and only the strictly mathematical content is typeset using another method?

MathJax already includes a configuration parameter that allows you to specify that the contents of \text{} calls will be in the surrounding font.  Use

MathJax.Hub.Config({

  SVG: {

    mtextFontInherit: true

  }

});

to make that happen.  See

http://docs.mathjax.org/en/latest/options/output-processors/SVG.html

Thanks a lot. I'll try it out and send my experience.
 

We are working on version 3 of MathJax, and it does have a more flexible internal font format that should allow mixing of fonts (e.g., substituting another font for the letters and numbers while still using the standard ones for everything else), and will include the tools for generating the needed data.  But it will still be about a specific set of fonts that MathJax has the data for, not arbitrary fonts selected by a user.

Yes, that sounds like a nice compromise. But it does not work at all in version 2?

Version 2 is not set up to allow for that/

I am also curious about version 3: will it produce the exact same SVG output as version 2? 

We currently are implementing the CommonHTML output first, and haven't started the SVG output yet.  Because this is a complete rewrite, I expect that we will take this opportunity to improve some of the features of the SVG output, and so I would not expect it to be exactly the same output.  I'm not sure how exact you need the similarity to be.  it should be basically the same.

I am not sure either. But I guess if it is similar or even better no one should complain. :)

Daniel
 

Davide

[Daniel]

Am Dienstag, 20. März 2018 13:11:30 UTC+1 schrieb David Farmer:

I don't think you have described your use case.

I think you are right.
 

Do you really need to be able to paste the formula into any word
processor?  If you really want that, then there is no uniform solution
that gives good results in all cases.

Do you expect your users to manually position the formula as
an image?

No, there is a whole diagram that can be positioned.
 

Davide gave a clear explanation for why it is impossible to get
excellent results if you let the user choose any font and also
automate the placement of the formula.  I am wondering why you
are still seeking a method that seems destined to give poor results.

If you were more forthcoming about what you actually want to
do, then maybe there is a good solution.

Here is an example diagram:
(Unfortunately, google groups does not support SVG as image either.)

Best would be to have the user choose the font for all labels of the diagram. But there seems to be no good solution for that. Second best is to have at least the pure text parts set in another font, e.g. "Risky Policy" and "Save Policy". The exported diagrams are for use in word processors.

Regards,

Daniel
 

[Davide Cervone]

The problem with SVG is that, first, it does not solve the basic problem that the font will likely differ from the font in the document and, second, unbelievable as it is, SVG is not supported by some word processors, like MS Word unless one has the 365 version (I know no one who does), and only with basic functionality in other applications.

Sad, isn't it.  Does it support PDF images?  You could convert the SVG to PDF, and (as long as the conversion doesn't go through a bitmap first), that should get better results than a bitmap.

Indeed, there seems to be some support for PDF images. I haven't thought about this option before. I am using Imagick (php) for conversions. However, that gives rasterized conversion only. Do you happen to know a way to convert from SVG to PDF within the browser (client or server side doesn't matter, I guess)? If not, I'll try to find a way.

This library looks like it might be what you need:

https://github.com/yWorks/svg2pdf.js

I haven't tried it, but it doesn't seem to go through a bitmap first, if I understand the description.

There is also this library:

http://pdfkit.org

but it doesn't seem to parse an SVG object, but rather is a javascript interface to svg-like commands, so that probably isn't want you want.

Davide