Frédéric Wang Subscribe   About   Mathematics   Computer Science   Miscellaneous   Archive

Update on OpenType MATH fonts

I mentioned in a previous post that Igalia organized the Web Engines Hackfest 2022 last week. As usual, fonts were one of the topic discussed. Dominik Röttsches presented COLRv1 color vector fonts in Chrome and OSS (transcript) and we also settled a breakout session on Tuesday morning. Because one issue raised was the availability of OpenType MATH fonts on operating systems, I believe it’s worth giving an update on the latest status…

There are only a few fonts with an OpenType MATH table. Such fonts can be used for math layout e.g. modern TeX engines to render LaTeX, Microsoft Office to render OMML or Web engines to render MathML. Three of such fonts are interesting to consider, so I’m providing a quick overview together with screenshots generated by XeTeX from the LaTeX formula $${\sqrt{\sum_{n=1}^\infty {\frac{10}{n^4}}}} = {\int_0^\infty \frac{2x dx}{e^x-1}} = \frac{\pi^2}{3} \in {\mathbb R}$$:

Recently, Igalia has been in touch with Myles C. Maxfield who has helped with internal discussion at Apple regarding inclusion of STIX Two Math in the list of fonts on macOS. Last week he came back to us announcing it’s now the case on all the betas of macOS 13 Ventura 🎉 ! I just tested it this morning and indeed STIX Two Math is now showing up as expected in the Font Book. Here is the rendering of the last slide of my hackfest presentation in Safari 16.0:

Screenshot of a math formula rendered with STIX Two Math by Safari

Obviously, this is a good news for Chromium and Firefox too. For the former, we are preparing our MathML intent-to-ship and having decent rendering on macOS by default is important. As for the latter, we could in the future finally get rid of hardcoded tables to support the deprecated STIXGeneral set.

Another interesting platform to consider for Chromium is Android. Last week, there has been new activity on the Noto fonts bug and answers seem more encouraging now… So let’s hope we can get a proper math font on Android soon!

Finally, I’m not exactly sure about the situation on Linux and it may be different for the various distributions. STIX and Latin Modern should generally be available as system packages that can be easily installed. It would be nicer if they were pre-installed by default though…

Short blog post from Madrid's hotel room

This week, I finally went back to A Coruña for the Web Engines Hackfest and internal company meetings. These were my first on-site events since the COVID-19 pandemic. After two years of non-super-exciting virtual conferences I was so glad to finally be able to meet with colleagues and other people from the Web.

Igalia has grown considerably and I finally get to know many new hires in person. Obviously, some people were still not able to travel despite the effort we put to settle strong sanitary measures. Nevertheless, our infrastructure has also improved a lot and we were able to provide remote communication during these events, in order to give people a chance to attend and participate !

Work on the Madrid–Galicia high-speed rail line finally completed last December, meaning one can now travel with fast trains between Paris - Barcelona - Madrid - A Coruña. This takes about one day and a half though and, because I’m voting for the Legislative elections in France, I had to shorten a bit my stay and miss nice social activities 😥… That’s a pity, but I’m looking forward to participating more next time!

Finally on the technical side, my main contribution was to present our upcoming plan to ship MathML in Chromium. The summary is that we are happy with this first implementation and will send the intent-to-ship next week. There are minor issues to address, but the consensus from the conversations we had with other attendees (including folks from Google and Mozilla) is that they should not be a blocker and can be refined depending on the feedback from API owners. So let’s do it and see what happens…

There is definitely a lot more to write and nice pictures to share, but it’s starting to be late here and I have a train back to Paris tomorrow. 😉

Igalia's contribution to the Mozilla project and Open Prioritization

As many web platform developer and Firefox users, I believe Mozilla’s mission is instrumental for a better Internet. In a recent Igalia’s chat about the Web Ecosystem Health, participants made the usual observation regarding this important role played by Mozilla on the one hand and the limited development resources and small Firefox’s usage share on the other hand. In this blog post, I’d like to explain an experimental idea we are launching at Igalia to try and make browser development better match the interest of the web developer and user community.

Open Prioritization by Igalia. An experiment in crowd-funding prioritization.

Igalia’s contribution to browser repositories

As mentioned in the past in this blog, Igalia has contributed to different part of Firefox such as multimedia (e.g. <video> support), layout (e.g. Stylo, WebRender, CSS, MathML), scripts (e.g. BigInt, WebAssembly) or accessibility (e.g. ARIA). But is it enough?

