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

big \Up/Downarrows don't look nice #476

Closed
nageh opened this issue May 20, 2013 · 15 comments

Comments

Projects
None yet
2 participants
@nageh
Copy link

commented May 20, 2013

Modifying \Downarrow, \Uparrow and \Updownarrow with \big, \Big, \bigg or \Bigg results in a very stitched appearance on Chrome. Looks better on Firefox but not perfect either. Appearance improves with larger font sizes.

@dpvc

This comment has been minimized.

Copy link
Member

commented May 20, 2013

Can you provide a screen shot? They look fine for me. What OS are you working on?

@nageh

This comment has been minimized.

Copy link
Author

commented May 25, 2013

Sure. Captured on Chrome 27 and Firefox 21, Windows 7, using STIX fonts, from http://en.wikipedia.org/wiki/Help:Latex

mathjax2 2-bigarrows_chrome27-windows7
mathjax2 2-bigarrows_firefox21-windows7

@dpvc

This comment has been minimized.

Copy link
Member

commented May 25, 2013

OK, here's the issue. There is no standard unicode character for a double-arrow extender, so MathJax has to use something else for that. In the STIX fonts, there is a character in the PUA that is marked as "stix-extender for vertical double arrow", but it does not match up with the double arrows (its horizontal position is off). So MathJax has to do a horizontal adjustment to the character in order to get it to line up. How well this shifting works depends on the font size, and it looks like the shift may be slightly too much. The current shift is .1em, but it probably should be more like .085em. (The results are slightly less noticeable with the anti-aliasing in the lower images.)

If you want to try out a different value, you could use

<script type="text/x-mathjax-config">
MathJax.Hub.Register.LoadHook("[MathJax]/jax/output/HTML-CSS/fonts/STIX/fontdata.js",function () {
  var DELIMITERS = MathJax.OutputJax["HTML-CSS"].FONTDATA.DELIMITERS;
  DELIMITERS[0x21D1].stretch.ext[2] = .085;
  DELIMITERS[0x21D3].stretch.ext[2] = .085;
  DELIMITERS[0x21D5].stretch.ext[2] = .085;
});
</script>

and see if that looks better to you. Unfortunately, what works best in one font size may not work as well in other font sizes, so you may need to test in several different situations, and with several browsers, on several operating systems. Welcome to my world.

@nageh

This comment has been minimized.

Copy link
Author

commented May 25, 2013

Yeah, cross-system compatibility is quite a b*tch.

The issue here seems not to be the horizontal adjustment though. The extension symbol is definitely too slim to match the arrow width no matter the horizontal position. Can I actually stretch the extension symbol?

@dpvc

This comment has been minimized.

Copy link
Member

commented May 25, 2013

I have checked the fonts, and the two characters have the same size and placement of their vertical pieces, it is only the horizontal position that differs. I suspect that what you are seeing as a difference in width is an artifact of the outlines-to-pixels conversion, and that this is dependent on the positioning of the character with respect to the pixel grid, so that if we get the position right, the width will also be taken care of. Did you try out my suggestion of the horizontal positioning change? I think that is the best thing to try. Changing the width will only make it not work in other situations, as the space between the verticals in the font are the same in both glyphs, so you really don't want to change that.

@nageh

This comment has been minimized.

Copy link
Author

commented May 25, 2013

Well, I was asking because whatever horizontal adjustment I take the extension always appears too narrow. So, using a factor of .922 makes the right line to be too much on the inside, whereas a factor of .923 moves the left line too much on the inside.

@dpvc

This comment has been minimized.

Copy link
Member

commented May 25, 2013

OK, try

