This updates fonts so rather than rastering directly to a bitmap, you
can extract paths for glyphs. This is then used to implement a
Gfx::Path::text("some text", font) API, that if given a vector font
appends the path of the text to your Gfx::Path. This then allows
arbitrary manipulation of the text (rotation, skewing, etc), paving the
way for Word Art in Serenity.
An error is now returned if `numTables` is zero or greater than 4096.
While this isn't explicitly mentioned in the specification, subsequent
calculations will be incorrect if the value falls outside this range.
a396bb0 removed the palette field but did not update the allocation size
in `Bitmap::serialize_to_byte_buffer()`. This led to a few crashes (I
noticed this from a drag/drop crash in the file manager).
Fixes#21434
The first implementation of this property was just plain wrong. Looks
like this property isn't used a lot as I found the issue by reviewing
the code and not because of a specific image.
The test image is a 32x32 mosaic of alternating black and yellow pixels,
it was generated using this code:
Bitdepth 8
RCT 1
Width 32
Height 32
if W-WW-NW+NWW > -300
- Set -1000
- Set 900
Currently, the `isobmff` utility will only print the media file type
info from the FileTypeBox (major brand and compatible brands), as well
as the names and sizes of top-level boxes.
This image is exactly the same as the previous one, excepted the RCT
transformation. It has been generated with:
Width 64
Height 64
RCT 29
Upsample 2
Bitdepth 10
if N > 300
- NE -6
- W 6
This image uses the modular encoding with a very simple prediction tree.
It also makes use of two features: upsampling (x2 factor) and a
non-standard bit depth (10 bits). The file has been generated on
https://jxl-art.surma.technology/ , with the following input:
Width 64
Height 64
Upsample 2
Bitdepth 10
if N > 300
- NE -6
- W 6
Reordering these calls allow us to ensure that all encoders are able to
return the size of the image before they are requested to decode the
whole bitmap.
This tests that we can successfully parse the "everything" TVG files,
which make use of every feature in TinyVG.
Test files taken from https://github.com/TinyVG/examples (MIT).
Assertion fails if the point is outside of the rect. This was introduced
in introduced in #18970 and causes serenity to crash when changing to 2x
resolution for a monitor, if the cursor after resizing is outside of
the new screen.
Added test to reproduce.
This just works at the moment after e19892a099, but if we ever do
the FIXME in ColorIndexingTransform::transform(), this test will
remind us to think of this case there too.
catdog-alert-13-alpha-used-false.webp is identical to
catdog-alert-13.web but with the byte at offset 0x2a changed from
0x10 to 0x00 -- that is, the bit in the VP8L header that stores
`is_alpha_used` is cleared.
See the commit message of e19892a099 for more information.
Two files are used both as test inputs for the webp decoder test and
for the icc profile test.
Use redundant copies of these two files for the two usecases, since
different parts of the files are used in both tests (and we could
remove the unneeded parts later).
simple-vp8l-alpha-used-false.webp is a copy of simple-vp8l.webp,
with the byte at offset 0x18 changed from 0x10 to 0x00 -- that
is, the bit in the VP8L header that stores `is_alpha_used` is cleared.
We would already allocated a BGRx8888 instead of a BGRA8888 bitmap,
but keep actual alpha data in the `x` channel.
That lead to at least `image` still writing a PNG with an alpha channel.
So explicitly set the alpha channel to 0xff when is_alpha_used is false,
to make sure all consumers of decoded lossless webp data have behavior
consistent with other webp readers.
In practice, webp encoders usually don't write files that have
`is_alpha_used` set to false and then write actual alpha data to their
output. So this is rarely observable. However, for example for
lossy+ALPH webp files, the lossless webp used to store the ALPH channel
has `is_alpha_used` set to false and all channels but green are 0
(since the lossless green channel stores the alpha channel of a
lossy+ALPH webp). So if we dump such a bitmap to a standalone webp
file (e.g. with the temporary debugging code in fc3249a1ca),
then without this commit here, `image` would convert that webp to
a fully transparent webp, while other webp software would correctly
display the green image with opaque alpha.
I opened smolkling.webp in Photoshop, added a layer mask with a vertical
gradient, replaced the leftmost column with completely transparent
pixels (because the leftmost column is vertically predicted with the
horizontal filter too), and saved it as webp. That wasn't enough to
get a horizontal filter for the ALPH chunk though, so I also ran
cwebp \
-alpha_filter best \
smolkling.webp \
-o Tests/LibGfx/test-inputs/smolkling-vertical-alpha.webp
That did the trick.
I opened smolkling.webp in Photoshop, added a layer mask, and
scribbled a shape vaguely looking like the letter "C" on it.
I then saved it as a lossy webp and that was enough to end up
with filter method ¯\_(ツ)_/¯
I opened smolkling.webp in Photoshop, added a layer mask with a
horizontal gradient, and saved it as webp. That wasn't enough to
get a horizontal filter for the ALPH chunk though, so I also ran
cwebp \
-alpha_filter best \
smolkling-ps.webp \
-o Tests/LibGfx/test-inputs/smolkling-horizontal-alpha.webp
That did the trick.
(Looks like doing the same with a vertical or diagonal gradient
_also_ produces a webp file with filtering_method 1, i.e. horizontal.)
