Katex: Support units other than em, ex, mu (e.g. "\\[0.5 cm]" and "p{1cm}" within array)

Created on 15 May 2017 · 27Comments · Source: KaTeX/KaTeX

Hello, I want to write a table in my html page with the following code

\begin{array}{ccccc}
   & A & B & C &  \\
\textrm{Cantidad demandada por ciudad} & x & y & z & 42\\[0.5cm]
\textrm{Cierta semana piden} & y+z & 1.2\displaystyle\left(\frac{x}{2}+\frac{z}{3}\right) & z & 
\end{array}

But when you save it to the editor, the browser does not display that table, unless you remove \\[0.5cm]

Also I can not control the column width, ie I do not see anything in the browser when I write \begin{array}{p{2cm}cccc}

How do I solve this?

Here I leave my complete code for whatever case

<!DOCTYPE html>
<html>
    <head>
        <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/KaTeX/0.7.1/katex.min.css" integrity="sha384-wITovz90syo1dJWVh32uuETPVEtGigN07tkttEqPv+uR2SE/mbQcG7ATL28aI9H0" crossorigin="anonymous">
        <script src="https://cdnjs.cloudflare.com/ajax/libs/KaTeX/0.7.1/katex.min.js" integrity="sha384-/y1Nn9+QQAipbNQWU65krzJralCnuOasHncUFXGkdwntGeSvQicrYkiUBwsgUqc1" crossorigin="anonymous"></script>
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
        <title>Sistemas de ecuaciones</title>
    </head>
    <body>

<p align="center" ><span class="tex" data-expr="\begin{array}{{p{2cm}cccc}}
& A & B & C &  \\[0.5cm]
\textrm{Cantidad demandada por ciudad} & x & y & z & 42\\
\textrm{Cierta semana piden} & y+z & 1.2\displaystyle\left(\frac{x}{2}+\frac{z}{3}\right) & z & 
\end{array}"</span></p>

    <script>
     window.onload = function() {
      var tex = document.getElementsByClassName("tex");
      Array.prototype.forEach.call(tex, function(el) {
          katex.render(el.getAttribute("data-expr"), el);
      });
        }; 
    </script>

    </body>
</html>

Source

MathSalomon

All 27 comments

@MathSalomon we only support em, ex, and mu measurements at the moment.

kevinbarabash on 15 May 2017

👍1

@kevinbarabash I see. Well, at least I can create custom tables in html and fill them with Katex. Thank you anyway.

MathSalomon on 15 May 2017

KaTeX really ought to support the other TeX units. I imagine we just need to decide what 1em translates to in TeX land (based on the internal notion of font size), and convert other units into that -- or vice versa. (In HTML/CSS, everything has a defined scale relative to the px unit.)

edemaine on 15 May 2017

👍1

