8

In the answers to this question, I learned that OpenType Math fonts like Cambria and Latin Modern Math contain script-size and script-script-size characters, with different optical scaling. In my documents, I see that the script-script-size ones (with .sts names) are being used for subscripts. This is surprising -- I was expecting that the script-size ones would be used (the ones with .st names). The effect is not very noticeable, because the vertical sizes of the subscript characters are as I would expect -- roughly 7 pt for a document that uses 10 pt as the basic text size.

enter image description here

In short, I was expecting to get the result on the right, and I'm getting the result on the left (in both displayed and in-line math). Is this to be expected? If it is, then what are the script-size glyphs used for ??

Edit
This seems to be related to the use of Unicode-Math.

% Compile using XeLateX
\documentclass{article}
\usepackage{unicode-math}
\begin{document}
\[
x_2 = 2
\]
\end{document}

Removing the third line of code gives the result I'd expect -- the "two.st" glyph is used.

Reported as a bug on github.

Community
  • 1
bubba
  • 2,462
  • 2
    I am getting the same error and I would call it as such. Please report this here: https://github.com/wspr/unicode-math/issues?q=is%3Aopen+is%3Aissue Chapter 4.2 of the documentation says that those fonts should get selected by default. Off topic: Please do not use $$! – LaRiFaRi Jan 06 '15 at 08:28
  • I don't understand this stuff at all, so I don't know if it's an error or not. I somewhat like it, actually. I'll report it as a bug if that's the consensus. Let's wait a while, first, though. – bubba Jan 06 '15 at 09:41

1 Answers1

5

Ah, thanks very much for spotting this! The reason this occurs is two-fold.

Firstly, when loading a maths font, unicode-math queries it to establish the sizes it should define for script and scriptscript sizes. After doing this, it needs to re-load the font with these new sizes, and that wasn't happening. (I don't know if this was actually a problem in practise, but it's been fixed.)

Secondly, and more importantly, TeX is notorious for its mathematics ability, and after reading in the appropriate values it needed to do some rescaling for the main font size. This was being done poorly, resulting in a value of 6.99997pt instead of 7pt. Because the font was defined to switch from script to scriptscript below 7pt, this triggered the result you show above.

I've now re-implemented this using expl3's floating point mathematics engine; for those curious this has changed 

\cs_set:Nn \@@_fontdimen_to_percent:nn
 { \strip@pt\dimexpr\fontdimen#1#2*65536/100\relax }
\cs_set:Nn \@@_fontdimen_to_scale:nn
 { \@@_fontdimen_to_percent:nn {#1} {#2} \dimexpr \f@size pt\relax }

to

\cs_new:Nn \@@_fontdimen_to_percent:nn
 { \fp_eval:n { \strip@pt\fontdimen#1#2 * 65536 / 100 } }
\cs_new:Nn \@@_fontdimen_to_scale:nn
 { \fp_eval:n {\@@_fontdimen_to_percent:nn {#1} {#2} * \f@size } pt }

Now! Something I hope doesn't become a problem: this new method produces a size of 7.01236pt (for Latin Modern Math, TL2015). I would have expected 7pt, so I hope there isn't something else in here that might trip us up later.

Another way to solve this problem would be to avoid defining the font change at the boundaries, but rather in their middles. E.g. if the font says that SS-size is 5pt and S-size is 7pt for a 10pt font, it would kind of make more sense to define the font as something like:

6pt and below : script script size font
6pt - 8.5pt   : script size font
8.5pt and up  : regular size font

I might investigate this solution instead if the issue you've raised re-occurs in similar form in the future.

Will Robertson
  • 73,872
  • 1
    Thanks for the fix. I make my living doing floating-point computations, and I'd say that using any number close to 7 as the "test" value is asking for trouble. Your suggestion in "another way " sound much safer, to me. – bubba Jul 31 '15 at 04:39
  • @bubba — the main reason I haven't implemented this straight away (besides laziness) is that I'm aware there are larger problems surrounding the way that the script sizes are calculated; namely, that these are frozen for the text size, and so writing \Huge$x^a_b$ will have a and b in "regular size glyphs" but scaled up. I'm not sure if this is appropriate or not, but deserves finer consideration… – Will Robertson Jul 31 '15 at 07:03