Previously when launching a UI process and/or a WebContent process on
Windows, the following message would be output to the console:
Fontconfig error: Cannot load default config file: No such file: (null)
Apparently on Windows, you have to provide a font .conf file to
fontconfig explicitly. Since we are not doing that, the default fonts
that are backed off to are not ideal.
Similar to how we aren't using fontconfig on Android, Windows also has
native font infrastructure in terms of both a collection of System
installed fonts as well as skia support for font managers that use
native Windows APIs. With that, we can remove the usage of fontconfig
entirely and improve the fonts used on websites like ladybird.org or
google.com.
Enhance `Font::harfbuzz_font()` to include font variation information
when creating HarfBuzz fonts. This required updating the `Font` struct
to store details about font variations.
I wasn’t aware of this, but it also fixed some visual artifacts with
variable fonts, so big thanks to @Lubrsi for the suggestion!
This change lays the groundwork for variable font support in LibWeb.
FontVariationSettings enables customization of existing font axes such
as weight (wght) and width (wdth).
This patch introduces a per-Gfx::Font cache for harfbuzz text shaping
results. As long as the same OpenType features are used, we now cache
the results of harfbuzz shaping, saving massive amounts of time during
text layout.
As an example, it saves multiple seconds when loading the ECMAScript
specification at <https://tc39.es/ecma262>. Before this change, harfbuzz
shaping was taking up roughly 11% of a profile of loading that page.
The cache brings it down to 1.8%.
Note that the cache currently grows unbounded. I've left a FIXME about
adding some limits.
This first pass only applies to the following two cases:
- Public functions returning a view type into an object they own
- Public ctors storing a view type
This catches a grand total of one (1) issue, which is fixed in
the previous commit.
Based very scientifically on what's listed here:
https://harfbuzz.github.io/what-does-harfbuzz-do.html
I've moved the code into LibGfx because including a HarfBuzz header
directly from LibWeb is a little unpleasant. But the Gfx::FontTech enum
follows the CSS definitions for font features for simplicity.
TrueType collections are supported. SVG and Embedded OpenType are not,
but they're not widely supported by other browsers so that's fine.
Most of the features are completely supported by HarfBuzz, so we can
just return true. Graphite support is optional (and it appears we use a
build of HarfBuzz without it) but there's a define we can check.
Incremental Font Transfer is a whole separate thing that we definitely
don't support yet.
this commit also introduces GlobalFontConfig class that is now
responsible for fontconfig initialization. it seems sane, even thought
FcInit's docs state that if the default configuration has already been
loaded, this routine does nothing.
the goal is to rely on fontconfig for font directory resolution. it
doesn't seem like it would be appropritate to call to fontconfig funcs
from within the LibCore.
i'm not 100% confident that FontDatabase is the correct place.. seems
okay?
Typeface::try_load_from_externally_owned_memory() relies on that
external owner keeping the memory around. However, neither WOFF nor
WOFF2 do so - they both create separate ByteBuffers to hold the TTF
data. So, rename them to make it clearer that they don't have any
requirements on the byte owner.
This improves the quality of our font rendering, especially when
animations are involved. Relevant changes:
* Skia fonts have their subpixel flag set, which means that individual
glyphs are rendered at subpixel offsets causing glyph runs as a
whole to look better.
* Fragment offsets are no longer rounded to whole device pixels, and
instead the floating point offset is kept. This allows us to pass
through the floating point baseline position all the way to the Skia
calls, which already expected that to be a float position.
The `scrollable-contains-table.html` ref test needed different table
headings since they would slightly inflate the column size in the test
file, but not the reference.
