A few closely-related changes:
- Move our definitions of the OpenType spec's "data types" into their
own header file.
- Add definitions for the integer types there too, for completeness.
(Plus Uint16 matches the spec term, and is less verbose than
BigEndian<u16>.)
- Include Traits for the non-BigEndian types so that we can read them
from Streams. (BigEndian<integer-type> already has this.)
- Use the integer types in our struct definitions.
As a bonus, this fixes a bug in Hmtx, which read the left-side bearings
as i16 instead of BigEndian<i16>.
Do more checks at load time, including categorizing the subtables and
producing our own directory of them.
The format for Kern is a little complicated, so use a Stream instead of
manual offsets.
Maxp had the shared fields duplicated, and OS2 embedded each version's
struct in the next. Instead, let's use inheritance to avoid duplicating
shared fields while still allowing them to be directly accessed.
While I'm at it, rename the Maxp and GPOS table structs to just be
VersionX_Y, because they're not ambiguous with anything else.
LibGfx: Rename GPOSHeader to HeaderVersion1_0
Because there's a version 1.1 as well, which we'll eventually want to
support.
At first glance this looks like it holds the memory that the various
slices point into... but it actually doesn't own that memory. Nobody
uses m_buffer, so it serves no purpose.
Some of these are odd sizes. We managed not to insert padding because
BigEndian is itself marked as packed, but let's be explicit instead of
relying on that. :^)
Normally, we want to avoid accidentally using such atomics, since
they're much slower. In this case however, we're just implementing
another atomics API, it is then up to the JavaScript code to avoid
using the slow atomics.
We currently cannot parse the output of `toString` and `toUTCString`.
While the spec does not require such support, test262 expects it, and
all major engines support it.
For example, LibJS will need to parse date strings of the form:
Wed Dec 31 1969 19:00:00 GMT-0500 (Eastern Standard Time)
This string contains both the time zone offset (-05:00) and a display
name for the time zone (Eastern Standard Time). Because we will already
handle time zone adjustments when we handle the offsets, we will want to
just skip the time zone name. This patch will let us use a format string
of the form "GMT%z (%+)" to do so.
LibCore currently cannot depend on LibTimeZone directly. All build-time
code generators depend on LibCore, so there'd be a circular dependency:
LibCore -> LibTimeZone -> GenerateTZData -> LibCore.
So to support parsing time zone names and applying their offsets, add a
couple of weakly-defined helper functions. These work similar to the way
AK::String declares some methods that LibUnicode defines. Any user who
wants to parse time zone names (from outside of LibCore itself) can link
against LibTimeZone to receive full support.
Having two ways that `<position>` is represented is awkward and
unnecessary. So, let's combine the two paths together. This first step
copies and modifies the `parse_position()` code to produce a
`PositionStyleValue`.
Apart from returning a StyleValue, this also makes use of automatic enum
parsing instead of manually comparing identifier strings.
Display a warning when some images are missing, instead of crashing.
Also, don't keep old images around when loading a new set, and make use
of get_piece_graphic() more often.
Previously we would give up on loading the piece images if one fails.
That was awkward because 2 out of 3 places where `set_piece_set_name()`
is called can't propagate errors, so we'd just crash.
Instead, let's skip any images that fail to load, and then when painting
the preview, skip any missing bitmaps and show a warning message that
some are missing.
This will be required for propagating the current animation time to all
relevant timelines, which each propagate that time to all of their
relevant animations.