Although commit count is an imperfect metric it is also one of the easiest to obtain. Let’s take a look at how Igalia’s commits repositories of the Chromium (chromium, v8), Mozilla (mozilla-central, servo, servo-web-render) and WebKit projects were distributed last year:

pie chart
Diagram showing, the distribution of Igalia's contributions to browser repositories in 2019 (~5200 commits). Chromium (~73%), Mozilla (~4%) and WebKit (~23%).

As you can see, in absolute value Igalia contributed roughly 3/4 to Chromium, 1/4 to WebKit, with a small remaining amount to Mozilla. This is not surprising since Igalia is a consulting company and our work depends on the importance of browsers in the market where Chromium dominates and WebKit is also quite good for iOS devices and embedded systems.

This suggests a different way to measure our contribution by considering, for each project, the percentage relative to the total amount of commits:

Bar graph
Diagram showing, for each project, the percentage of Igalia's commits in 2019 relative to the total amount of the project. From left to right: Chromium (~3.96%), Mozilla (~0.43%) and WebKit (~10.92%).

In the WebKit project, where ~80% of the contributions were made by Apple, Igalia was second with ~10% of the total. In the Chromium project, the huge Google team made more than 90% of the contributions and many more companies are involved, but Igalia was second with about 4% of the total. In the Mozilla project, Mozilla is also doing ~90% of the contributions but Igalia only had ~0.5% of the total. Interestingly, the second contributing organization was… the community of unindentified addresses! Of course, this shows the importance of volunteers in the Mozilla project where a great effort is done to encourage participation.

Open Prioritization

From the commit count, it’s clear Igalia is not contributing as much to the Mozilla project as to Chromium or WebKit projects. But this is expected and is just reflecting the priority set by large companies. The solid base of Firefox users as well as the large amount of volunteer contributors show that the Mozilla project is nevertheless still attractive for many people. Could we turn this into browser development that is not funded by advertising or selling devices?

Another related question is whether the internet can really be shaped by the global community as defended by the Mozilla’s mission? Is the web doomed to be controlled by big corporations doing technology’s “evangelism” or lobbying at standardization committees? Are there prioritization issues that can be addressed by moving to a more collective decision process?

At Igalia, we internally try and follow a more democratic organization and, at our level, intend to make the world a better place. Today, we are launching a new Open Prioritization experiment to verify whether crowdfunding could be a way to influence how browser development is prioritized. Below is a short (5 min) introductory video:

I strongly recommend you to take a look at the proposed projects and read the FAQ to understand how this is going to work. But remember this is an experiment so we are starting with a few ideas that we selected and tasks that are relatively small. We know there are tons of user reports in bug trackers and suggestions of standards, but we are not going to solve everything in one day !

If the process is successful, we can consider generalizing this approach, but we need to test it first, check what works and what doesn’t, consider whether it is worth pursuing, analyze how it can be improved, etc

Two Crowdfunding Tasks for Firefox

CIELAB color space*
Representation of the CIELAB color space (top view) by Holger Everding, under CC-SA 4.0.

As explained in the previous paragraph, we are starting with small tasks. For Firefox, we selected the following ones:

  • CSS lab() colors. This is about giving web developers a way to express colors using the CIELAB color space which approximates better the human perception. My colleague Brian Kardell wrote a blog with more details. Some investigations have been made by Apple and Google. Let’s see what we can do for Firefox !

  • SVG path d attribute. This is about expressing SVG path using the corresponding CSS syntax for example <path style="d: path('M0,0 L10,10,...')">. This will likely involve a refactoring to use the same parser for both SVG and CSS paths. It’s a small feature but part of a more general convergence effort between SVG and CSS that Igalia has been involved in.


Is this crowd-funded experiment going to work? Can this approach solve the prioritization problems or at least help a bit? How can we improve that idea in the future?…

There are many open questions but we will only be able to answer them if we have enough people participating. I’ll personally pledge for the two Firefox projects and I invite you to at least take a look and decide whether there is something there that is interesting for you. Let’s try and see!

Contributions to Web Platform Interoperability (First Half of 2020)

Note: This blog post was co-authored by AMP and Igalia teams.

Web developers continue to face challenges with web interoperability issues and a lack of implementation of important features. As an open-source project, the AMP Project can help represent developers and aid in addressing these challenges. In the last few years, we have partnered with Igalia to collaborate on helping advance predictability and interoperability among browsers. Standards and the degree of interoperability that we want can be a long process. New features frequently require experimentation to get things rolling, course corrections along the way and then, ultimately as more implementations and users begin exploring the space, doing really interesting things and finding issues at the edges we continue to advance interoperability.

