This was the only remaining codec that produced IndexedN bitmaps.
By removing them, we'll be able to get rid of those formats and simplify
the Bitmap and Painter classes.
Previously, `load_from_memory()` just took a raw pointer to the data,
and then manually calculated offsets from that pointer. Instead, let's
use the MappedFile we already have, to stream in the data, to make
things a bit safer. We also now check that the entire file's data was
read, since if there was data left over, then either the file is bad or
we've done something wrong.
I've moved the code directly into `try_load_from_mapped_file()` since
`load_from_memory()` was only called from there. The extra indirection
wasn't adding anything.
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
