Re: MathML Core Meeting on Monday April 24, 2023

Right, I stand corrected on many fronts. Ouch and sorry. Thanks for the 
excellent replies!

1. Yes, the severity comes from heights, not widths. To explain (not 
excuse) my mistake, I started with the stack overflow bug report 
(https://stackoverflow.com/questions/75621629/issue-with-mathml-rendering-of-matrix-like-formulas-in-chrome-for-both-on-mac-an) 
about heights, verified it on my computer, and found the chromium bug 
issue that already reported and verified it 
(https://bugs.chromium.org/p/chromium/issues/detail?id=1419746). These 
both focused on heights, not widths. Then I found Fred's note at 
https://bugs.chromium.org/p/chromium/issues/detail?id=1415218 and read 
it too quickly, relying on what I'd seen on my screen, the chromium bug 
report, and my knowledge of history.

2. I also followed Brian Kardell's link to your agenda, and read the 
agenda items without following them. To a poor developer like me, they 
looked like bug reports, not spec issues. In hindsight, I am an idiot.

3. Is it MathML Core policy that any web pages using it should download 
a math web font? Or is this a temporary problem? Is there a good web 
page explaining this (and recommending a solution) that I (jqMath) can 
link to? I suppose I could change jqMath to automatically download a 
math web font, but authors should be able to override the choice, and 
need to understand this issue, I think. My confusion, and the stack 
overflow issue and chromium bug report(!) which preceded it show that 
the web font requirement is a surprise, even to those of us that should 
know better.

Many thanks for your explanation. I do think this needs clarification to 
us unwashed masses, though.

Cheers, Dave B.

On 4/24/23 9:58 AM, Neil Soiffer wrote:
> Thanks for pointing that out. I believe you are correct that it is a 
> font issue. I remember seeing that during the beta. I think I brought 
> this up and Fred said it was bad info in the OpenType math table for 
> some fonts, but it is possible I'm misremembering.
>
> I was going to mention that the referenced bug report is really about 
> the width calculation for vertically stretched chars (height for 
> horizontal stretching), but that's not the rendering issue that was on 
> stack exchange so I didn't want to muddy the waters.
>
> @Dave Barton: if you use a web font, does this significantly lessen 
> the severity of the bug in your eyes? Or are you more concerned with 
> the chars crashing into each other. I tried a few cases and couldn't 
> see that problem, but I didn't try very hard.
>
>     Neil
>
>
> On Mon, Apr 24, 2023 at 3:36 AM David Carlisle <davidc@nag.co.uk> wrote:
>
>     On 24/04/2023 09:35, Neil Soiffer wrote:
>>     Dave,
>>
>>     Thanks for the reference. According to the chromium issue, Google
>>     is aware of this issue and has a long term plan to change how
>>     rendering works so the rendering will be correct. I suspect "long
>>     term" means "not this year." :-(
>>
>>     I just tried the example from the referenced stackoverflow
>>     link in Chrome 112.0.5615.138 and the brackets look good. Here's
>>     my codepen example <https://codepen.io/nms/pen/xxyqZPo>. Are you
>>     seeing a problem in Chrome with this example? In the bug report,
>>     I don't see mention of it being fixed so I don't know why it is
>>     working for me in 112.
>>
>>         Neil
>>
>     I see the stackoverflow issue (brackets not stretching at all) on
>     android with chrome 112 but not windows.  but I don't think that's
>     related to the reported chromium issue as that's about the width
>     of stretched characters. That doesn't apply to [] so much as [
>     doesn't get much wider as it gets taller. It's more of an issue for ()
>
>     Note the android issue as seen on stackexchange or your codepen
>     just seems to be the default font
>
>
>     https://fred-wang.github.io/MathFonts/mozilla_mathml_test/
>
>
>     brackets don't stretch but if you select (any)  web font option
>     from the dropdown at the top then they do.
>
>
>     But
>
>     > If you're going to discuss bugs in your agenda, I suggest you
>     include this one
>
>     Normally  in WG meetings we don't discuss implementation bugs.
>     Implementation bugs should be raised with the relevant bug trackers.
>
>
>     David
>
>
>
>
>     *Disclaimer*
>
>     The Numerical Algorithms Group Ltd is a company registered in
>     England and Wales with company number 1249803. The registered
>     office is: 30 St. Giles, Oxford, OX1 3LE, United Kingdom. Please
>     see our Privacy Notice
>     <https://www.nag.com/content/privacy-notice>for information on how
>     we process personal data and for details of how to stop or limit
>     communications from us.
>
>     This e-mail has been scanned for all viruses and malware by
>     Microsoft Exchange Online (EOP)
>