Both AMP and Igalia are very pleased to have been able to play important roles at all stages of this process and help drive things forward. During the first half of this year, here’s what we’ve been up to…

Default Aspect Ratio of Images

In our previous blog post we mentioned our experiment to implement the intrinsic size attribute in WebKit. Although this was a useful prototype for standardization discussions, at the end there was a consensus to switch to an alternative approach. This new approach addresses the same use case without the need of a new attribute. The idea is pretty simple: use specified width and height attributes of an image to determine the default aspect ratio. If additional CSS is used e.g. “width: 100%; height: auto;”, browsers can then compute the final size of the image, without waiting for it to be downloaded. This avoids any relayout that could cause bad user experience. This was implemented in Firefox and Chromium and we did the same in WebKit. We implemented this under a flag which is currently on by default in Safari Tech Preview and the latest iOS 14 beta.


We continued our efforts to enhance scroll features. In WebKit, we began with scroll-behavior, which provides the ability to do smooth scrolling. Based on our previous patch, it has landed and is guarded by an experimental flag “CSSOM View Smooth Scrolling” which is disabled by default. Smooth scrolling currently has a generic platform-independent implementation controlled by a timer in the web process, and we continue working on a more efficient alternative relying on the native iOS UI interfaces to perform scrolling.

We have also started to work on overscroll and overscroll customization, especially for the scrollend event. The scrollend event, as you might expect, is fired when the scroll is finished, but it lacked interoperability and required some additional tests. We added web platform tests for programmatic scroll and user scroll including scrollbar, dragging selection and keyboard scrolling. With these in place, we are now working on a patch in WebKit which supports scrollend for programmatic scroll and Mac user scroll.

On the Chrome side, we continue working on the standard scroll values in non-default writing modes. This is an interesting set of challenges surrounding the scroll API and how it works with writing modes which was previously not entirely interoperable or well defined. Gaining interoperability requires changes, and we have to be sure that those changes are safe. Our current changes are implemented and guarded by a runtime flag “CSSOM View Scroll Coordinates”. With the help of Google engineers, we are trying to collect user data to decide whether it is safe to enable it by default.

Another minor interoperability fix that we were involved in was to ensure that the scrolling attribute of frames recognizes values “noscroll” or “off”. That was already the case in Firefox and this is now the case in Chromium and WebKit too.

Intersection and Resize Observers

As mentioned in our previous blog post, we drove the implementation of IntersectionObserver (enabled in iOS 12.2) and ResizeObserver (enabled in iOS 14 beta) in WebKit. We have made a few enhancements to these useful developer APIs this year.

Users reported difficulties with observe root of inner iframe and the specification was modified to accept an explicit document as a root parameter. This was implemented in Chromium and we implemented the same change in WebKit and Firefox. It is currently available Safari Tech Preview, iOS 14 beta and Firefox 75.

A bug was also reported with ResizeObserver incorrectly computing size for non-default zoom levels, which was in particular causing a bug on twitter feeds. We landed a patch last April and the fix is available in the latest Safari Tech Preview and iOS 14 beta.

Resource Loading

Another thing that we have been concerned with is how we can give more control and power to authors to more effectively tell the browser how to manage the loading of resources and improve performance.

The work that we started in 2019 on lazy loading has matured a lot along with the specification.

The lazy image loading implementation in WebKit therefore passes the related WPT tests and is functional and comparable to the Firefox and Chrome implementations. However, as you might expect, as we compare uses and implementation notes it becomes apparent that determining the moment when the lazy image load should start is not defined well enough. Before this can be enabled in releases some more work has to be done on improving that. The related frame lazy loading work has not started yet since the specification is not in place.

We also added an implementation for stale-while-revalidate. The stale-while-revalidate Cache-Control directive allows a grace period in which the browser is permitted to serve a stale asset while the browser is checking for a newer version. This is useful for non-critical resources where some degree of staleness is acceptable, like fonts. The feature has been enabled recently in WebKit trunk, but it is still disabled in the latest iOS 14 beta.

Contributions were made to improve prefetching in WebKit taking into account its cache partitioning mechanism. Before this work can be enabled some more patches have to be landed and possibly specified (for example, prenavigate) in more detail. Finally, various general Fetch improvements have been done, improving the fetch WPT score. Examples are:

