[lucida] incompatible sizes of arrows (uparrow and downarrow)

[Bruno Voisin]

Hi Michael,

For texmf-cache and the .tma and .tmd files, I assume these are all ConTeXt-specific. (I'm not a ConTeXt user myself.)

> Regarding the measures you give. Yes, the base glyphs do have the same
> measures. It is when we use the parts to make vertical extensibles
> that we seem to get different numbers (the "advance", "start" and
> "end" in the vparts). I never used the lucida t1 math, so I don't know
> if it has these extensible arrows. I'm sorry if I was not clear
> enough.

Thanks, I understand now: your code triggers the construction of extensible arrows. I hadn't got that earlier, sorry.

Trying the same in LaTeX, I can't get the same result (see attached lucida-advance-test.tex). Maybe it depends on the default font size in your document (10 pt or 9.5 pt, for example), such that for you $P^{\uparrow}$ is just below the threshold for triggering the construction of an extensible delimiter for downarrow, and just above it for uparrow.

What's odd is that opening the PDF output in Illustrator, the up and down arrow heads seem indeed to enter by different amounts "inside" the box for the vertical line part of the arrows. But this isn't visible when viewing lucida-advance-test.pdf in a PDF viewer.

Regarding the T1 fonts, there are indeed extensible arrows in lbme. They seem constructed from arrowvertex (the vertical line, vsize 570) and arrowtp and arrowbt (the top and bottom heads, both vsize 550).

An aside: attached are the plain TeX support file lcdplain.tex and a test file torture.tex displaying all the predefined delimiter sizes from big to Biggg (among many other things). I haven't tried to combine torture.tex with Hans' luatex-math.tex to do the same for the OpenType fonts.

But this (looking at the glyphs as I did) was a dead end. Sorry for that. The problem for the OpenType fonts turns out to come from the MathGlyphConstruction table

https://docs.microsoft.com/en-us/typography/opentype/spec/math#mathglyphconstruction-table

defining how the glyphs are combined to form the extensible delimiters.

Applying ttx to LucidaBrightMathOT.otf, there's first

      <VertGlyphCoverage>
        [11 entries]
        <Glyph value="arrowup"/>
        <Glyph value="arrowdown"/>
        [more entries]
      </VertGlyphCoverage>

which associates the extensible up and down arrows with indices (starting from 0) 11 and 12 in the MathGlyphConstruction table, and then

     <VertGlyphConstruction index="11">
        <GlyphAssembly>
          <ItalicsCorrection>
            <Value value="0"/>
          </ItalicsCorrection>
          <!-- PartCount=2 -->
          <PartRecords index="0">
            <glyph value="arrowvertex"/>
            <StartConnectorLength value="190"/>
            <EndConnectorLength value="190"/>
            <FullAdvance value="570"/>
            <PartFlags value="1"/>
          </PartRecords>
          <PartRecords index="1">
            <glyph value="arrowup"/>
            <StartConnectorLength value="212"/>
            <EndConnectorLength value="212"/>
            <FullAdvance value="637"/>
            <PartFlags value="0"/>
          </PartRecords>
        </GlyphAssembly>
        <!-- VariantCount=1 -->
        <MathGlyphVariantRecord index="0">
          <VariantGlyph value="arrowup"/>
          <AdvanceMeasurement value="784"/>
        </MathGlyphVariantRecord>
      </VertGlyphConstruction>

      <VertGlyphConstruction index="12">
        <GlyphAssembly>
          <ItalicsCorrection>
            <Value value="0"/>
          </ItalicsCorrection>
          <!-- PartCount=2 -->
          <PartRecords index="0">
            <glyph value="arrowdown"/>
            <StartConnectorLength value="210"/>
            <EndConnectorLength value="210"/>
            <FullAdvance value="630"/>
            <PartFlags value="0"/>
          </PartRecords>
          <PartRecords index="1">
            <glyph value="arrowvertex"/>
            <StartConnectorLength value="190"/>
            <EndConnectorLength value="190"/>
            <FullAdvance value="570"/>
            <PartFlags value="1"/>
          </PartRecords>
        </GlyphAssembly>
        <!-- VariantCount=1 -->
        <MathGlyphVariantRecord index="0">
          <VariantGlyph value="arrowdown"/>
          <AdvanceMeasurement value="784"/>
        </MathGlyphVariantRecord>
      </VertGlyphConstruction>

That's where the advance, start and end values you reported seem to come from. Indeed, the advance values are 637 for arrowup and 630 for arrowdown. I've no idea how these values are calculated, which one is right, or even what FullAdvance exactly means.

Other than the above link from the OpenType spec, the only other web page I found on FullAdvance is the MathML spec (of which David Carlisle, of LaTeX fame, is an editor)

https://www.w3.org/TR/mathml-core/#the-glyphassembly-table

Bruno

-------------- next part --------------
A non-text attachment was scrubbed...
Name: lcdplain.tex
Type: application/octet-stream
Size: 18373 bytes
Desc: not available
URL: <https://tug.org/pipermail/lucida/attachments/20220817/240154d2/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: torture.pdf
Type: application/pdf
Size: 138500 bytes
Desc: not available
URL: <https://tug.org/pipermail/lucida/attachments/20220817/240154d2/attachment-0002.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: torture.tex
Type: application/octet-stream
Size: 22393 bytes
Desc: not available
URL: <https://tug.org/pipermail/lucida/attachments/20220817/240154d2/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lucida-advance-test.pdf
Type: application/pdf
Size: 3703 bytes
Desc: not available
URL: <https://tug.org/pipermail/lucida/attachments/20220817/240154d2/attachment-0003.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lucida-advance-test.tex
Type: application/octet-stream
Size: 317 bytes
Desc: not available
URL: <https://tug.org/pipermail/lucida/attachments/20220817/240154d2/attachment-0005.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot 2022-08-17 at 17.51.22.png
Type: image/png
Size: 86384 bytes
Desc: not available
URL: <https://tug.org/pipermail/lucida/attachments/20220817/240154d2/attachment-0001.png>
-------------- next part --------------