Support absolute TeX units #732

edemaine · 2017-06-14T22:28:30Z

This is a proposed fix to #706, as discussed in that thread.

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.

Rationale: Absolute distances are used all over KaTeX already, such as \arraycolsep being defined to 5pt. But it's not actually 5pt -- it renders as half of the font size. As a math author, this is actually what I want -- I don't care about "real-world distances", I care about how I'd write it in LaTeX to get the relative spacing that I want. I have an intuitive sense of how much space I add when I write \\[0.5in] (although I admittedly usually use em and ex units), and want roughly that much space, independent of what CSS font size or browser scaling they happen to get rendered in.

Issues: One issue I ran into is where to put the table of units. Currently it is in buildHTML, which means the parser can't access it and so can't directly tell whether a unit is valid, so I moved validity testing to buildHTML. (This causes some current tests to fail.) Perhaps it would be better to move this somewhere else. My feeling is that there should be a buildGeom that would be useful for outputting HTML and other "geometric" formats we support in the future (SVG, Canvas) but not MathML (so buildCommon doesn't make sense). Thoughts?

I'm also missing any additional tests. Open to suggestions. I think the obvious thing would be a screenshot test, as it's essentially a visual effect. An example I found useful was

\begin{array}{l}
  \mathrm H\kern 1em\mathrm H\\
  \mathrm H{\scriptstyle \kern 1em}\mathrm H\\
\end{array}

which taught me that the LaTeX em unit really doesn't change when switching style, only when switching font size. Not what I thought!

kevinbarabash · 2017-06-15T02:49:25Z

src/buildHTML.js

+// Thus, multiplying a length by this number converts the length from units
+// into pts.  Dividing the result by ptPerEm gives the number of ems
+// *assuming* a font size of ptPerEm (normal size, normal style).
+const ptPerUnit = {


I wonder if we should include em and mu in this list as well.

kevinbarabash · 2017-06-15T02:58:24Z

src/Parser.js

@@ -787,11 +787,8 @@ Parser.prototype.parseSizeGroup = function(optional) {
        number: +(match[1] + match[2]), // sign + magnitude, cast to number
        unit: match[3],
    };
-    if (data.unit !== "em" && data.unit !== "ex" && data.unit !== "mu") {
-        throw new ParseError("Invalid unit: '" + data.unit + "'", res);
-    }


We should continue to throw here, but check if data.unit is one of the keys in ptPerUnit (assuming we add em and mu to it).

kevinbarabash · 2017-06-15T03:01:55Z

I think we'll want to eventually have a buildGeom.js, but in this particular situation creating a units.js that can be imported into Parser.js and buildHTML.js probably makes the most sense.

kevinbarabash · 2017-06-15T03:04:26Z

@edemaine thanks for this PR. I love how simple the changes are for this.

edemaine · 2017-06-15T15:41:13Z

Thanks @kevinbarabash . The decision to make units.js is valuable, and makes the other issues easy to deal with.

Moved ptPerUnit (now ptPerAbsoluteUnit) to units.js. I think pt makes most sense for absolute units, so I kept it to absolute units.
Added emPerUnit which includes all absolute units, em, and mu, but no ex, as ex requires a function. [I had actually written this code before, then thought it wouldn't work because ems would need scaling based on font style, but later realized that isn't true...]
I added a validUnit function for Parser.js to use to check whether a unit is valid, in particular for the ex special case. This fixes most tests.
Changed 1px "bad unit" tests to 1au, so it's actually invalid and matches some other tests.

I'll save from squashing for easier review, but these commits should be squashed.

kohler · 2017-06-15T16:01:04Z

Hey Erik, I think you forgot to git add units.js. Also, I would suggest that #719 be merged first, since it will change this calculation.

edemaine · 2017-06-15T16:05:20Z

Oops, thanks! Added now. I ended up rebasing then.

Thanks for the heads up on #719. I realize now that this PR probably doesn't work with font-size changes like \large, but I take it #719 provides a (different) way to find out font size?

ronkok · 2017-06-16T03:13:11Z

I have a request. I ask that these proposed units be exposed to authors with names that are differentiated in some small way from the name of any pre-existing truly absolute unit.

For example, expose the unit name \cm or texcm, not cm. The unit name cm already has a standard meaning in HTML documents. The new, very valuable units in this PR deserve their own names.

edemaine · 2017-06-16T13:27:19Z

@ronkok I understand your concern, but I for one would not be happy with nonstandard units. I want to be able to copy/paste LaTeX code between LaTeX and KaTeX and have them render roughly the same, up to scaling. I doubt I am alone...

In my opinion, it's reasonable for units in KaTeX to mean LaTeX units, not CSS units. Another example: the following render with the same horizontal space in KaTeX and in LaTeX, because of the styles-don't-scale-ems rule I just learned about in LaTeX. (To test in LaTeX, you need to remove the braces on the \kern argument.)

\begin{matrix}
  x_{\kern{1em}y} \\
  x\kern{1em}_y
\end{matrix}

By contrast, the following render with different horizontal spaces in HTML:

x<sub><span style="padding-left:1em"></span>y</sub><br>
x<span style="padding-left:1em"></span><sub>y</sub>

So even for the existing primary unit, em, LaTeX ems differ from CSS ems. So there is no contract that HTML and CSS units should behave the same.

I could see an argument that absolute units should render as absolute units. That is not the decision made by KaTeX so far (which already uses pts internally, but expands them relative to font size), so I've matched that. Perhaps it would make sense, in the future, to add an option where units can render one way or the other, though as discussed before, that may actually be impossible on the client side. Definitely it makes sense to add an option to control the 10pt base size, so that it can match the actual CSS font size. (I thought about adding that to this PR, but it'd be an extensive change...)

But at least in my personal applications, the relative treatment of units as in this PR would work great.
Perhaps you have some ideas on how to improve the documentation I added to the README?

ronkok · 2017-06-16T16:00:39Z

I am all for relative units and I am very much in favor of a migration path from LaTeX. I just think that much confusion can be saved if we avoid using the same word to mean two different things. Poor @kevinbarabash will be doing user support for the rest of his life.

Of course, this PR may really be just a fiendish plot to make it impossible for KaTeX to ever support truly absolute units.

In which case you have my support.

edemaine · 2017-06-16T19:11:52Z

Hahaha, that made me laugh! I think I see what you're asking. There are a few possible long-term plans:

Support CSS relative meanings of LaTeX's absolute units, and that's it. Ideally with the base font size (10pt) configurable.
Support CSS absolute meanings of LaTeX's absolute units (same as MathJax?), and that's it.
Support absolute or relative meanings, configurable as an option to the renderer.
Support both absolute and relative meanings simultaneously (in the same LaTeX expression), and have a way to specify which you want (e.g. different names for the relative units, like you suggested).

I think you had in mind Plan 4, which explains the idea of naming the units differently. I think I had in mind Plan 1, and maybe later extension to Plan 3. In this case, we don't need to name the units differently.

Perhaps we should reach consensus on which plan(s) make sense in the long term. Personally I'm happy with Plan 1, even though it could lead to relevant support queries (kinda like the queries related to <!DOCTYPE...).

kevinbarabash · 2017-06-17T20:23:14Z

My vote would be for 2. It doesn't preclude doing any of the other options later.

edemaine · 2017-06-17T20:43:31Z

@kevinbarabash Ah. You do realize that's the opposite of what's implemented in this PR?

kevinbarabash · 2017-06-17T22:01:38Z

@edemaine I mis-parsed the choices. Is there an option that does what's in this PR? I agree with @ronkok that some people might be confused that cm in their LaTeX code behaves differently from the CSS's notion of cm, but... I feel like more people would be confused when they copy/paste stuff from tex.stackexchange or wherever and things look off. Option 3 sounds alright, but b/c this PR implements half of it. I would be okay with deferring making it configurable.

edemaine · 2017-06-18T00:43:47Z

Sorry for the confusion. Option 1 corresponds to the PR (once I correct it to handle font sizes). It could later be extended to Option 3.

kevinbarabash · 2017-06-28T01:01:33Z

@edemaine I've merged #719. Can you rebase this?

edemaine · 2017-06-30T18:24:03Z

Rebased, and separated out the handling of absolute and relative units using the new infrastructure from #719. All seems working, except I find that

\begin{array}{l}
  \mathrm H\kern 1em\mathrm H\\
  \mathrm H{\large \kern 1em}\mathrm H\\
\end{array}

now produces two identical spaces in KaTeX, but not in LaTeX. I think this is a bug, not from this PR, but introduced by #719. It's maybe not truly a bug because LaTeX gives LaTeX Font Warning: Command \large invalid in math mode, but it does compile, and the spaces are different in LaTeX, which matches my intuition (whereas replacing \large with \scriptstyle should, and does, produce the same spaces). @kohler could you comment on what might be going on here?

kohler · 2017-06-30T20:48:45Z

Yes, I think I found it.

Basically, as part of #719, I went through and changed mentions of Style.sizeMultiplier to Options.sizeMultiplier. This should have changed nothing: both sizeMultipliers are needed only for absolute sizes (rarely needed in KaTeX). But the change may have uncovered a few latent bugs.

~~In this case, the bug is that kerns used absolute units—as if 1em always referred to 1em in the current text or display size (not scriptstyle or scriptscriptstyle). That's not how TeX works.~~ (I was wrong; in TeX \kern1em does use the textstyle font's size, but \mkern1mu uses the current style's font sizes.)

But there's more. TeX's notion of a quad (em) is different from CSS's. In CSS “em” just measures the current font size. In TeX, 1em is relatively larger for nominally smaller font sizes. So \kern1em should not translate to 1em in CSS terms, you need to multiply the fontMetrics.quad value. This affects em and mu units. But ex was wrong too: ex is relative to the font size, not the TeX quad, so the previous use of emPerEx wasn't quite right.

This branch has the necessary changes but I have not run screenshotter tests or added new ones so no PR at the mo
https://github.com/kohler/KaTeX/tree/fix-sized-space

~~I think these bugs predate my refactorings~~ Some of these bugs predate my refactorings but I apologize either way.

edemaine · 2017-06-30T21:00:50Z

Cool, thanks for investigating!

I don't think this is quite right yet, though. As far as I've found in LaTeX, \kern 1em should be independent of style -- at least, it seems to produce the same space in \textstyle and \scriptstyle in LaTeX. So we still need to multiply by a multiplier...?

I didn't know about the quad measure. What fun!

kohler · 2017-07-01T04:01:44Z

You're partially right, but it turns out it depends.

(1) \kern

\tracingonline=1
$\textstyle a\kern1em\scriptstyle b\kern1em\scriptscriptstyle c\kern1em d$
\showlists

\hbox(0.0+0.0)x15.0
\mathon
\OML/cmm/m/it/10 a
\kern 10.00002
\OML/cmm/m/it/7 b
\kern 10.00002
\OML/cmm/m/it/5 c
\kern 10.00002
\OML/cmm/m/it/5 d
\mathoff

Result: 1em always in textsize.

(2) \mkern18mu

\tracingonline=1
$\textstyle a\mkern18mu\scriptstyle b\mkern18mu\scriptscriptstyle c\mkern18mu d$
\showlists

\hbox(0.0+0.0)x15.0
\mathon
\OML/cmm/m/it/10 a
\kern 9.99976
\OML/cmm/m/it/7 b
\kern 8.19443
\OML/cmm/m/it/5 c
\kern 7.36111
\OML/cmm/m/it/5 d
\mathoff

Result: 1em of current style (scaled).

(3) \kern in \text mode (NB not supported by katex yet)

\tracingonline=1
$\textstyle a\text{\kern1em}\scriptstyle b\text{\kern1em}\scriptscriptstyle c\text{\kern1em}d$
\showlists

\hbox(0.0+0.0)x15.0
\mathon
\OML/cmm/m/it/10 a
\hbox(0.0+0.0)x10.00002
.\hbox(0.0+0.0)x10.00002
..\kern 10.00002
\OML/cmm/m/it/7 b
\hbox(0.0+0.0)x7.97224
.\hbox(0.0+0.0)x7.97224
..\kern 7.97224
\OML/cmm/m/it/5 c
\hbox(0.0+0.0)x6.80565
.\hbox(0.0+0.0)x6.80565
..\kern 6.80565
\OML/cmm/m/it/5 d
\mathoff

Result: 1em of current size (scaled).

🤷‍♂️

kohler · 2017-07-01T13:19:33Z

src/units.js

+const calculateSize = function(sizeValue, options) {
+    let x = sizeValue.number;
+    if (sizeValue.unit in emPerUnit) {
+        x *= emPerUnit[sizeValue.unit];


I'd recommend making changes based on #755. em and mu should scale by the quad font metric; em should be additionally un-scaled if the current style is script/scriptscript.

kohler · 2017-07-01T13:22:44Z

src/units.js

+    if (sizeValue.unit in emPerUnit) {
+        x *= emPerUnit[sizeValue.unit];
+    } else if (sizeValue.unit === "ex") {
+        x *= options.fontMetrics().emPerEx;


Should be xHeight, and should be un-scaled in script/scriptscript.

kohler · 2017-07-01T13:25:08Z

src/units.js

+    } else if (sizeValue.unit === "ex") {
+        x *= options.fontMetrics().emPerEx;
+    } else if (sizeValue.unit in ptPerUnit) {
+        x *= ptPerUnit[sizeValue.unit] / options.fontMetrics().ptPerEm;


Think this should be divided by options.sizeMultiplier, so that \large/script/scriptscript doesn't change the meaning of absolute units.

edemaine · 2017-07-31T20:23:51Z

Finally got to rebasing this to include @kohler's em/ex/mu size fixes. I think this is ready to go now.

Here's a texcmp output for a new screenshot, which unfortunately has a shift caused by the parentheticals being in \tiny font, but otherwise looks like a perfect match -- testing ex, em, mu, and cm during both style changes ("ss" means \scriptstyle) and size changes ("sm" means \small).

edemaine · 2017-07-31T20:27:51Z

P.S. @ronkok Your documentation looks good, but your (*) footnote is no longer accurate, as @kohler discovered above. In fact, mu units scale with scriptstyle/scriptscriptstyle, while other relative units always refer to the textstyle font in the current size. (But these are all behaviors we inherit from TeX, so I don't know how much we need to say here...)

kevinbarabash · 2017-07-31T21:15:46Z

It's hard to tell what's going on with the spacing for \scriptstyle and \scriptscriptstyle b/c of the difference in horizontal metrics. It would be nice to fix that at some point. After some quick googling it appears that it's possible to scale an element such that elements flow around it properly instead of leaving whitespace (or lack thereof). Another PR for another day.

kevinbarabash · 2017-07-31T21:20:28Z

@edemaine what font size would this need to be rendered at to verify that 1cm is actually 1cm?

kohler · 2017-07-31T23:47:18Z

src/units.js

+    "dd": 1238 / 1157,  // didot
+    "cc": 14856 / 1157, // cicero (12 didot)
+    "nd": 685 / 642,    // new didot
+    "nc": 1370 / 107,   // new cîcero (12 new didot)


no î please ;)

Oops, missed one! Thanks.

kohler · 2017-07-31T23:53:39Z

README.md

+Similarly, if you specify a length using LaTeX absolute units,
+such as <code>\rule{1cm}{1pt}</code>, it gets converted into the
+equivalent number of ems assuming a 10pt font, which will end up getting
+scaled according to your font size.


So this isn't quite right? KaTeX might assume that the “base font size” of the .katex span is 10pt, but the reader is likely to misunderstand what that means. In katex.less, the default .katex rule raises the font size to 1.21em—that is, 1.21x the surrounding font size. Which means that KaTeX assumes that the base font size (1em in the surrounding context) is 8.264 TeX pt or something.

In a typical modern layout with 16px base font size, 1pt in KaTeX equals (16 * 1.21 / 10) = 1.936px (CSS px). Whereas 1 CSS pt always equals 1.333px. Weird!

This kind of makes me question this approach of mapping LaTeX units to relative CSS units. It would be better IMO for non-font-relative units—especially px!—to match CSS's concepts. It feels strange and even maybe misguided to document extremely precise units (“1 TeX inch is exactly 72.27 TeX point!”) when the precision is relative to an imprecisely specified, and often even unknown, base.

But I don't feel that strongly and actually implementing non-font-relative units would greatly complicate KaTeX height & depth calculations.

Perhaps best would be to document the current implementation but describe it as provisional. For example, “KaTeX might change in the future to make absolute TeX units, such as cm, in, and px, equivalent to the corresponding CSS units. We recommend using relative units.” This agrees with @ronkok's comment that absolute units kinda suck. :)

I wondered if this documentation needed updating -- thanks for the comments! I also wasn't aware of the 1.21x scaling. I assume there's a reason for that, like KaTeX fonts integrate better with typical web fonts at that scale?

Anyway, I took a stab at rewriting, and justifying why this makes sense. Namely, "The end result is that any rendered KaTeX should be a scaled version of what LaTeX would do with a 10pt base font (e.g., \documentclass{article}), where the scale depends on the CSS font-size." This is the only definition that will satisfy this property. Personally, I think it's what I'd want -- I want to be able to copy/paste some KaTeX code into LaTeX (or vice versa), even code that uses absolute units, and have everything look relatively the same, just up to a global scale factor.

To me, mapping KaTeX pt (say) to CSS pt would not make sense, precisely because an author wouldn't have enough context when writing the LaTeX to know how that should be scaled to "look good". For example, maybe you make an equation look good, but then globally change the site's font-size. Now your formulas will look relatively bad.

On the other hand, I'd be fine with later adding a unit like css pt that maps to CSS pt. Except that, as you say, this would make height computation difficult if not impossible to do on the server side.

kohler · 2017-07-31T23:55:24Z

src/units.js

+    "nc": 1370 / 107,   // new cîcero (12 new didot)
+    "sp": 1 / 65536,    // scaled point (TeX's internal smallest unit)
+    // https://tex.stackexchange.com/a/41371
+    "px": 803 / 800,    // \pdfpxdimen defaults to 1 bp in pdfTeX and LuaTeX


px is not a default TeX unit, and it might be more useful, and less surprising, to map px one-to-one onto CSS px than to this. 1 CSS px equals 1/96in.

px is built into pdflatex. Maybe I'm biased because that's the only TeX format I use, but that seems pretty standard/default to me. I'd be OK with omitting px (I frankly didn't realize it was valid in pdflatex until working on this PR), if we think it's too confusing -- but I don't think it's a good idea for some TeX units to map to CSS units when some TeX units to map to TeX units (in some sense).

kohler · 2017-07-31T23:59:26Z

src/units.js

+    if (sizeValue.unit in ptPerUnit) {
+        // Absolute units
+        scale = ptPerUnit[sizeValue.unit]   // Convert unit to pt
+           / options.fontMetrics().ptPerEm  // Convert pt to em


Update the comment to say CSS em?

edemaine · 2017-08-01T03:21:02Z

@kohler Implemented or responded to your review comments. Thanks for the quick review!

@kevinbarabash You should set the font-size of the root .katex element to 9.96264pt (manually in inspector). I just tried it, and \kern 1cm renders as margin-left: 2.84528em which, according to inspector, results in a width of 37.795px (in Chrome). Setting manually to margin-left: 1cm results in the same width of 37.795px. This makes sense given that, in CSS, 1in = 96px = 2.54cm, and 37.795 / 96 * 2.54 = 0.99999270833.

9.96264pt is a terrible consequence of the two different pt measurements. 9.96264 CSS pts = 9.96264 TeX bp = 10 TeX pt.

edemaine · 2017-08-01T03:57:21Z

Here's the output of texcmp for the same test without the \tiny parentheticals (which is where the horizontal metrics seem off). Seems to confirm we're doing all the cases right!

kohler · 2017-08-01T13:08:49Z

Please accept the following alternate text for the “font size and lengths” section. I feel pretty strongly about this. The current text overpromises and is more detailed than the README warrants.

Font size and lengths

By default, KaTeX math is rendered in a 1.21× larger font than the surrounding context, which makes super- and subscripts easier to read. You can control this using CSS; for example:

.katex { font-size: 1.1em; }

KaTeX supports all TeX units, including absolute units like cm and in. Absolute units are currently scaled relative to the default TeX font size of 10pt, so that \kern1cm produces the same results as \kern2.845275em. Since most browsers default to a larger font size, this typically means that a 1cm kern in KaTeX will appear larger than 1cm in browser units. This behavior may change in future.

FWIW, this image shows the difference between a 1cm rule in KaTeX (black) and a 1cm rule using browser units (red), with the default browser font size.

edemaine · 2017-08-01T14:16:51Z

@kohler I like that wording, and will change it once I'm at a computer again. (Small planned change: the use of em to specify percentages seems like it might be counterintuitive, so I'll add a mention that the CSS example achieves 1.1x.)

I'm OK with removing the "KaTeX aims to render a scaled version of what LaTeX would do", but I'm curious what is wrong with that. Do you disagree with the goal or the claim or both?

ronkok · 2017-08-01T14:42:42Z

Perhaps an edit?

KaTeX provides copy-and-paste compatibility with all TeX units. TeX's absolute units, like cm or in, are currently scaled relative to ...

I'm trying to be more precise with the word absolute. TeX has absolute units. KaTeX really doesn't.

kohler · 2017-08-01T19:34:57Z

@edemaine: I hate to respond because at some level we do agree but

Do you disagree with the goal or the claim or both?

I think KaTeX does, and should, aim for LaTeX compatibility, but “KaTeX aims to produce the visual equivalent of LaTeX output at 10pt body font size scaled up to, by default, 1.21x the font size of the context” isn't a good goal or a useful claim. KaTeX aims to be a fast, useful library for rendering TeX-like math in the browser. Scaled cut-and-paste compatibility with arbitrary LaTeX documents is a different goal and a less good one.

kohler · 2017-08-01T19:37:27Z

But it's your PR and if you feel strongly about the “KaTeX aims to render…” I approve of it.

kevinbarabash · 2017-08-02T03:34:00Z

Some thoughts:

calling out that we scale KaTeX fonts by 1.21x and how to change that is good as I think this is something that can catch people off guard
I doubt that many people using KaTeX for print so being able to scale things so that absolute measures are accurate is not important (I was asking out of curiosity)
some people may be interesting in how absolute measurements are handle so calling out that they scaled by the same scale factor that is applied to the rest of the layout is probably worth doing, but getting into the nitty gritty details probably isn't

edemaine · 2017-08-11T13:50:31Z

Sorry for the delay. I took a stab at revising the documentation. In particular, I left a statement about being a scaled version of LaTeX, but now it's just in the context of unit/kern rendering. Let me know if you see any other changes/comments!

kohler · 2017-08-11T21:47:21Z

LGTM!

kevinbarabash · 2017-08-11T22:30:46Z

@edemaine thanks for the PR. @kohler thanks for reviewing.

The new screenshot is correct as per #732 and compared to Firefox.

* Run screenshotter using Chrome 83 and Firefox 76 * Update screenshots * Update NegativeSpace-chrome screenshot The new screenshot is correct as per #1194. * Update Units-chrome screenshot The new screenshot is correct as per #732 and compared to Firefox. * Update screenshots

edemaine mentioned this pull request Jun 14, 2017

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

Closed

kevinbarabash reviewed Jun 15, 2017

View reviewed changes

kevinbarabash self-assigned this Jun 15, 2017

kevinbarabash added the GH Review: needs-revision label Jun 15, 2017

edemaine force-pushed the units branch from 45c90ee to e7799cc Compare June 15, 2017 16:02

edemaine added the blocked label Jun 15, 2017

edemaine mentioned this pull request Jun 17, 2017

Horizontal spacing commands: \>, \hfill #164

Closed

kevinbarabash removed the blocked label Jun 28, 2017

edemaine force-pushed the units branch from e7799cc to c986679 Compare June 30, 2017 18:18

kohler mentioned this pull request Jul 1, 2017

Correct computation of TeX sizes. #755

Merged

kohler requested changes Jul 1, 2017

View reviewed changes

Support absolute TeX units

9777403

edemaine force-pushed the units branch from 6b46ad0 to 9777403 Compare July 31, 2017 20:20

kohler reviewed Aug 1, 2017

View reviewed changes

Implement @kohler's comments

d0bda7d

edemaine added 2 commits August 11, 2017 09:46

Rewrite unit documentation according to @kohler's comments

21bf577

Merge branch 'units' of github.com:edemaine/KaTeX into units

8b7914d

kohler approved these changes Aug 11, 2017

View reviewed changes

Merge branch 'master' into units

ca5dc14

kevinbarabash added GH review: accepted and removed GH Review: needs-revision labels Aug 11, 2017

kevinbarabash merged commit a0bedcc into KaTeX:master Aug 11, 2017

edemaine mentioned this pull request Aug 12, 2017

Update function-support page for release 0.8.1 #787

Merged

kevinbarabash mentioned this pull request Sep 15, 2017

How to deal with absolute dimensions #296

Closed

ylemkimon added a commit that referenced this pull request Jul 13, 2020

Update Units-chrome screenshot

8115b5e

The new screenshot is correct as per #732 and compared to Firefox.

Support absolute TeX units #732

Support absolute TeX units #732

Conversation

edemaine commented Jun 14, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kevinbarabash commented Jun 15, 2017

kevinbarabash commented Jun 15, 2017

edemaine commented Jun 15, 2017 • edited Loading

kohler commented Jun 15, 2017

edemaine commented Jun 15, 2017 • edited Loading

ronkok commented Jun 16, 2017

edemaine commented Jun 16, 2017

ronkok commented Jun 16, 2017

edemaine commented Jun 16, 2017

kevinbarabash commented Jun 17, 2017

edemaine commented Jun 17, 2017

kevinbarabash commented Jun 17, 2017

edemaine commented Jun 18, 2017

kevinbarabash commented Jun 28, 2017

edemaine commented Jun 30, 2017 • edited Loading

kohler commented Jun 30, 2017 • edited Loading

edemaine commented Jun 30, 2017 • edited Loading

kohler commented Jul 1, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

edemaine commented Jul 31, 2017

edemaine commented Jul 31, 2017

kevinbarabash commented Jul 31, 2017

kevinbarabash commented Jul 31, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

edemaine Aug 1, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

edemaine commented Aug 1, 2017 • edited Loading

edemaine commented Aug 1, 2017

kohler commented Aug 1, 2017

Font size and lengths

edemaine commented Aug 1, 2017

ronkok commented Aug 1, 2017

kohler commented Aug 1, 2017

kohler commented Aug 1, 2017

kevinbarabash commented Aug 2, 2017

edemaine commented Aug 11, 2017

kohler commented Aug 11, 2017

kevinbarabash commented Aug 11, 2017

edemaine commented Jun 14, 2017 •

edited

Loading

edemaine commented Jun 15, 2017 •

edited

Loading

edemaine commented Jun 15, 2017 •

edited

Loading

edemaine commented Jun 30, 2017 •

edited

Loading

kohler commented Jun 30, 2017 •

edited

Loading

edemaine commented Jun 30, 2017 •

edited

Loading

edemaine Aug 1, 2017 •

edited

Loading

edemaine commented Aug 1, 2017 •

edited

Loading