What’s next

There is still a lot to do in scrolling and resource loading improvements and we will continue to focus on the features mentioned such as scrollend event, overscroll behavior and scroll behavior, lazy loading, stale-while-revalidate and prefetching.

As a continuation of the work done for aspect ratio calculation of images, we will consider the more general CSS aspect-ratio property. Performance metrics such as the ones provided by the Web Vitals project is also critical for web developers to ensure that their websites provide a good user experience and we are willing to investigate support for these in Safari.

We love doing this work to improve the platform and we’re happy to be able to collaborate in ways that contribute to bettering the web commons for all of us.

Transcendental number from the oscillating zeno's paradox

Oscillating Zeno’s paradox

In a previous blog post, I described an oscillating Zeno’s paradox, which can be formalized as follows. Atalanta moves on the real line. She leaves from 0 and at step nn she decides to move forward or backward by 12n+1\frac{1}{2^{n+1}}. If ϵn{1,1}\epsilon_n \in {\{-1, 1\}} corresponds to the chosen direction then writing S0=0S_0 = 0 and

Sn+1=Sn+ϵn2n+1 S_{n+1} = S_n + \frac{\epsilon_n}{2^{n+1}}

we obtain sequence of Atalatan’s position on the real line.

In the non-oscillating case (ϵn=1\epsilon_n = 1 for all nn) then this just corresponds to a geometric series of common ration 12\frac{1}{2}. SnS_n converges to 1 by lower values, with remaining distance being 12n\frac{1}{2^n}. More generally, SnS_n is just the partial sum of an absolutely convergent series and so is convergent to a destination S=n=0+ϵn2n+1S_\infty = {\sum_{n=0}^{+\infty} \frac{\epsilon_n}{2^{n+1}}}. It is easy to see that |Sn|<1\left|S_n\right| < 1, |S|1\left|S_\infty\right| \leq 1 and |SSn|12n{\left| S_\infty - S_n \right| \leq \frac{1}{2^n}}. If additionally ϵn\epsilon_n is chosen so that it is not ultimately constant (i.e. Atalatan’s position keeps oscillating) then this becomes a strict inequality |SSn|<12n{\left| S_\infty - S_n \right| < \frac{1}{2^n}}.

In theory, it is possible to reach any destination x[1,1]x \in {[-1,1]} using this approach. Just define ϵn=1\epsilon_n = 1 if and only if SnxS_n \leq x (i.e. “move toward xx”). It is easy to prove by recurrence that |xSn|12n{\left| x - S_n \right| \leq \frac{1}{2^n}} for all nn and so S=xS_\infty = x. However, this assumes we already know xx in order to decide the sequence of directions ϵn\epsilon_n. Let’s see how to build sequences without knowing the destination.

Avoiding an at most countable subset

Suppose that XX \subseteq \mathbb R is at most countable and let (xn)n{(x_n)}_{n \in \mathbb N} be a sequence of real numbers such that X={xn:n}X = \left\{ x_n : n \in \mathbb N \right\}. We want to find a sequence such that SXS_\infty \notin X.

Assuming additionally that it has infinitely many terms above 11 and infinitely many terms below 1-1, then we obtain a non-ultimately-constant sequence by defining ϵn=1\epsilon_n = 1 if and only if SnxnS_n \geq x_n (i.e. “move away from xx”). This is because 1<Sn<1-1 < S_n < 1 so there are always infinitely many terms in front of and behind Atalanta.

Incidentally, X=X = \mathbb N with trivial enumeration xn=nx_n = n shows a simple counter-example with no term below 1-1 and ultimately constant ϵn\epsilon_n. In that case, S0=0S_0 = 0 and S1=12S_{1} = \frac{1}{2} and Sn+1=Sn12n+1S_{n+1} = S_{n} - \frac{1}{2^{n+1}} for n1n \geq 1. But S=0S_\infty = 0 \in \mathbb N.

To workaround that issue, we can alternatively define the sequence ϵ2n=1\epsilon_{2n} = 1 if and only if SnxS_n \geq x and ϵ2n+1=ϵ2n\epsilon_{2n+1} = -\epsilon_{2n}. This still moves away from all xnx_n once, keeps oscillating and does not require additional assumption on XX.

