The predictor code assumed that all stream data is image data
(...which would make sense: trailing data there is wasted space).
But some PDFs have trailing data there, e.g. 0000257.pdf, so be
forgiving about it.
Now, we will evenly distribute the remaining free space across tracks
using the auto max-tracks sizing function, exactly as the specification
states. Many tests are affected, but they are not visually broken.
Fixes https://github.com/SerenityOS/serenity/issues/22798
Relative paths cause issues in a couple of ways:
- `open_project()` sets the working directory to that path, and then
opens a project at that same path. This means opening `./foo` goes to
`./foo`, and then tries to open `./foo/foo`.
- Even with that rearranged, we would then have issues with trying to
open files, because again we would try to open `./foo/foo/file`
instead of `./foo/file`.
- The relative path would get saved in "Recent Projects" which is wrong.
Absolutizing the path before using it means we avoid these issues, and
without having to rearchitect everything. :^)
There's now two namespaces, RIFF (little-endian) and IFF (big-endian)
which (for the most part) contain the same kinds of structures for
handling similar data in both formats. (They also share almost all of
their implementation) The main types are ChunkHeader and (Owned)Chunk.
While Chunk has no ownership over the data it accesses (and can only be
constructed from a byte view), OwnedChunk has ownership over this data
and is aimed at reading from streams.
OwnedList, implementing the standard RIFF LIST type, is currently only
implemented for RIFF due to its only user being WAV, but it may be
generalized in the future for use by IFF.
Co-authored-by: Timothy Flynn <trflynn89@pm.me>
This splits the RIFFTypes header/TU into the WAV specific parts, which
move to WavTypes.h, as well as the general RIFF parts which move to the
new LibRIFF.
Sidenote for the spec comments: even though they are linked from a site
that explains the WAV format, the document is the (an) overall RIFF spec
from Microsoft. A better source may be used later; the changes to the
header are as minimal as possible.
Previously, all page contents ended up overprinting a single line
over and over for PDFs that used only `\r` as line ending.
This is for example useful for 0000364.pdf.
This is to avoid duplicating the printing logic and so that we can
have an alternative way of printing the result (i.e. for the next
commit that will print without a pathname if no file operands were
provided). This also has us avoid the algorithm checks in the for
loop.
This codepath is separate from the predictor in the TIFF decoder.
The TIFF decoder currently does bits->Color conversion before
processing the predictor. That doesn't fit the PDF model where
filters are processed before converting streams into bitmaps.
If this code here ever grows to handle all cases, maybe we can move
it over to the TIFF decoder and then make it do predictions before
decoding to colors, to share this code.
(TIFF prediction is pretty messy since it's bits-per-pixel-dependent.
PNG prediction is always byte-based, which makes things easier.)
SamplingFactors already has default initializers for its field,
so no need to have an explicit one for the first of the two fields.
No behavior change.
We now allow all subsampling factors where the subsampling factors
of follow-on components evenly decode the ones of the first component.
In practice, this allows YCCK 2111, CMYK 2112, and CMYK 2111.
Previously, we handled sampling factors as part of ycbcr_to_rgb().
That meant it worked ok for code paths that used YCbCr ("normal"
jpegs, and the YCC part of YCCK jpegs), but it didn't work for
example for the K channel in YCCK jpegs, nor for CMYK.
By making this a separate pass, it should now work for all cases.
It also makes it easier to support more subsampling arrangements
in the future, and to use something better than nearest neighbor
for upsampling subsampled blocks.
...and hook it up.
I opened MainMenu.xib in Xcode, added a new "Submenu Menu Item"
from the Library (cmd-shift-l), added a User Defined
"toggleShowClippingPaths:" action on First Responder and connected
the menu item's action to that action.
(I first tried duplicating the existing Window menu and editing that,
but the Window menu is marked as `systemMenu="window"` in the xib and
I couldn't find a way to undo that in Xcode. So the Debug menu first
acted as a second Window menu.)
I made "Debug" a toplevel menu to make it consistent with Ladybird.app
for now, but I'll probably make it a submenu of "View" in the future.
For some reason I decided to change the argument passing order before
submitting my PR, but this would cause the oldset argument to always
be 0x74 as a0 is overridden with 0 in that order.
This refactoring makes WebContent less aware of LibWeb internals.
The code that initializes paint recording commands now resides in
`Navigable::paint()`. Additionally, we no longer need to reuse
PaintContext across iframes, allowing us to avoid saving and restoring
its state before recursing into an iframe.
There are a bunch of situations where we need to treat cross axis
max-size properties as "none", notably percentage values when the
reference containing block size is an intrinsic sizing constraint.
This fixes an issue where flex items with definite width would get
shrunk to 0px by "max-width: 100%" in case the item itself is an
SVG with no natural width or height.
For consistency, we now use the should_treat_max_width/height_as_none
helpers throughout FFC.
This makes the search/account/cart icons show up in the top right
on https://twinings.co.uk :^)
Mostly because I audited all places that assigned to `m_text_matrix`
after #22760.
This one is very difficult to trigger in practice.
`show_text()` marks the text rendering matrix dirty already,
so this only has an effect if the `TJ` array starts with a
number, and the matrix isn't marked dirty going in.
`Tm` caches the text rendering matrix, so I changed text.pdf
to contain:
```
1 0 0 1 45 130 Tm
[ 200 (Hello) -2000 (World) ] TJ T*
```
This first sets an x offset of 5 (on top of the normal 40), and
then undoes it (`200` is multiplied by font size (25) / -1000,
and `200 * 25 / -1000` is -5). Before this change, the topmost
"Hello World" ended up slightly indented.
Likely no behavior change in practice, but makes the code easier
to understand, and maybe it helps in the wild somewhere.
0000342.pdf page 5 contains this snippet:
```
/T1_1 10.976 Tf
0 -31.643 TD
(This)Tj
1 0 0 1 54 745.563 Tm
22.181 -31.643 Td
[(vehicle)-270.926(uses)...
```
The `Tm` marked the text rendering matrix as dirty at the start,
but it then calls calculate_text_rendering_matrix() almost in the
next line, which recalculates the text rendering matrix and caches
the new matrix. The `Td` used to not mark it as dirty, and we'd
draw "vehicle" with an incorrect matrix.
