Ultimately, we should find a way to route all emoji access through
the font code, but for now, this patch adds a special case for fonts
that are known to have embedded color bitmaps so we can test them.
This patch does three things:
- Font::has_color_bitmaps() (true if CBLC and CBDT are present)
- Glyph now knows when its bitmap comes from a color bitmap font
- Painter draws color bitmap glyphs with the appropriate scaling etc
This also removes DirIterator::error_string(), since the same strerror()
string will be included when you print the Error itself. Except in `ls`
which is still using fprintf() for now.
The values aren't 100% self-consistent, but it probably doesn't make
a difference for u8 color data. Good enough for now. See all the links
on #17714 for some more background.
Calling it was harmless as add_ac iterates over the spectral selection,
hence it won't do anything if not needed. However, this patch remains
useful as it prevents dereferencing the iterator returned by find, in
case the AC table isn't defined yet. This case happens with SOF2 images
and is (pretty harmless as read only but still) undefined behavior.
This patch brings support for SOF2 JPEGs that only use spectral
selection :^)
We still don't have achieved full support for SOF2 images, but as an
example, we decode progressive JPEG from Cloudinary.
This might be useful for converting data from arbitrary profiles to
sRGB.
For now, this only encodes the transfer function and puts in zero values
for chromaticities, whitepoint, and chromatic adaptation matrix.
This makes the profile unusable for now. But I've spent a very long time
reading things and need to check in some code, and it's some progress.
The encoded transfer function exactly matches the one in GIMP's built-in
sRGB ICC profile (but not the Compact-ICC-Profiles v4 one or the
RawTherapee v4 one -- I'll add a comment about why later.)
This returns the font's size (distance between ascender and descender)
in pixels, rounded up to the nearest integer.
This is the number we want to use in a lot of UI code, so let's have
a friendly API for it instead of ceil'ing the pixel_size() in a million
random places.
This API is used by LibWeb's text painter. Bring it up to date with the
glyph width computations performed in draw_text_line() used by other GUI
applications.
Similar to the FontDatabase, this will be needed for Ladybird to find
emoji images. We now generate just the file name of emoji image in
LibUnicode, and look for that file in the specified path (defaulting to
/res/emoji) at runtime.
Scan with only one component are by definition not interleaved, meaning
that each value is linearly ordered in the stream. Grayscale images
were supported thanks to a hack, by forcing the subsampling to 1.
Now we properly support grayscale image with other subsampling (even if
it doesn't make sense) and more generally scans with only one component
and any sampling factors.
While this solution is more general than the last one it also feels a
bit hackish. We should probably refactor the way we iterate over
components and macroblocks. But that's work for latter, especially when
we will add support for other subsampling than 4-2-2.
Huffman streams are encountered in the scan segment. They have nothing
to do outside this segment, hence they shouldn't outlive the scan.
Please note that this patch changes behavior. The stream is now reset
after each scan.
A scan can contain fewer components that the full image. However, if
there is multiple components, they have to follow the ordering of the
frame header. It means that we can loop over components of the image
and skip those that doesn't correspond.
For now, we exit after the first scan without needing to parse `EOI`.
However, to read scans in a loop we will need to properly detect and
parse `EOI`.
This patch brings us closer to the spec point of view. And while it
makes no functional changes, it reduces the number of places where you
can misuse scan-specific data and improve support for multiple scans.
Nobody made use of the ErrorOr return value and it just added more
chance of confusion, since it was not clear if failing to sniff an
image should return an error or false. The answer was false, if you
returned Error you'd crash the ImageDecoder.
Turns out extended-lossless-animated.webp did have a loop count of 0.
So I opened it in Hex Fiend and changed the byte at position 42
(which is the first byte of the little-endian u16 storing the loop
count) to 0x2A, so that the test can compare the loop count to something
not 0.
This reorganizes things so that:
* When initially decoding chunks, we only store pointers to
their data and don't look at the contents
* We allow pausing decoding after decoding the first chunk, since
that's where the dimensions are stored, and we don't need to read
more than that if we only care about dimensions. (Currently
inconsequential, but maybe we want to get dimensions after
receiving the first few bytes off the network in the future.)
* We then have separate methods to interpret chunk data
(only for the first few bytes which store the size, so far.)
