Only some specific number of values should be allowed, but let's accept
everything for now and add these checks when the generator will be more
mature.
Let's make the "read a sample" part independent of the decoder. That
will soon allow us to read samples based on the image's parameter
without duplicating the code for every decoder.
Fixes these errors from `Meta/test_pdf.py path/to/0000`, with
0000 being 0000.zip from the PDF/A corpus in unzipped:
Malformed PDF file: Indexed color space lookup table doesn't
match size, in 4 files, on 8 pages, 73 times
path/to/0000/0000206.pdf 2 4 (2x) 5 (3x) 6 (4x)
path/to/0000/0000364.pdf 5 6
path/to/0000/0000918.pdf 5
path/to/0000/0000683.pdf 8
When upsampling e.g. the 4-bit value 0b1101 to 8-bit, we used to repeat
the value to fill the full 8-bits, e.g. 0b11011101. This maps RGB colors
to 8-bit nicely, but is the wrong thing to do for palette indices.
Stop doing this for palette indices.
Fixes "Indexed color space index out of range" for 11 files in the
PDF/A 0000.zip test set now that we correctly handle palette indices
as of the previous commit:
Malformed PDF file: Indexed color space lookup table doesn't match
size, in 4 files, on 8 pages, 73 times
path/to/0000/0000206.pdf 2 4 (2x) 5 (3x) 6 (4x)
path/to/0000/0000364.pdf 5 6
path/to/0000/0000918.pdf 5
path/to/0000/0000683.pdf 8
Previously, we were scaling palette indices from 0..(palette_size - 1)
to 0..255 before using them as index into the palette. Instead, do not
scale palette indices before using them as indices.
(Renderer::load_image() uses `component_value_decoders.empend(
.0f, 255.0f, dmin, dmax)`, so to get an identity mapping, we have to
return `0, 255` from IndexedColorSpace::default_decode()).
Fixes rendering of the gradient on page 5 of 0000277.pdf.
BorderRadiusCornerClipper usage to clip border radius is specific to
CPU painter so it should not be stored in painting commands.
Also with this change bitmaps for corner sampling are allocated during
painting commands replaying instead of commands recording.
Currently, when editing a DOM attribute, the replacement method first
removes the attribute, then adds the replacement attributes. This
results in the edited attribute jumping to the end of the attribute
list in the Inspector.
This patch will try to avoid removing the attribute if one of the
replacements has the same name. This will keep the edited attribute in
the same location.
The FIXME added to ConnectionFromClient::remove_dom_node is copied from
Web::EditEventHandler. The same behavior is observed here, with many
lingering Layout::TextNodes, for example.
The Inspector will have context menu support to manipulate the DOM, e.g.
adding or removing nodes/attributes. This context menu will require some
detailed knowledge about what element in the Inspector has been clicked.
To support this, we intercept the `contextmenu` event and collect the
required information to be sent to the Inspector client over IPC.
First, we had a logic typo where we were checking parse errors for
non-empty instead of non-null. Fixing this caused more modules to
actually start executing.
As usual, this tripped on some "empty backup incumbent settings object
stack" bugs, so this patch also pushes a module execution context in
two places where it makes sense.
Co-Authored-By: networkException <networkexception@serenityos.org>
For now, we handle this by creating a synthetic async function to wrap
the top-level module code. This allows us to piggyback on the async
function driver wrapper mechanism.
Gfx::ICC::Profile's current API takes bytes, so we need to do some
contortions for LAB values to go through.
This will probably become nicer once we implement all the backward
transforms in Gfx::ICC::Profile, but for now let's hack it in
on the LibPDF side.
Makes colors in 0000651.pdf looks good, especially on pages 1 and 7-12.
Other browsers have a nice little feature where right-clicking on a
`mailto` or `tel` link will let you copy the email address or telephone
number, instead of the full URL. So let's do that!
mft1 and mft2 tags are very similar. The only difference is that
mft1 uses an u8 lookup table, while mft2 uses a u16 lookup table.
This means their PCS lookup encodings are different, and mft2 uses a
PCSLAB encoding that's different from other places in the v4 spec.
The css-backgrounds.html ref test file only tests the most basic usage
of this, which failed to catch some regressions, so let's add a more
extensive test. :^)
There were two bugs here, one of which hid the other:
- Only one offset would have a value, but we dereferenced both.
- We consumed a token whether it was a valid offset or not.
This allows us to remove one raw Web::Page& member. Or rather, it
becomes a JS::NonnullGCPtr that we trace like anything else. :^)
Co-Authored-By: Andreas Kling <kling@serenityos.org>
This is a first step towards removing the various Page& and Page*
we have littering the engine with "trust me bro" safety guarantees.
Co-Authored-By: Andreas Kling <kling@serenityos.org>
