We previously did not notify the listener about entering the root node,
which caused the following snippet to produce the wrong output:
a = new DOMParser
a.parseFromString("<x/>", "text/xml").documentElement // != null
This makes Piano exactly as usable as when I started the large refactor
some years ago, which *sounds* like I'm a terrible person but now it (1)
looks nicer and (2) has a flexible backend that can already deal with
aribtrary kinds of processors on any track.
These were part of the postcreate script previously, but with the new
powers of sed, we can text-replace the library name and make changing
them much more convenient.
Namely, the window title and size are carried over, since a larger
window with a more readable "Example Application" title is better to
understand. I also took the opportunity to add a missing trailing
newline to the generated CMake file.
Our current `peek_bits` function allows retrieving more bits than we can
actually provide, so whenever someone discards the requested bit count
afterwards we were underflowing the value instead.
The actual cause for the "missing bits" is currently unknown, and this
test case doesn't actually start obviously breaking yet unless we start
reporting errors about missing bits. However, since we are touching the
BitStream implementation already, let's add the test early to make extra
sure that we aren't breaking anything.
This follows on from the SVG linear gradients. It supports the same
features (xlink:href, gradientUnits, gradientTransform).
With this commit I have now implemented all web gradients :^)
(Though we are still missing a few parameters for SVG gradients,
e.g. spreadMethod).
This also slightly refactors things to share more implementation with
the SVG linear gradients, and improve accuracy (which fixes some banding
issues).
Since this FIXME was added the SVGFormattingContext has got a fair bit
more spec compliant. The other more specific FIXMEs in this file should
be more useful.
This is typically used as `class A extends EventTarget`. It's usage can
be found on websites such as https://loadout.tf/
This has the quirk that we don't do set the EventTarget prototype for
HTML::Window, as it would cause a null deref on startup. However, given
it wasn't doing this before, I don't think it should cause any issues.
The actual port is SeriousSamClassic, but only The First Encounter is
built and installed. It should be relatively easy to also build and
install The Second Encounter from this port in the future.
LutAToBTagData::from_bytes() and LutBToATagData::from_bytes() already
reject curves for which this isn't true with an error.
Ensure potential future callers of the constructors get it right too.
https://www.w3.org/TR/CSS22/visuren.html#floats says that when a box
establishes BFC it should not overlap with floats. The way to avoid
overlaps is up to implementor. This change implements avoiding overlap
by narrowing width of a box because it seems like what other engines
do (in the scenarios I tested).
Calculating width of a box in BFC requires having resolved y to be able
to check if a box overlaps with any floating boxes.
This change makes compute_width() to be called after finding y
position. That also required to move resolving of vertical metrics
in the beginning of a box layout process to have vertical margins
resolved before finding y position.
Resolves#18618.
8134dcc changed `JsonArray::set()` to insert elements at an index
instead of changing existing elements in-place. Since no behavior
such as `Vector::try_at()` exists yet, it returns nothing.
When there are floats present inside an IFC, we must coordinate with
the parent BFC to calculate the automatic width of the IFC's block box.
This is because the IFC is not directly aware of floats. Only the BFC
knows enough about them to account for them in automatic sizing.
In particular, we now blockify layout internal boxes (e.g table parts)
by turning them into `block flow`. This fixes a crash when viewing
our GitHub repo :^)
This adds 'JonoF's Duke Nukem 3D Port'.
Parts of the network-related stuff has been patched out.
See patch: patches/0002-mmulti.c-ifdef-out-network-related-stuff-we-currentl.patch
Notes:
- Some sound work seems to be needed. During the title screen and
gameplay SFX works, but music does not play. At the ending screen of
Hollywood Holocaust music does play.
- GTK has been disabled, by default it will start in fullscreen, to get
back to windowed mode can be done through the Video Settings.
- OpenGL support has been disabled, as far as I can tell it will need
OpenGL 2.0 support which we do not currently have.
- True 3D renderer has been turned on.
This allows converting to a color space that uses a non-parametric
curve, for example:
Build/lagom/image -o foo.png \
--convert-to-color-profile .../profiles/sRGB-v2-micro.icc \
input.jpg
...where profiles/sRGB-v2-micro.icc is from
https://github.com/saucecontrol/Compact-ICC-Profiles/
(Parametric curves are new in ICC v4, which means all v2 profiles
use point curves.)
For now, only for color spaces that are supported by Profile::to_pcs()
and Profile::from_pcs(), which currently means that all matrix profiles
(but not LUT profiles) in the source color space work, and that
matrix profiles with parametric curves in the destination color
space work.
This adds Profile::convert_image(Bitmap, source_profile), and
adds a `--convert-to-color-profile file.icc` flag to `image`.
It only takes a file path, so to use it with the built-in
sRGB profile, you have to write it to a file first:
% Build/lagom/icc -n sRGB --reencode-to serenity-sRGB.icc
`image` by default writes the source image's color profile
to the output image, and most image viewers display images
looking at the profile.
For example, take `Seven_Coloured_Pencils_(rg-switch_sRGB).jpg`
from https://commons.wikimedia.org/wiki/User:Colin/BrowserTest.
It looks normal in image viewers because they apply the unusual
profile embedded in the profile. But if you run
% Build/lagom/image -o huh.png --strip-color-profile \
'Seven_Coloured_Pencils_(rg-switch_sRGB).jpeg'
and then look at huh.png, you can see how the image's colors
look like when interpreted as sRGB (which is the color space
PNG data is in if the PNG doesn't store an embedded profile).
If you now run
% Build/lagom/image -o wow.png \
--convert-to-color-profile serenity-sRGB.icc --strip-color-profile \
'Seven_Coloured_Pencils_(rg-switch_sRGB).jpeg'
this will convert that image to sRGB, but then not write
the profile to the output image (verify with `Build/lagom/icc wow.png`).
It will look correct in image viewers, since they display PNGs without
an embedded color profile as sRGB.
(This works because 'Seven_Coloured_Pencils_(rg-switch_sRGB).jpeg'
contains a matrix profile, and Serenity's built-in sRGB profile
uses a matrix profile with a parametric curve.)