Whatever the decision chosen, we can show that SXS_{\infty} \notin X. Otherwise, consider one NN such that ϵN\epsilon_{N} is defined by moving away from SS_{\infty}. Then either SNS0{S_N - S_\infty} \geq 0 and SN+1=SN+12N+1S+12N+1S_{N+1} = {S_N + \frac{1}{2^{N+1}}} \geq {S_\infty + \frac{1}{2^{N+1}}} or SN+1=SN12N+1<S12N+1S_{N+1} = {S_N - \frac{1}{2^{N+1}}} < {S_\infty - \frac{1}{2^{N+1}}}. But in any case, we would have |SSN+1|12N+1{\left| S_\infty - S_{N+1} \right| \geq \frac{1}{2^{N+1}}} which contradicts our strict inequality for not ultimately constant ϵn\epsilon_n.

As explained in the previous blog, this shows that \mathbb R (or any complete subspace containing \mathbb Q) is uncountable. Otherwise, we could use a sequence enumerating it to arrive to a contradiction.

Similarly, because \mathbb Q is countable then we can find a sequence such that {xn:n}=\left\{ x_n : n \in \mathbb N \right\} = \mathbb Q, which gives us an irrational number SS_\infty. If instead XX is the set of algebraic numbers (which is countable and contains \mathbb Q) then we obtain a transcendental SS_\infty.

An explicit computation

The big difference between the case of \mathbb Q and the set of algebraic numbers is that it’s much easier to actually compute a list of (xn)n{(x_n)}_{n \in \mathbb N} that lists all the \mathbb Q. For example, a simple way to enumerate the fractions pq\frac{p}{q} without trying to avoid duplicate values is, for each M=0,1,2,...M=0, 1, 2, ... to enumerate the integers pp and q0q \neq 0 bounded by MM in the lexicographical order. One can similarly enumerate for each MM the non-constant polynomial of degree at most MM and integer coefficient bounded by MM but it’s not obvious how to actually compute their roots.

One can rely on root finding algorithm to estimate the roots α\alpha in order to be able to calculate the sign SnαS_n - \alpha and so determine ϵn\epsilon_n. But in theory, α\alpha can be arbitrary close to SnS_n so it’s not clear how much precision to request.

Instead, let’s consider (Pn)n{(P_n)}_{n \in \mathbb N} an enumeration of the non-constant polynomial with integer cofficients and define ϵn=1\epsilon_n = 1 if and only if (PnPn)(Sn)0{(P_n\prime P_n)}{(S_n)} \geq 0. With that new formula, ϵn\epsilon_n can be calculated very easily in O(degPn)O(\deg P_n) from the cofficients of PnP_n using Horner’s method.

For any integer M1M \geq 1, let’s consider QM±=(X±2)MQ_M^\pm = {(X \pm 2)}^M. Then its product with its derivative is M(X±2)2M1M {(X \pm 2)}^{2M -1}. Its value at any xx has the same sign as x±2x \pm 2 and if |x|<1\left|x\right| < 1 it just ±\pm. For any nn, we can find MM large enough such that QM+Q_M^+ and QMQ_M^- have not been enumerated yet. So ϵn\epsilon_n is not ultimately constant. Alternatively, we could have used the trick from the previous section to force that property.

Now let’s prove that SS_\infty is still algebraic. If that’s not the case, let nn such that Pn(S)=0{P_n(S_\infty)} = 0. We can choose nn such that PnP_n is of minimal degree and so Pn(S)0{P_n\prime(S_\infty)} \neq 0. Since PnP_n has only finitely many roots, there is knk \geq n such that at maximum distance 12k\frac{1}{2^k} around SS_\infty, SS_\infty is the only root of PnP_n and PnP_n\prime does not vanish. Let’s MM large enough such that the polynomial RM=Pn2M+1R_M = P_n^{2M+1} has not been enumerated before PkP_k. Let’s ll such that Pl=RMP_l = R_M.

In the considered neighbourhood of SS_\infty, PlP_l has only one root SS_\infty, has the same sign as PnP_n and its derivative (2M+1)Pn2MPn{(2M+1)}P_n^{2M} P_n\prime has the same nonzero constant sign as PnP_n\prime. Analyzing each combination PlP_l\prime positive/negative and SlS_l greater/smaller than SS_\infty, we verify that ϵl\epsilon_l is chosen such that |SSl+1|12l+1{\left| S_\infty - S_{l+1} \right| \geq \frac{1}{2^{l+1}}} which is obviously also true if Sl=SS_l = S_\infty. This agains contradict our strict inequality. Q.E.D.