This moves the CSS gradient painting to the painter creating:
- Painter::fill_rect_with_linear_gradient()
- Painter::fill_rect_with_conic_gradient()
- Painter::fill_rect_with_radial_gradient()
This has a few benefits:
- The gradients can now easily respect the painter scale
- The Painter::fill_pixels() escape hatch can be removed
- We can remove the old fixed color stop gradient code
- The old functions are now just a shim
- Anywhere can now easily use this gradient painting code!
This only leaves the color stop resolution in LibWeb (which is fine).
Just means in LibGfx you have to actually specify color stop positions.
(Also while here add a small optimization to avoid generating
excessively long gradient lines)
DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so
let's rename it to A) match the name of DeprecatedString, B) write a new
FlyString class that is tied to String.
While this subtable ID is supposed to be deprecated, it is used heavily
in PDF files.
It supports mapping one or two-byte values, with quite a large list of
encodings to tell you which one to expect.
For our use case, we ignore this encoding ID and just pick the first
subtable with this platform ID. Unsupported encodings will get caught
by Subtable::glyph_id_for_code_point() anyway.
This trims the input bytes to the profile size stored in the file.
Alternatively, we could reject files where the stored size doesn't
match the handed in size. But ICC profiles can be embedded in other
files, and those could conceivably pad the ICC profile data some.
There's a small, old-timey list of platforms in the spec, but as far
as I can tell nobody is using additional platforms on Linux or Android
or what. So let's try going with an enum class instead of the FourCC
machinery for now.
Namely:
- preferred CMM type
- device manufacturer
- device model
- profile creator
These all have in common that they can take arbitrary values, so I added
a FourCC class to deal with them, instead of using an enum class.
I made distinct types for each of them, so that they aren't accidentally
mixed up.
These flags are always 0 in practice in all profiles I've seen so far,
but hey, probably nice to dump them anyways.
And hey, it's just 86 lines to print 4 bits.
Always computing computing the md5 takes some time, but most
icc profiles are small. So that's probably fine.
If this ends up being a perf problem in the future, or if it ends up
rejecting tons of embedded proiles from images, we can row it back.
But let's see if we can get away with this first.
I checked that they are zero for all profiles in Compact-ICC-Profiles
and for all .icc files in /Library/ColorSync and
/System/Library/ColorSync on my Mac (running macOS 12.6.2).
This is achieved by simplifying the logic in TextLayout. We get rid
of all the various ways that the layout bounding rect can get cropped.
Then we make sure to use the right pixel metrics.
Finally we use the font's own line gap metrics instead of hard-coding 4.
The end result is that text painted with vector fonts now gets pretty
reasonable vertical alignment in most cases.
This adds the option to pass a subpixel offset when fetching a glyph
from a font, this offset is currently snapped to thirds of a pixel
(i.e. 0, 0.33, 0.66). This is then used when rasterizing the glyph,
which is then cached like usual.
Note that when using subpixel offsets you're trading a bit of space
for accuracy. With the current third of a pixel offsets you can end
up with up to 9 bitmaps per glyph.
`inline` already assigns vague linkage, so there's no need to
also assign per-TU linkage. Allows the linker to dedup these
functions across TUs (and is almost always just the Right Thing
to do in C++ -- this ain't C).
In doing so, this removes all uses of the Encoder's stream operator,
except for where it is currently still used in the generated IPC code.
So the stream operator currently discards any errors, which is the
existing behavior. A subsequent commit will propagate the errors.
