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

Closed
opened this issue May 20, 2013 · 15 comments

Projects
None yet
2 participants

### nageh 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.
Member

### dpvc commented May 20, 2013

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

### nageh 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
Member

### dpvc 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   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.
Author

### nageh 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?
Member

### dpvc 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.
Author

### nageh 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.
Member

### dpvc commented May 25, 2013

 OK, try   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).
Author

### nageh 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".
Author

### nageh 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.
Member

### dpvc 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.
Author

### nageh 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).
Member

### dpvc 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).
Author

### nageh 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! :)
Member

### dpvc 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

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

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

 Merge branch 'issue476' into develop. Issue mathjax#476. 
 27c047a 

Member

### dpvc commented Feb 17, 2014

 => Merged.