This is an adaptation of the "misc/backgrounds.html" file in the
Serenity image. It tests a lot of background-related properties that we
otherwise have no tests for.
While parsing DSR response, we might encounter invalid characters, for
example, when we `cat` a binary file. Previously, we just pushed those
characters in `m_incomplete_data` buffer, which worked fine until we
didn't get a terminating character. We kept increasing coordinate value
and crashed in following assertion.
Before this change `navigate()` was always invoked twice when a link
is clicked:
- From `activation_behavior` callback of `HTMLAnchorElement` during
event dispatch.
- Directly from `handle_mouseup`.
It is a mistake to add this early return in fragment navigation because
"ongoing navigation id" is not used during this kind of navigation.
With this change we no longer crash in Acid2 test after reload button
is pressed.
Whenever the tests produce a `test-dumps` directory, publish the files
in it as an artifact. This lets us peek at the screenshots and see
what's mismatched, instead of just having to guess.
When the `--dump-failed-ref-tests` flag is provided, screenshots of the
actual and reference pages will be placed in
`Build/lagom/ladbybird/test-dumps`. This makes it a lot easier to spot
what's wrong with a failing test. :^)
NumericLimits<u32>::max + 1 overflowing to 0 caused us to call
AK::get_random_uniform(0) which doesn't make sense (the argument is an
_exclusive_ bound).
The current implementation fails if a file in the archive is not valid
UTF-8. The CLDR 44.0.1 package unfortunately contains such files (it
errantly has .DS_Store files).
If a unit tests defines a `deps` array, the unit test template would
have tried to overwrite it (and it is actually an error to overwrite
a non-empty list with another non-empty list).
This will not meaningfully affect short array literals, but it does
give us a bit of extra perf when evaluating huge array expressions like
in Kraken/imaging-darkroom.js
This is a hack: Ideally we'd have a CMYK Bitmap pixel format,
and we'd convert to rgb at blit time. Then we could also apply color
profiles (which for CMYK images are CMYK-based).
Also, the colors for our CMYK->RGB conversion are off for PDFs,
and we have distinct codepaths for this in Gfx::Color (for paths)
and JPEGs. So when we fix that, we'll have to fix it in two places.
But this doesn't require a lot of code and it's a huge visual
progression, so let's go with it for now.
The file wasn't quite decided if it wanted to sort by ascii value
or by case folding. Now it uses ascii value, thanks to vim's
`:'<,'>sort`.
No behavior change.
This is a very inefficient implementation: Every time a type 3 font
glyph is drawn, we parse its operator stream and execute all the
operators therein.
We'll want to instead cache the glyphs in bitmaps (at least in most
cases), like we do for other fonts. But it's a good first step, and
all the coordinate math seems to work in the files I've tested.
Good test files from pdfa dataset 0000.zip:
- 0000559.pdf page 1 (and 2): Has a non-default font matrix;
text appears mirrored if the font matrix isn't handled correctly
- 0000425.pdf, page 1: Draws several glyphs in a single run;
glyphs overlap if Renderer::render_type3_glyph() ignores the
passed-in point
- 0000211.pdf, any page: Uses type 3 glyphs for all text.
Good perf test (already "reasonably fast")
- 0000521.pdf, page 5 (or 7 or or 16): The little red flag in the
purple box is a type 3 font glyph, and it's colored (which in part
means the first operator is `d0`, while all the other documents above
use `d1`)
Type 3 font glyphs begin with either `d0` or `d1`. If we bail out
with an "unsupported" error on the very first operator in a glyph,
we'll never paint the glyph.
Just stub these out for now. We probably want to do more in here in
the future (see "TABLE 5.10 Type 3 font operators" in the 1.7 spec).
They are the first operator in a type 3 charproc.
Operator.h already knew about them, but we didn't manage to parse
them, since they're the only two operators that contain a digit.
It's a bit unfortunate that fonts need to know about the renderer,
but type 3 fonts contain PDF drawing operators, so it's necessary.
On the bright side, it makes it possible to pass fewer parameters
around and compute things locally as needed.
(As we implement more fonts, we'll probably want to create some
functions to do these computations in a central place, eventually.)
No behavior change.
/BaseFont is a required key for type 0, type 1, and truetype
font dictionaries, but not for type 3 font dictionaries.
This is mechanical; type 0 fonts don't even use this yet
(but probably should).
PDFFont::initialize() is now empty and could be removed,
but maybe we'll put stuff there again later, so I'm leaving
it around for a bit longer.
