There's probably a nicer way of doing this where we don't need to expand
the gray value into a full Vector3, but for now this is good enough.
Makes PDFs written by macOS 13.5.2's "Save as PDF..." feature show up.
Since it will become a stream in a little bit, it should behave like all
non-trivial stream classes, who are not primarily intended to have
shared ownership to make closing behavior more predictable. Across all
uses of MappedFile, there is only one use case of shared mapped files in
LibVideo, which now uses the thin SharedMappedFile wrapper.
It is unlikely this is needed anymore, and as pointed out things should
now safely return OOM if the bitmap is too large to allocate.
Also, no recently added decoders respected this limit anyway.
Fixes#20872
Some clients (e.g LibWeb) want to look up typefaces by name. Since we
already store typefaces in a HashMap keyed by family name, let's also
have a nice & fast API that takes advantage of this.
A few very minor changes seemed to small to commit separately:
- Fix typo postive -> positive
- Remove swap(start, end) FIXME, that is the correct thing to do
- Add FIXME for start_radius == end_radius case
- Formatting tweaks
Previously, it was assumed the focal point was the center of the start
circle. This is only the case if the start radius is zero or the centers
of the start and end circle are the same.
This was pretty hard to spot until repeating SVG radial gradients where
added, where the maths broke near the focal point.
The current implementation assumes the focal point is the center of the
start circle, for most cases the difference this makes is very subtle,
but becomes more apparent with spreadMethod=repeat/reflect.
Note that we already have Size::scaled(T). While subjectively providing
API symmetry, this is mostly to allow using these methods in templated
helpers without caring what the exact underlying type is.
Ignoring Size for a second, we currently have:
Rect::scale_by
Rect::scaled
Point::scale_by
Point::scaled
In Size, before this patch, we have:
Size::scale_by
Size::scaled_by
This aligns Size to use the same method name as Rect and Point. While
subjectively providing API symmetry, this is mostly to allow using this
method in templated helpers without caring what the exact underlying
type is.
It wasn't enough to do it only for simple glyphs, we need to do it for
composite glyphs as well.
Fixes an issue where some glyph data was misaligned in the output and
thus ended up rendered incorrectly or not at all.
IFF was a generic container fileformat that was popular on the Amiga
since it was the only file format supported by Deluxe Paint.
ILBM is an image format popular in the late eighties/nineties
that uses the IFF container.
This is a very first version of the decoder that only supports
(byterun) compressed files with bpp <= 8.
Only the minimal chunks are decoded: CMAP, BODY, BMHD.
I am planning to add support for the following variants:
- EHB (32 colours + lighter 32 colours)
- HAM6 / HAM8 (special mode that allowed to display the whole Amiga
4096 colours / 262 144 colours palette)
- TrueColor (24bit)
Things that could be fun to do:
- Still images could be animated using color cycle information
Due to the way JPEG XL encodes its lossless images, it is sometimes
interesting to embed a large image and crop the result at the end. This
patch adds the functionality to crop a frame.
Note that JPEG XL supports image composition (almost like layers in
image editing software programs) and I tried to make these changes be
a step toward image composing. It's a small step as we are still unable
to read multiple frames, and we only support the `kReplace` blending
mode.
The image was previously managed as an output parameter of the
`read_frame` function. This reorganisation also brings us closer to the
spec. As it is specified that each frame have its own image that will
later on compose a greater bitmap.
