This adds a basic `mkfs.fat` utility, which can format FAT12, FAT16
and FAT32 partitions.
This does have a few limitations, namely in that FAT12 formatting is
limited to a set known floppy disk sizes, and we can only generate
512-byte sectors.
Previously, we would remove the "longest extension" from each file name
when parsing it as the name of a utility, which made it impossible for
the names of utilities to contain any extensions.
This creates a bitmap filled with a fixed color, then (in memory)
saves it as jpeg and loads it again, and repeats that until the
color of the bitmap no longer changes. It then reports how many
iterations that took, and what the final color was.
It does this for a couple of colors.
This is for quality assessment of the jpeg codec. Ideally, it should
converge quickly (in one iteration), and on a color not very far from
the original input color.
This patch brings a service to handle image decompression. With it comes
security enhancement due to the process boundary. Indeed, consequences
of a potential attack is reduced as only the decoder will crash without
perturbing the WebContent process.
It also allows us to display pages containing images that we claim to
support but still make us crash, like for not-finished-yet decoders.
As an example, we can now load https://jpegxl.info/jxl-art.html without
crashing the WebContent process.
This utility is actually a symlink to the gunzip utility.
The gunzip utility is modified to enable writing to stdout when running
through the zcat symlink, to emulate the same behavior on other OSes.
In addition to that, the gunzip utility is now required on a default
installation as it could be a vital utility under some conditions (for
example, downloading source code in a tar.gz file).
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 is still very bare bones, and there is _much_ more to still
handle. However, this implements enough functionality to parse a single
unified patch read from stdin, and apply it to a file.
Using the cross-page links, we can generate a directed graph showing the
topology of which pages refer to other pages. This is not just for fun:
the links show how often a page is linked (since links are not
deduplicated on purpose), which pairs of pages only have links in one
direction (where a link in the other direction may be useful), which
groups of closely-interlinked pages exist, and which pages have few or
no links to other pages.
The EXTRA_MARKDOWN_CHECK_ARGS argument to the check-markdown script can
be used to inject the -g flag for generating the graph on all manpages.
This utility will learn tricks such as extracting images from PDFs and
dumping tables from PDFs so that we can create code from specs.
It also allows testing LibPDF things in lagom, and allows testing
reading large amounts of PDFs using a shell script.
The intention for this utility is to eventually become a general-purpose
multimedia conversion tool like ffmpeg (except probably not with as many
supported formats, stream mappings and filters). For now, we can not
write any video format so the added complexity is not necessary at the
moment.
This will make it a lot easier to understand what went wrong, especially
when the failure occurs on CI but not at home.
And of course, use LibDiff to generate the diff! :^)
This little program allows us to take the NetworkSettings app away
from being an elevated GUI app.
It receives a JsonObject on STDIN and writes it to the global
Network configuration file.
If the write was successfull it will apply the changes.
The initial version of sed implements only the `s` command (given on the
command line) applied to all lines of the input file. While this is
probably the most common scenario that people use sed with in the wild,
it's limited in several ways:
* `s` is only one of the many commands that sed is meant to implement.
* Commands may take one or two addresses that limits its applicability
to input lines.
* Commands in general operate over the "pattern" and "hold" spaces
rather than blindly over input lines.
* Command line parameters include specifying a script file, and
optionally input file(s) and/or a script to execute.
This commit implements a big portion of these missing features:
* It adds support for parsing *almost* all commands and their
arguments.
* It also implements the execution of a big portion of the commands.
* It adds support for parsing the optional addresses that prefix a
command, and enables/disables commands based on these address ranges.
* It implements the pattern and hold spaces, which are the source of
input/output for most of the commands.
* It improves the command line argument handling to receive a script
file, potentially multiple execution scripts, and optional input
files.
Some know missing functionality:
* The `{` and `}` commands are not supported yet.
* Pattern-based addresses are not supported yet.
* Labels and branches are parsed, but not supported at runtime.
We can always read the basic format information (sample rate, bit depth,
etc.), but we will also print artist, album, and title if available in
the metadata.
headless-browser currently uses its own PageClient to load web pages
in-process. Due to this, it also needs to set up a whole bunch of other
objects needed to run LibWeb, e.g. image decoders, request servers, etc.
This changes headless-browser to instead implement a WebView to launch
WebContent out-of-process. This implementation is almost entirely empty,
but can be filled in as-needed. For example, we may want to print
JavaScript console messages.
At the moment, all it can do is read all image formats that LibGfx can
read and save to any image format that LibGfx can write (currently bmp,
png, qoi).
Currently, it drops all image metadata (including color profiles).
Over time, this could learn tricks like keeping color profiles,
converting an image to a different color profile, cropping out a part of
an image, and so on.
