We now cache potentially named elements on the Document when elements
are inserted and removed. This allows us to do lookup of what names are
supported much faster than if we had to iterate the tree every time.
This first cut doesn't implement the rules for 'exposed' object and
embed elements.
Together with the already-merged #23122, #23128, #23135, #23136, #23162,
and #23167, #23179, #23190, #23194 this adds initial support for
rendering some CFF-based Type0 fonts :^)
There's a long list of things that still need improving after this:
* A small number of CFF programs contain the charstring command 0,
which is invalid. Currently, this makes us reject the whole font.
* Type1FontProgram::rasterize_glyph() is name-based. For CID-based
fonts, we want a version that takes CIDs (character IDs) instead.
For now, I'm printing the CID to a string and using that, yuck.
(I looked into doing this nicely. I do want to do that, but I
need to read up on how the `seac` type1 charstring command uses
character names to identify parts of an accented character.
Also, it looks like `seac`'s accented character handling moved
over to `endchar` in type2 charstring commands (i.e. in CFF data),
and it looks like we don't implement that at all. So I need to do
more reading first, and I didn't want to block this on that.)
* The name for the first string in name-based CFF fonts looks wrong;
added a FIXME for that for now.
* This supports the named Identity-H cmap only for now. Identity-H
maps UTF16-BE values to glyph IDs with the idenity function, and
assumes it's horizontal text. Other named cmaps in my test files are
UniJIS-UCS2-H, UniCNS-UCS2-H, Identity-V, UniGB-UCS2-H, UniKS-UCS2-H.
(There are also 2 files using the stream-based cmaps instead of the
name-based ones.)
* In particular, we can't draw vertical text (`-V`) yet
* Passing in the encoding to CFF::create() is awkward (it's nullptr
for CID-keyed fonts), and it's also not necessary since
`Type1Font::draw_glyph()` already does the "take encoding from PDF,
and only from font if the PDF doesn't store one" dance.
* This doesn't cache glyphs but re-rasterizes them each time. Easy
to add, but maybe I want to look at rotation first. And things
don't feel glacial as-is.
* Type0Font::draw_glyph() is pretty similar to second half of
Type1Font::draw_glyph()
Make TopDict's defaultWidthX and nominalWidthX Optional<>s so that
we can check if they're set per fdselect-selected font dict, and
if so use the value from there in CID-keyed fonts. Otherwise, keep
using the value in the top dict.
This begins the process of aligning our implementation with the spec
with regard to using CalendarMethodsRecord. The main intent here is to
make it much easier to make normative changes to AOs which have been
updated to CalendarMethodsRecord.
While this does resolve various FIXMEs, many others above need to be
added in order to be able to pass through a CalendarMethodsRecord. The
use here aligns with what I can gather from the spec of what the
arguments to CreateCalendarMethodsRecord should be, but various AOs have
been updated so much with other changes it's not completely obvious.
Other AOs do not even exist in the latest version of the spec, but we
still rely on them.
As part of these updates, this commit coincidentally also fixes two
PlainDate roundingmode issues seen in test262 - a test of which is also
added in test-js. This issue boiled down to what appears to be an
observable optimization in the spec, where it can avoid calling
dateUntil in certain situations (roundingGranularityIsNoop).
However, the main goal here is to make it much easier to fix many more
issues in the future :^)
since/calendar-dateuntil-called-with-singular-largestunit.js ❌ -> ✅
until/calendar-dateuntil-called-with-singular-largestunit.js ❌ -> ✅
This is part of a large refactor made as part of the temporal spec.
Most AOs using the calendar now pass through this record. There will
need to be a long process of going through updating AOs to use this
record.
Duplicates can show up when copy-pasting IDL snippets into existing IDL
files, and the resulting error is extremely useless and misleading.
This commit makes it so the parser catches these cases, and emits a more
helpful error like "Overload set 'instantiate' contains multiple
identical declarations".
This is a simple extension of GenericLexer, and is used in more than
just LibXML, so let's move it into AK.
The move also resolves a FIXME, which is removed in this commit.
Before this change, the rebaseline script would generate reference
based on 'about:blank' (at least running it on my macOS system).
This commit allows 'about:blank' through the assertion and only dumps
the layout tree when theloaded URL matches the one we are interested
in.
Along with this, Port.h is include which helps generalising common
information for the port package, like it's name and version. With
SemVer complaint versions, it is possible to show positive change
(upgrade) or negative change (downgrade) in the installed ports.
However, for some non-complaint versions (eg. using git commit hash),
non-equality (`!=`) is used to notify upgrade. Since there is no
algorithm (without git history) to check the order of commits, it is
not possible to inform whether it is an upgrade or downgrade.
Semantic Versioning (SemVer) is a versioning scheme for software that
uses MAJOR.MINOR.PATCH format. MAJOR for significant, possibly
breaking changes; MINOR for backward-compatible additions; PATCH for
bug fixes. It aids communication, compatibility prediction, and
dependency management. In apps dependent on specific library versions,
SemVer guides parsing and validates compatibility, ensuring apps use
appropriate dependencies.
<valid semver> ::= <version core>
| <version core> "-" <pre-release>
| <version core> "+" <build>
| <version core> "-" <pre-release> "+" <build>
It seems that the difference between pending and ASAP in the spec is
only to allow the implementation to perform implementation-defined
operations between the two states. We don't need to distinguish the two
states, so lets just combine them for now.
An SDL2 application is allowed to show a message box before the video
subsystem is initialized. This change makes sure GUI::Application is
initialized.
An example of this is SRB2: the process forks itself to let the child
process install itself as the signal handler and deal with errors. This
child process could try to show a message box long after the video
subsystem was initialized, but since it is a forked process there is no
static state for GUI::Application or the connection to the window
server and the process would crash because of a null dereference.
* FDArray, FDSelect must be present
* Encoding must not be present
* Charset maps from GID (Glyph ID) to CID (Character ID),
instead of to character name
The fdselect array (that we already read) maps eachs glyph ID
to an fdarray index. The font dict at that index then stores
information for that glyph.
In practice, this is used to assign different defaultWidthX /
nominalWidthX values to blocks of glyphs in CID-keyed fonts.
We don't do anything yet with the data, and we also don't send
data of CID-keyed CFFs into this parser either, so no behavior
change.
This happens for CFFs that contain multiple fonts. This doesn't
happen in practice, but the same code will be used for fdarray
parsing, which will contain several dicts.
No behavior change.
Instead of limiting ourselves to the key of the property in the JSON,
allow overriding the function name so we can generate completely
different function signatures with very similar names to other existing
API methods (e.g. `glUniform*` vs `glUniform*v`).