The following command was used to clang-format these files:
clang-format-18 -i $(find . \
-not \( -path "./\.*" -prune \) \
-not \( -path "./Base/*" -prune \) \
-not \( -path "./Build/*" -prune \) \
-not \( -path "./Toolchain/*" -prune \) \
-not \( -path "./Ports/*" -prune \) \
-type f -name "*.cpp" -o -name "*.mm" -o -name "*.h")
There are a couple of weird cases where clang-format now thinks that a
pointer access in an initializer list, e.g. `m_member(ptr->foo)`, is a
lambda return statement, and it puts spaces around the `->`.
The C++ standard does not allow specifying the template parameters in
constructor declarations, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97202#c8.
Converting constructors have a higher priority that user-defined
conversion functions; let's constrain `Gfx::Size<T>(Gfx::Size<U>)` to
only be considered when `U` is convertible to `T`. This lets us fall
back to conversion operators in the case of `UISize` -> `IntSize`, for
instance. Clang is still okay without this, but MSVC would error out
similarly: https://godbolt.org/z/PTbeYPM7s
Note that a not-yet-committed patch is required for full compilation:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114784#c3
Most JPEG2000 files put the codestream in an ISOBMFF box structure
(which is useful for including metadata that's bigger than the
~65k marker segment data limit, such as large ICC profiles), but
some files just store the codestream directly, for example
https://sembiance.com/fileFormatSamples/image/jpeg2000/balloon.j2c
See https://www.iana.org/assignments/media-types/image/j2c for the
mime type.
The main motivation is to be able to use the test data in J.10 in
the spec as a test case.
Add factory functions to distinguish between when the owner of the File
wants to transfer ownership to the new IPC object (adopt) or to send a
copy of the same fd to the IPC peer (clone).
This behavior is more intuitive than the previous behavior. Previously,
an IPC::File would default to a shallow clone of the file descriptor,
only *actually* calling dup(2) for the fd when encoding or it into an
IPC MessageBuffer. Now the dup(2) for the fd is explicit in the clone_fd
factory function.
These changes are compatible with clang-format 16 and will be mandatory
when we eventually bump clang-format version. So, since there are no
real downsides, let's commit them now.
A tag tree is a data structure used for deserializing JPEG2000
packet headers.
We don't use them for anything yet, except from tests.
The implementation feels a bit awkward to me, but we can always polish
it later.
The spec thankfully includes two concrete examples. The code is
correct enough to pass those -- I added them as test.
For text, we always ended up with a leading \0 byte (on little-endian),
which prints as nothing. Since that's the only thing we do with this
data, no actual behavior change.
We don't do anything with this (except log the contents if
JPEG2000_DEBUG is 1).
The motivation is that we now decode all marker segments that are
used in all JPEG2000 files I've seen so far, allowing us to make
remaining unknown marker types fatal.
This fixes the relevant warnings when running LibJSGCVerifier. Note that
the analysis is only performed over LibJS-adjacent code, but could be
performed over the entire codebase. That will have to wait for a future
commit.
The halftone region decoding procedure can draw patterns completely
outside the page bitmap. I haven't seen this in practice yet (not
many files use pattern/halftone segments), but it seems like it's
possible in theory and seems like a good thing to check for.
Annex C describes how to read a grayscale bitmap with n bits per pixel:
It's encoded as n bilevel bitmaps, where each bilevel bitmap stores one
bit of the grayscale value (using a en.wikipedia.org/wiki/Gray_code,
which is named after Frank Gray and doesn't normally have much to do
with grayscale images).
A halftone region stores a grayscale bitmap and a linear coordinate
system the grayscale bitmap is in. The grayscale bitmap is overlaid
the halftone region using the coordinate system, and each sample in
the grayscale bitmap is used as an index into a pattern dictionary
and the bitmap at that index is drawn at the current location.
This allows for efficient compression of ordered dithering
(but not error-diffusion dithering).
This does not yet implement halftone region decoding for MMR bitmaps.
The halftone region decoding procedure is the only way to call the
generic region decoding procedure with a skip pattern. This does
include code to compute the skip pattern, but support for that
is not yet implemented in the generic region decoding procedure,
so it'll error out when encountered. (I haven't yet found a file
using this feature, not a way to create such a file yet.)
A pattern dictionary stores n bitmaps with the same dimensions w x h.
They're stored in a single bitmap of width `n * w` that's then cut
into n stripes.
The implementation is very similar to #23831.
I created the test exactly like in #23713, except that I replaced the
last four lines in the ini file with:
```
-txt -Param -rATX1 10
-txt -Param -rATY1 -1
-txt -Param -rATX2 4
-txt -Param -rATY2 15
```
...in the generic region decoding procedure (not yet in the generic
refinement region procedure). Not yet for EXTTEMPLATE though.
I haven't seen these being used in the wild, but:
* I want to optimize this code some, and it's probably good if it
is feature complete (and well-tested) before being optimized
* Other PDF engines implement support for this
* The Pattern/Halftone feature (which we don't yet implement either,
but which I'd like to implement because see previous two bullets)
calls the generic region decoding procedure with custom adaptive
template pixels
