An error is now returned if `numTables` is zero or greater than 4096.
While this isn't explicitly mentioned in the specification, subsequent
calculations will be incorrect if the value falls outside this range.
This commit limits `WOFF::Header::num_tables` to 4096. This limitation
is not explicitly mentioned in the specification, but allowing numbers
larger than this results in an overflow when calculating
`search_range` and `range_shift`.
Previously, `load_from_memory()` just took a raw pointer to the data,
and then manually calculated offsets from that pointer. Instead, let's
use the MappedFile we already have, to stream in the data, to make
things a bit safer. We also now check that the entire file's data was
read, since if there was data left over, then either the file is bad or
we've done something wrong.
I've moved the code directly into `try_load_from_mapped_file()` since
`load_from_memory()` was only called from there. The extra indirection
wasn't adding anything.
Since it will become a stream in a little bit, it should behave like all
non-trivial stream classes, who are not primarily intended to have
shared ownership to make closing behavior more predictable. Across all
uses of MappedFile, there is only one use case of shared mapped files in
LibVideo, which now uses the thin SharedMappedFile wrapper.
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).
