mft1 and mft2 tags are very similar. The only difference is that
mft1 uses an u8 lookup table, while mft2 uses a u16 lookup table.
This means their PCS lookup encodings are different, and mft2 uses a
PCSLAB encoding that's different from other places in the v4 spec.
The css-backgrounds.html ref test file only tests the most basic usage
of this, which failed to catch some regressions, so let's add a more
extensive test. :^)
There were two bugs here, one of which hid the other:
- Only one offset would have a value, but we dereferenced both.
- We consumed a token whether it was a valid offset or not.
This allows us to remove one raw Web::Page& member. Or rather, it
becomes a JS::NonnullGCPtr that we trace like anything else. :^)
Co-Authored-By: Andreas Kling <kling@serenityos.org>
This is a first step towards removing the various Page& and Page*
we have littering the engine with "trust me bro" safety guarantees.
Co-Authored-By: Andreas Kling <kling@serenityos.org>
This is a first step towards simplifying the ownership model of
Web::Page. Soon Web::Page will store its WebClient as a
NonnullGCPtr to help solve lifetime issues of the client being
destroyed before the page.
Given that we have a glyph run where the position of each glyph is
calculated for text fragments during layout, we can reuse it to avoid
this work during painting.
Pages like the new tab page, error page, etc. all belong solely to
Ladybird, but are scattered across a couple of subfolders in Base. This
moves them all to Base/res/ladybird.
When a QObject subclass (widgets, etc.) are provided a parent, then
ownership of that object is passed to the parent. Similarly, objects
added to a QLayout are owned by the layout.
Thus, do not store these objects in an OwnPtr.
QString is UTF-16, thus QString::size returns the number of UTF-16 code
units. Thus, we would fail to perform, for example:
ak_string_from_qstring(QString("😀"));
Which is 2 UTF-16 code units, but 4 UTF-8 code units.
There's no need for 2 overloads for String and DeprecatedString, we can
just use a StringView. This also avoids some cases of needlessly
allocating a DeprecatedString from a StringView when calling this
method.
This patch fixes `nix develop` commands not using proper paths, uses
the serenity root directory as an assumption for all commands and
adds variants of nix commands to use a custom entry point, for example
a shell.
This patch updates the flake to track the nixos-unstable branch instead
of master for the nixpkgs flake input.
This ensures that hydra.nixos.org (the NixOS CI) has built all packages,
made them available in the cache.nixos.org binary cache without the risk
of a definitions (evalulation) being broken on master.
If one profile uses PCSXYZ and the other PCSLAB as connection space,
we now do the necessary XYZ/LAB conversion.
With this and the previous commits, we can now convert from profiles
that use PCSLAB with mAB, such as stress.jpeg from
https://littlecms.com/blog/2020/09/09/browser-check/ :
% Build/lagom/icc --name sRGB --reencode-to serenity-sRGB.icc
% Build/lagom/bin/image -o out.png \
--convert-to-color-profile serenity-sRGB.icc \
~/src/jpegfiles/stress.jpeg
ICC profiles work by transforming from the input color space
(one of many: RGB, CMYK, YUV, etc) to a "profile connection space" (PCS)
and then from there to the output color space.
However, there's not one but two possible profile connection spaces,
PCSXYZ and PCSLAB. The matrix/curve tags can only be used with PCSXYZ,
but the mAB, mBA, mft1, mft2 tags can be used with PCSLAB as well.
The PCSLAB encoding has L going from 0 to 100 and ab from -128 to 127,
instead of from 0 to 1. So they need to be scaled up at the end.
That's also the reason for the "mystery conversion factor": PCSXYZ
doesn't go from 0 to 1 either, but from 0 to 65535/32768, per ICC v4
6.3.4.2 General PCS encoding, Table 11 - PCSXYZ X, Y or Z encoding.
Between input and output are various curves (and the CLUT) that
have domain and range of 0..1. For these, the color has to be linearly
scaled to 0..1 before the curve and back to the actual range after
the curve. Doing that back-to-back is a no-op, so scaling back at
the very end is sufficient.
We will need to use ColorSpace in TagTypes.h, and it can't include
Profile.h.
Also makes Profile.cpp a bit smaller.
No behavior change, pure code move.
This allows a limited amount of DOM manipulation through the Inspector.
Users may edit node tag names, text content, and attributes. To initiate
an edit, double-click the tag/text/attribute of interest.
To remove an attribute, begin editing the attribute and remove all of
its text. To add an attribute, begin editing an existing attribute and
add the new attribute's text before or after the existing attribute's
text. This isn't going to be the final UX, but works for now just as a
consequence of how attribute changes are implemented. A future patch
will add more explicit add/delete actions.
This adds APIs to allow Ispector clients to:
* Change a DOM text or comment node's text data.
* Add, replace, or remove a DOM element's attribute.
* Change a DOM element's tag.
