Re: MathML Core Meeting: cancelled for 20/4/20

Hi,

Sorry, I forgot to reply to this.

This is for the same reason explained last November: patches increasing
significantly Android binary size will be very hard to get approved.
Current MathML3 operator dictionary size (counting single-char only) is
6935bytes and although the total is probably less than Chromium's hard
limit for an alarm (16kb), it would be *very* bad to submit a patch with
the raw table of ~1500 entries and no optimization at all.

Writing a script to generate a specific form of the tables is not a big
deal, I had already written one last November and was expecting that it
would help David and you for the dictionary updates... The point is that
the actual optimization and size will depend on the final values of the
dictionary. The compression is based on redundancy but there are still
many edge cases that are causing size increase and it's not clear
whether these cases can be removed (not essential), or can be merged
into an existing category (mistakes or inconsistency) or are really
fundamental (deserves special treatment). See github issues #176 #143
#209 for details.

Finally, any update has a cost so I disagree with you on your "update
should be easy": not only we need to regenerate the tables in the spec,
but also the WPT tests & associate WOFF font, then we need to
synchronize all the tests in WebKit/Chromium/Gecko, and get patches
reviewed for all these operator dictionaries updates, dealing with any
test failures/updates. So although in principle I agree with you that we
should be ready to update the table in the future, I expect that it is
not going to happen so frequently and that any change will preserve the
decided existing categories (i.e. we are not going to add new fancy
operators with bizarre spacing and properties) and so won't change
fundamentally the optimization logic and implementation.

Given that we are about to upstream operator code to Chromium, I think
the solution to unblock this will be to perform the synchronization of
tests based on

https://mathml-refresh.github.io/mathml-core/#operator-dictionary-compact

maybe with a few more updates and excluding edge cases ; and we will
then ignore any future update in the short term.

Thanks,

-- 
Frédéric Wang

On 23/04/2020 20:20, Neil Soiffer wrote:
> I'm confused as to why updating the values in the operator dictionary
> is blocking you. Given that the table is large (and hence likely to
> change because bugs will exist in it just as bugs exist in code) and
> that Unicode comes out with updates at least once a year, any
> implementation needs to be able to be able to easily update it's
> tables, so working with the current values should be acceptable. I've
> cc'd David in case the problem is that some specific form of the table
> needs to be generated that is not currently generated.
>
>     Neil
>
>
> On Wed, Apr 22, 2020 at 9:02 AM Frédéric Wang <fwang@igalia.com
> <mailto:fwang@igalia.com>> wrote:
>
>     On 20/04/2020 06:37, Neil Soiffer wrote:
>>     The pressing issues to discuss are ones that were raised by
>>     Frédéric. He said he can't make the meeting on Monday, so there
>>     won't be a meeting on Monday. Hopefully he can make it the
>>     following week
>>
>>     If someone wants to add items to an agenda for the 27th, please
>>     do so by editing the agenda at
>>     https://github.com/mathml-refresh/mathml/issues/8#issuecomment-616303323.
>>
>>     For those planning on attending, enjoy your unplanned extra hour
>>     this week :-)
>>
>>         Neil
>>
>>
>>     <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
>>      Virus-free. www.avg.com
>>     <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
>>
>>
>     I removed my pending items, I think the highest priority right now
>     is having the compact operator dictionary as this is already
>     blocking us to implement movablelimits for example ; or to do
>     refactoring in Gecko / WebKit or to update tests. Updating the CSS
>     proposal (in particular with fantasai's suggestion) is also
>     important but we need more time to review that with Rob ; so it
>     probably does not make sense to discuss it again for now. Finally,
>     several layout improvements (operators, etc) will probably depend
>     on future feedback from Google reviewers, so not sure the CG can
>     decide for now.
>
>     -- 
>     Frédéric Wang
>