[lucida] Lucida OT equality symbol looks faint in Adobe Acrobat

[Bruno Voisin]

> On 13 Aug 2022, at 00:42, Karl Berry <karl at freefriends.org> wrote:
> 
> The math definition is apparently only drawing
> two lines (one by each callsubr), so the thickness of the line is
> presumably getting defined somewhere else. And that "somewhere else" is
> probably what Acrobat doesn't like.
> 
> The text definition is drawing four lines. Or is it drawing two lines on
> top of each other? I need to draw out the coordinates to see, but that's
> not going to happen.


After some looking and experimenting:


- It seems the default line thickness for the fonts is yStrikeoutSize (= thickness of the em dash) from the OS/2 table

	https://docs.microsoft.com/en-us/typography/opentype/spec/os2#ystrikeoutsize

which is meant to match underlineThickness from the POST table

	https://docs.microsoft.com/en-us/typography/opentype/spec/post#underlineThickness

Both are 50 for Lucida Bright Text and Math.


- In addition for Lucida Bright Math the MATH table includes four thicknesses

	FractionRuleThickness
	OverbarRuleThickness
	UnderbarRuleThickness
	RadicalRuleThickness

According to

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

these are recommended to match the default rule thickness defined as the thickness of "a minus sign, low line, or a similar font value such as OS/2.yStrikeoutSize".

For Lucida Bright Math the math rule thicknesses are 40.


- However, this difference between thicknesses doesn't seem to cause the Acrobat rendering problem. My impression is that only yStrikeoutSize/underlineThickness matters for the equal sign, with value 50.

First I thought maybe the 41 difference between the coordinates 230 and -271 (ignoring the sign for the latter) in the text font def

        <CharString name="equal">
          230 108 190 rmoveto
          -100 callsubr
          163 vmoveto
          -100 callsubr
          -271 vmoveto
          -100 callsubr
          163 vmoveto
          -100 callsubr
          endchar
        </CharString>

was related to the 40 math rule thickness in some way. So I changed these coordinate values, to no effect, the problem was still there.

Eventually I removed the instructions for drawing the last two lines in LucidaBrightOT, keeping

        <CharString name="equal">
          230 108 190 rmoveto
          -100 callsubr
          163 vmoveto
          -100 callsubr
          endchar
        </CharString>

similar to the instructions already in LucidaBrightMathOT

        <CharString name="equal">
          108 190 rmoveto
          -100 callsubr
          163 vmoveto
          -100 callsubr
          endchar
        </CharString>

That seems to solve the problem: in Acrobat at zoom factor 210% and below, the equal sign looks just fine. And it is identical to the equal glyph from the math font (as far as I can see), which seems to imply the default rule thickness 50 is used.

The initial 230 seems to actually have no effect. I thought maybe this positioned the glyph vertically such that, in a line mixing text and math, the equal sign is placed correctly with respect to the math axis. But no, changing 230 to something else doesn't seem to alter the glyph.


Attached are the outputs for Kai's test file with the original LucidaBrightOT.otf and the modified one, together with Acrobat's renderings at 200% and 400% on my Mac setup.

To be clear: in all these tests, I used ttx from the Python FontTools to convert LucidaBrightOT.otf into its text representation in TTX format, edited this TTX file and used ttx to convert it back to OTF format.

That's as far as I went. I won't be able to pursue the matter.

Bruno Voisin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-lucida-after.pdf
Type: application/pdf
Size: 6020 bytes
Desc: not available
URL: <https://tug.org/pipermail/lucida/attachments/20220815/50906383/attachment-0002.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-lucida-before.pdf
Type: application/pdf
Size: 6027 bytes
Desc: not available
URL: <https://tug.org/pipermail/lucida/attachments/20220815/50906383/attachment-0003.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Acrobat-200%.png
Type: image/png
Size: 427923 bytes
Desc: not available
URL: <https://tug.org/pipermail/lucida/attachments/20220815/50906383/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Acrobat-400%.png
Type: image/png
Size: 443182 bytes
Desc: not available
URL: <https://tug.org/pipermail/lucida/attachments/20220815/50906383/attachment-0003.png>
-------------- next part --------------