Some clients (e.g LibWeb) want to look up typefaces by name. Since we
already store typefaces in a HashMap keyed by family name, let's also
have a nice & fast API that takes advantage of this.
It wasn't enough to do it only for simple glyphs, we need to do it for
composite glyphs as well.
Fixes an issue where some glyph data was misaligned in the output and
thus ended up rendered incorrectly or not at all.
This fixes an issue with some typefaces where the space character has an
advance width, but no glyf entry (and thus no ascent/descent). Before
this change, we'd render whitespace with zero advance in such cases.
This resolves a problem where the kerning value multiplied by the scale
is stored in the cache, even though the code retrieving the value from
the cache does not anticipate it to be scaled. As a result, it leads to
a buggy double multiplication by the scale.
Before this change we always returned the font's point size as the
x-height which was basically never correct.
We now get it from the OS/2 table (if one with version >= 2 is available
in the file). Otherwise we fall back to using the ascent of the 'x'
glyph. Most fonts appear to have a sufficiently modern OS/2 table.
Remove SplitLineSegment and replace it with a FloatLine, nobody was
interested in its extra fields anymore. Also, remove the sorting of
the split segments, this really should not have been done here
anyway, and is not required by the rasterizer anymore. Keeping the
segments in stroke order will also make it possible to generate
stroked path geometry (in future).
Implied point = point created by two subsequent "off curve" points.
Fixes following issues in function that builds glyph path from points:
- If first point is "off curve" it was wrongly treated as "on curve"
which caused wrong first point position in the path.
- If both first and last points in the path are "off curve" implied
point was not created between them which caused wrong path shape in
the end of the path.
This seems mostly harmless and matches what CSS expects from us at the
moment. Eventually our CSS font selection will become more sophisticated
and stop relying on Gfx::FontDatabase for things like this, but for now
it's a simple stopgap that lets websites do "font-family: arial" :^)
The Font class now remembers the results of kerning lookups in a
HashMap. This fixes an issue where text-heavy UI (like WidgetGallery)
would lag when using a UI font with kerning data.
Negative accumulation on the right-hand side of the accumulation bitmap
would wrap around to the left, causing a negative start for certain
lines which resulted in horizontal streaks of lower alpha values.
Prevent this by not writing out of bounds :^)
Fixes#18394
When creating a copy of the font containing only the glyphs that are in
use, we previously looped over all possible code points, instead of the
range of code points that are actually in use (and allocated) in the
font. This is a problem, since we index into the array of widths to find
out if a given glyph is used. This array is only as long as the number
of glyphs the font was created with, causing an out of bounds read when
that number is less than our maximum.
Some fonts (like the Bootstrap Icons webfont) have bogus glyph offsets
in the `loca` table that point past the end of the `glyf` table.
AFAICT other rasterizers simply ignore these glyphs and treat them as if
they were missing. So let's do the same.
This makes https://changelog.serenityos.org/ actually work! :^)
The spec tells us that for glyph offsets in the "loca" table, if an
offset appears twice in a row, the index of the first one refers to a
glyph without an outline (such as the space character). We didn't check
for this, which would cause us to render a glyph outline where there
should have been nothing.
The stored ValueRecord in the font file only contains the fields
specified in the valueFormat field of the PairPosFormat1 table.
This means we need to construct the ValueRecord dynamically at runtime
and cannot bit_cast it to a struct.
read_value_record(u16 value_format, FixedMemoryStream& stream) takes
a bitmask value_format that describes the available fields of
the ValueRecord and a FixedMemoryStream at the location of the
next ValueRecord. It then advances the stream and returns a complete
ValueRecord.
At the moment, we only understand lookup type 2 (pair adjustment)
so let's ignore lookup tables with other types.
This fixes an issue where we'd choke on Noto Sans versions that come
with a chained context positioning lookup table (type 8).
Fixes#17924
This patch parses enough of GPOS tables to be able to support the
kerning information embedded in Inter.
Since that specific font only applies positioning offsets to the first
glyph in each pair, I was able to get away with not changing our API.
Once we start adding support for more sophisticated positioning, we'll
need to be able to communicate more than a simple "kerning offset" to
the clients of this code.
Ultimately, we should find a way to route all emoji access through
the font code, but for now, this patch adds a special case for fonts
that are known to have embedded color bitmaps so we can test them.
