Conversation
Make the width of an accented character equal to the width of the character, by making accents zero width. In particular, fixes KaTeX#1028 (`\ddot\imath`). This involved reworking all of the accent offset machinery, in particular skew and accent-hungarian. A bit cleaner now. Also added support for the new width character metrics in symbolNode.
|
You can see the difference in the spacing in the font tests. |
|
@edemaine does this mean that we don't use combining accent glyphs for anything (besides |
|
@edemaine the screenshots look good for |
| "style": "width:" + width + "em", | ||
| "viewBox": "0 0 " + 1000 * width + " " + 1000 * height, | ||
| "preserveAspectRatio": "xMinYMin", | ||
| }); |
There was a problem hiding this comment.
We should be able to get rid of this once we have non-combining \vec as well. Then all of the non-stretchy accent code should use the same path.
There was a problem hiding this comment.
Agreed. That makes me feel better about the hacky duplication of width.
| // So now we use an SVG. | ||
| // If Safari reforms, we should consider reverting to the glyph. | ||
| accent = buildCommon.staticSvg("vec", options); | ||
| accent.width = parseFloat(accent.style.width); |
There was a problem hiding this comment.
This is kind of hacky, but since it should disappear once we have non-combining \vec I'm okay with this.
src/buildHTML.js
Outdated
| let accentClass = null; | ||
| if (group.value.label === '\\H') { | ||
| accentClass = "accent-hungarian"; | ||
| left += 0.5; // width of space |
There was a problem hiding this comment.
I don't think this will work for all fonts, but since we're going to be adding non-combining double acute accents to all fonts soon it's okay to leave this as is for now.
There was a problem hiding this comment.
Also, I don't think this comment is correct as the width of a space is 250 (or thereabouts depending on the font).
There was a problem hiding this comment.
Ah, right, maybe it's double the width of a space. (I was copy/pasting the comment from the accent-hungarian CSS.) It might also be the width of the accent character, which is 0.5...
| // because we are centering the accent, so by adding 2*skew to the left, | ||
| // we shift it to the right by 1*skew. | ||
| accentBody.style.marginLeft = 2 * skew + "em"; | ||
| accentBody.style.left = left + "em"; |
There was a problem hiding this comment.
I found that change the left value in the browser didn't actually change the position of the accent body. It appears that .katex .accent>.vlist-t is the style that's actively centering accents. Maybe we don't need the glyph width after all.
There was a problem hiding this comment.
It's true that vlist is doing horizontal centering. That's how accents were able to work before. The catch is that we need to set the accent to zero width so that it doesn't affect the bounding box. When that happens, the left edge of the accent gets centered, and the accent itself extends to the right. Hence the need for the horizontal offset.
I do wonder whether there's a way to do this with CSS, without needing the width of the character...
|
@kevinbarabash Can you confirm whether I pushed a tweak to the comment. |
|
@edemaine let's deal with the non-combining |
|
@edemaine, You're correct. |
Make the width of an accented character equal to the width of the character, by making accents zero width. In particular, fixes #1028 (
\ddot\imath).This involved reworking all of the accent offset machinery, in particular skew and accent-hungarian. A bit cleaner now.
Also added support for the new width character metrics in symbolNode.
A bunch of screenshots involving skew correction have changed in an invisible way (diffs look entirely black and white). I assume this is a consequence of switching from
margin-lefttoleftas the mechanism for skew shift on accents.