Say that an array contains \\[0.5 cm]. And the array is wrapped with custom delimiters \left\{ ... \right..

How then does a server-side installation of KaTeX determine the height of that brace?

ronkok on 19 May 2017

Hmm... all of measurements are em based... maybe we could use calc in a creative way. How important is support absolute units of measure?

kevinbarabash on 19 May 2017

In testing for PR #670, I'm finding that browser support for CSS calc() is still less than 100% reliable. Any solution that depends heavily on calc would need thorough browser testing.

ronkok on 19 May 2017

I'm confused. HTML doesn't support absolute units at all (well, except mozmm); everything is relative to px. So similarly, we could compute everything relative to em, I think (in the same way we already convert ex to em, which is dependent on the font). Ah, but we have to take care that e.g. in is not relative to font size scaling, unlike em and ex.

edemaine on 19 May 2017

Correct. in, cm, mm are not relative to font size.

We could write a note in the browser support page to say that in, cm, mm are not supported when KaTeX is running server-side. That puts a burden on the author to know the difference between browser-side and server-side. And another burden to know where exactly the subject math will end up being rendered.

ronkok on 19 May 2017

Why can't this be computed server side? fontMetrics.js defines ptPerEm which maps between font coordinates (em/ex/etc.) and measurement coordinates (pt/in/cm/etc.). buildHTML.js uses this for a font-independent "scriptspace". Just need to generalize this.

edemaine on 19 May 2017

I don't think one should take that ptPerEm attribute literally. It is hard-coded to be equal to 10. That cannot be literally true when websites can set the base font to be any size.

In fact, all KaTeX dimensions are in ems and are therefore relative to font size. I have a guess at the source of the 10 ptPerEm number.

// These font metrics are extracted from TeX by using
// \font\a=cmex10

My guess is that all the metrics were extracted from a 10 pt font. But everything scales up and down with font size because all dimensions in KaTeX are done in units of em. The ptPerEm number can get away with being hard coded at 10 because it is used to define things like kern distances and scriptspace. Things, in other words, that also scale up and down with font size.

So I suppose ptPerEm is a misleading name. It should not be used to convert to an actual absolute distance.

ronkok on 19 May 2017

@ronkok But isn't that exactly what we want? I might be missing something here. But what I want is for X\hspace{1mm}Y (say) to render in KaTeX (roughly) the same as it would render in LaTeX (with \documentclass[10pt]{article}), up to scaling. Yes, the browser can scale everything. But we want the spacing to scale in exactly the same way that fonts do. So if the X renders bigger, the hspace should also render bigger. We never want "absolute distance".

edemaine on 19 May 2017

So now let's go back to @MathSalomon's issue. He wants a spacing of \\[0.5cm]. He has explicitly asked for something that does not scale with font size. The server doesn't know the website's base font size, so server-side KaTeX has no obvious, non calc, way to convert from em to cm.

ronkok on 19 May 2017

We'd have to make KaTeX aware of the actual font size being used.

kevinbarabash on 19 May 2017

But the font size can change, on the fly, while the web page is being viewed, long after the server has generated its HTML. It would take some very sophisticated CSS to be responsive to such a change.

ronkok on 19 May 2017

Yeah... I don't think this is worth the effort.

kevinbarabash on 19 May 2017

It may be very feasible on the browser-side. But, if you take this on, you should start with the knowledge that this will cause a break between server-side capability and browser-side capability.

I've been more negative on this topic than is really reflective of my thoughts. There are pro's and con's to this idea. I've written some of the con's because no one else was, and I thought you should make an informed decision. I will support whatever decision you make and I might even help write the documentation.

ronkok on 19 May 2017

Okay, one last comment. Even if absolute units were feasible sever-side, they are usually bad practice. Per @edemaine:

We never want "absolute distance".

I think that is true much more often than not. Consider a hypothetical author who contributes an article to Khan Academy. That person is a subject matter expert in their own field, a real boffin. But not web savvy.

Now the author writes \\[0.5 cm], looks at the result, and is satisfied. That author is probably completely unaware that a web page administrator might some day change the underlying font size and make that 0.5 cm gap look terrible. And so KA would end up with articles that are brittle to a font change.

IMHO, Absolute units, even if feasible, would cause more problems than they would solve.

ronkok on 19 May 2017

In my opinion, we should accept "absolute distances" (in, cm, etc.) as input, but convert them to how LaTeX would render in 10pt mode. Under this model, we can convert all units to em (via ptPerEm and using \normalsize font size) and render them as em in HTML. Yes, the browser can scale everything, but then all distances ("absolute" and "font-relative") would all scale in exactly the same way, so everything will simply be a scaled version of the 10pt LaTeX rendering.

Hopefully this proposal is clear. I can try to put together a PR to show more precisely what I mean. (But I probably need to fix/understand the font sizing issue in #709 first, as I need to get to \normalsize to do this translation.)

edemaine on 20 May 2017

👍1

Sounds good to me.

kevinbarabash on 20 May 2017

1 cm box does not scale with document font size. So says W3C. MathJax agrees.

ronkok on 20 May 2017

That's an HTML/CSS 1 cm box. I was suggesting defining the meaning of a LaTeX 1cm box to mean a (something) em box, which will get rendered at different sizes depending on the HTML/CSS font-size. I guess that will be incompatible with MathJax, though it wouldn't be the first time...

Maybe we could make ptPerEm configurable as an option, so that people could set the KaTeX-viewed font size from the outside to match the CSS, if they wanted to, and otherwise the behavior is this scaling relative to 10pt font? Or rather, make the 10pt base font size a specifiable option.

edemaine on 20 May 2017

To test the of intelligibility of this proposal, let’s try writing the documentation. If cm is the CSS definition, then the environment section can contain the line:

Acceptable line separators include: \\, \cr, and \\[*distance*]. Distance can be written with units of em, ex, mu, mm, cm, or in.

Everyone will know what that line means. If we define cm as you wish, how then should we write that line?

ronkok on 20 May 2017

We may want to add a section to the README explaining how KaTeX measurements are computed and that they scale relative to the font size.

kevinbarabash on 20 May 2017

I speak now as an advocate for math authors, not programmers or web site administrators. A person who contributes an article to a web site should not have to understand the material in README. They are subject matter experts, not web mavens. They need to know what is in the Function Support page and they need to know that it goes between $ ...$ . And that's it.

Remember, they're busy, too. They became subject matter experts because they put in the time.

ronkok on 20 May 2017

Point taken. In the docs we can state simply which units are accepted, but we should have a note somewhere about how scaling affects units like mm, cm, and in.

kevinbarabash on 13 Jun 2017

OK, I made a proposal for this in #732, with some more rationale about why I think this is the way to go (at least given past KaTeX decisions). I'd suggest continuing any discussion there.

edemaine on 15 Jun 2017

🎉1

This is in v0.8.0.

kevinbarabash on 12 Aug 2017

Was this page helpful?

0 / 5 - 0 ratings