https://cldr.unicode.org/index/downloads/cldr-44
Notable changes that affect us include:
* The Islamic Calendar is now localized as the Hijri Calender (in en-US)
but has not been updated for all locales. So this patch updates tests
where possible and removes a few test cases that currently cannot be
localized.
* The und locale has received more likely subtag data (the und locale is
basically a pseudo-locale meaning "undetermined").
* The exponential symbol in the Arabic number system was changed from
U+0627 to U+0623.
It's a little awkward that one caller of this is passing through an
Optional<String> and another an Optional<DeprecatedString>, but that
should be fixed some point in the future with further DeprecatedString
porting.
No IDL file pulls in these requiring DeprecatedString support, so we
are now able to remove these functions! :^)
Also leave a FIXME while we are at it, as ideally this function would
take an Optional<FlyString> - but the IDL generator does not currently
support this.
These were DeprecatedFlyStrings, but had no reason to be. We were not
making use of the O(1) lookup, so instead of porting it over to a
FlyString, just make it a StringView.
This is the API for NamedNodeMap which we are wanting to eventually use
instead of taking a StringView. Currently we just end up deferring to
the StringView versions of these functions, but at some stage in the
future, this will allow us to have O(1) comparison when making attribute
lookups.
In the meantime, the advantage of this API is that it makes it much less
awkward to use than the StringView variant when you have an
Optional<FlyString> namespace to pass through.
The original value 15 was too little: it made our
`weighted_boolean_fair_false` test fail every now and then.
This is because a fair coin (P(false) = 0.5) will hit the same value 15
times in a row with a probability (1/2)^15: around once in a 32k tries.
With the bumped up value, this is now once in 1 billion tries. Should
lower the test flakiness enough (if our random number generator is
truly uniform), while 30 tries is still an OK amount of computation for
randomized tests to do, compared to 15.
Now that x86-specific Assembler will be compiled on every architecture
we can't rely on void* being the right width.
It also fixes compilation on targets which have void*
be different length from u64 (WASM in particular).
This is in preparation for making LibJIT support multiple architectures.
Assembler will now be typedefed to the specific assembler
for a particular architecture.
Additionally, there's now JIT_ARCH_SUPPORTED which is defined on
architectures which LibJIT supports.
This makes JS::JIT::Compiler less architecture-specific
and unifies aligning the stack into a single operation,
where previously we were doing it separately for preserved registers
and for stack arguments.
* Compare array size to 3 and 4, not 4 and 5
* Fix literal typo in error message
Fixes crash processing 0000906.pdf from 0000.zip from the pdf/a dataset.
Representing a text run panting command as a vector of glyphs, rather
than as a string simplifies collecting of unique glyphs which is a
prerequisite for `prepare_glyphs_texture()` call.
Text painting operates in two steps:
1. Preparation of a texture that contains all the glyphs required for
text painting, along with metadata that describes the locations of
those glyphs within texture beforehand.
2. Blitting glyphs from the prepared texture onto corresponding glyph
quads.
Users of LibAccelGfx will need to call `prepare_glyphs_texture()`,
passing a set of all unique (font, code_paint) pairs, before painting
any text.
This change separates a part of the `draw_text_run()` function, which
is responsible for calculating the positions for glyphs that need to be
painted, into a separate function called `get_glyph_run()`.
It is a part of the preparation for text run painting using OpenGL,
where we can't immediately blit glyph bitmaps but instead need to
prepare a sequence of quads for them in advance.
