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}$$:

• Cambria Math is a proprietary font installed by default on Microsoft Windows.
• STIX Two Math is a font under the OFL license with a large unicode coverage for scientific characters.
• Latin Modern Math is a font under the GUST license with the Computer Modern style that TeX uses by default.

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:

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.

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:

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:

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 gmail.com 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

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.

Conclusion

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.

Scrolling

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:

• Remove certain headers when a redirect causes a request method change
• Implement wildcard behavior for Cross-Origin-Expose-Headers”
• Align with Origin header changes
• Fetch: URL parser not always using UTF-8

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 $n$ she decides to move forward or backward by $\frac{1}{2^{n+1}}$. If $\epsilon_n \in {\{-1, 1\}}$ corresponds to the chosen direction then writing $S_0 = 0$ and

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

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

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

Avoiding an at most countable subset

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

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

Incidentally, $X = \mathbb N$ with trivial enumeration $x_n = n$ shows a simple counter-example with no term below $-1$ and ultimately constant $\epsilon_n$. In that case, $S_0 = 0$ and $S_{1} = \frac{1}{2}$ and $S_{n+1} = S_{n} - \frac{1}{2^{n+1}}$ for $n \geq 1$. But $S_\infty = 0 \in \mathbb N$.

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

Whatever the decision chosen, we can show that $S_{\infty} \notin X$. Otherwise, consider one $N$ such that $\epsilon_{N}$ is defined by moving away from $S_{\infty}$. Then either ${S_N - S_\infty} \geq 0$ and $S_{N+1} = {S_N + \frac{1}{2^{N+1}}} \geq {S_\infty + \frac{1}{2^{N+1}}}$ or $S_{N+1} = {S_N - \frac{1}{2^{N+1}}} < {S_\infty - \frac{1}{2^{N+1}}}$. But in any case, we would have ${\left| S_\infty - S_{N+1} \right| \geq \frac{1}{2^{N+1}}}$ which contradicts our strict inequality for not ultimately constant $\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 $\left\{ x_n : n \in \mathbb N \right\} = \mathbb Q$, which gives us an irrational number $S_\infty$. If instead $X$ is the set of algebraic numbers (which is countable and contains $\mathbb Q$) then we obtain a transcendental $S_\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 ${(x_n)}_{n \in \mathbb N}$ that lists all the $\mathbb Q$. For example, a simple way to enumerate the fractions $\frac{p}{q}$ without trying to avoid duplicate values is, for each $M=0, 1, 2, ...$ to enumerate the integers $p$ and $q \neq 0$ bounded by $M$ in the lexicographical order. One can similarly enumerate for each $M$ the non-constant polynomial of degree at most $M$ and integer coefficient bounded by $M$ 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 $S_n - \alpha$ and so determine $\epsilon_n$. But in theory, $\alpha$ can be arbitrary close to $S_n$ so it’s not clear how much precision to request.

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

For any integer $M \geq 1$, let’s consider $Q_M^\pm = {(X \pm 2)}^M$. Then its product with its derivative is $M {(X \pm 2)}^{2M -1}$. Its value at any $x$ has the same sign as $x \pm 2$ and if $\left|x\right| < 1$ it just $\pm$. For any $n$, we can find $M$ large enough such that $Q_M^+$ and $Q_M^-$ have not been enumerated yet. So $\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 $S_\infty$ is still algebraic. If that’s not the case, let $n$ such that ${P_n(S_\infty)} = 0$. We can choose $n$ such that $P_n$ is of minimal degree and so ${P_n\prime(S_\infty)} \neq 0$. Since $P_n$ has only finitely many roots, there is $k \geq n$ such that at maximum distance $\frac{1}{2^k}$ around $S_\infty$, $S_\infty$ is the only root of $P_n$ and $P_n\prime$ does not vanish. Let’s $M$ large enough such that the polynomial $R_M = P_n^{2M+1}$ has not been enumerated before $P_k$. Let’s $l$ such that $P_l = R_M$.

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