<script type="text/x-mathjax-config">
MathJax.Hub.Register.LoadHook("[MathJax]/jax/output/HTML-CSS/fonts/STIX/fontdata.js",function () {
  var DELIMITERS = MathJax.OutputJax["HTML-CSS"].FONTDATA.DELIMITERS;
  DELIMITERS[0x21D1].stretch.ext[0] = 0xE10E;
  DELIMITERS[0x21D3].stretch.ext[0] = 0xE10E;
  DELIMITERS[0x21D5].stretch.ext[0] = 0xE10E;
  DELIMITERS[0x21D1].stretch.ext[1] = "STIXNonUnicode";
  DELIMITERS[0x21D3].stretch.ext[1] = "STIXNonUnicode";
  DELIMITERS[0x21D5].stretch.ext[1] = "STIXNonUnicode";
  DELIMITERS[0x21D1].stretch.ext[2] = .017;
  DELIMITERS[0x21D3].stretch.ext[2] = .017;
  DELIMITERS[0x21D5].stretch.ext[2] = .017;
});
</script>

and see if that is any better. (Note, I had left out the 0 in my decimals, it should have been .085 not .85, but I assume you caught that).

@nageh

This comment has been minimized.

Copy link
Author

commented May 25, 2013

Yep, caught that zero (and missed it myself in my posting).

That example gives a [Math Processing Error]. Firebug tells me that the initial values of ext[1] are "STIXGeneral".

@nageh

This comment has been minimized.

Copy link
Author

commented May 25, 2013

Ok, I think we should declare this a browser font rendering issue/bug. A 125% zoom results in a too large horizontal adjustment for the first double arrow, whereas a 150% zoom shows a too small horizontal adjustment for the third arrow.

@dpvc

This comment has been minimized.

Copy link
Member

commented May 25, 2013

OOPS, my fault, it should have been ext[0] not ext[1] (that's what comes from doing it by memory without checking).

The issues you are seeing with the different zoom values are what I was afraid of. It is hard to get these to work at all font sizes, and it usually isn't worth trying to fine tune it, as it just doesn't work universally. Close most of the time is about as good as it gets, I'm afraid.

@nageh

This comment has been minimized.

Copy link
Author

commented May 25, 2013

I see that that changed the character glyph to 0xe10e, but that glyph doesn't exist (Chrome displays no extensions whereas Firefox shows those familiar missing glyph boxes).

Btw, horizontal adjustment is indeed also an issue for both Chrome and Firefox, though to a much lesser degree. A horizontal adjustment of 0.079 (instead of 0.1) worked pretty well on both browsers and at all zoom levels (though of course the extension glyphs still appear too narrow on Chrome).

@dpvc

This comment has been minimized.

Copy link
Member

commented May 25, 2013

Argh! My fault again. You have to change the STIXGeneral to STIXNonUnicode as well. I've edited the code above.

Your value of .079 is probably a good choice. The actual difference in the two glyph positions is .081. I had recommended .085 since .081 ended up making them too far to the left in MacOS (where I do most of my testing).

@nageh

This comment has been minimized.

Copy link
Author

commented May 25, 2013

Uh! That shows that it is clearly an issue with Chrome. One time it's too narrow, then too wide, and always off-positioned. In comparison, Firefox renders it (almost) perfectly.

I think we should stick with the old symbol, and maybe choose a default horizontal adjustment somewhere between 0.079 and 0.085.

Thanks for trying! :)

@dpvc

This comment has been minimized.

Copy link
Member

commented May 25, 2013

Yes, I was planning to fix the adjustment amount, which is why I'm leaving the issue tracker open (so I'll see it and take care of it in the next release).

dpvc pushed a commit to dpvc/MathJax that referenced this issue Feb 15, 2014

Davide P. Cervone
Adjust positions of extenders for double-lined vertical arrows. (The …
…horizontal position of the extender is off in teh fonts.) Resolves issue mathjax#476.

dpvc pushed a commit to dpvc/MathJax that referenced this issue Feb 17, 2014

@dpvc dpvc added Merged and removed Ready for Review labels Feb 17, 2014

@dpvc

This comment has been minimized.

Copy link
Member

commented Feb 17, 2014

=> Merged.

@dpvc dpvc closed this Feb 17, 2014

@dpvc dpvc added v2.4 and removed Merged labels Jun 30, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.