We are planning to add support for CFF fonts to read Type1 fonts, and
therefore much of the logic already found in PS1FontProgram will be
useful for representing the Type1 fonts read from CFF.
This commit moves the PS1-independent bits of PS1FontProgram into a new
Type1FontProgram base class that can be used as the base for CFF-based
Type1 fonts in the future. The Type1Font class uses this new type now
instead of storing a PS1FontProgram pointer. While doing this
refactoring I also took care of making some minor adjustments to the
PS1FontProgram API, namely:
* Its create() method is static and returns a
NonnullRefPtr<Type1FontProgram>.
* Many (all?) of the parse_* methods are now static.
* Added const where possible.
Notably, the Type1FontProgram also contains at the moment the code that
parses the CharString data from the PS1 program. This logic is very
similar in CFF files, so after some minor adjustments later on it should
be possible to reuse most of it.
This might not be an issue at the moment, but moved-from objects are
usually in a unspecifed but valid state, meaning that we shouldn't read
from them.
This commit expands the functionality of the "Crop Image to Content"
and "Crop Layer to Content" features by allowing them to detect and
crop the background color of an image instead of just cropping
transparent pixels.
The background color is determined by looking at the corner pixels of
the image. If no background color is found, the old behavior of
cropping transparent pixels is retained.
This makes sure that the aarch64 disk image also contains the correct
dynamic shared objects, specifically libgcc_s.so.1, as that one is a
dynamic dependency of every aarch64 executable.
To unify the x86_64 and aarch64 code paths, this commit just installs
everything from the compilers lib directory into the disk image lib
directory. This also happens for the Clang toolchain. This copies a few
extra files related to libsupc++ and libstdc++, increasing the size of
the disk image by 1.6MB. However, we were already copying libstdc++.a
manually anyway.
Without this tag, executables that link libgcc_s.so.1, which is every
executable, end up with the host path to libgcc_s.so.1 as the path for
the dynamic dependency (DT_NEEDED) of the executable. By making sure
that the libgcc_s.so.1 shared object includes the DT_SONAME tag, the
path to libgcc_s.so.1 dynamic dependency will only contain the basename,
instead of the absolute host path.
`Process::get_name()` and `Process::set_name()` are basically the same
as `get_process_name()` and `set_process_name()`, except making use of
convenient Serenity standard types and returning ErrorOr, instead of
char* and errno shenanigans.
`Process::set_name()` has an optional `SetThreadName` parameter, for
when you also want to set the thread's name to the same thing. That's
true for the two places that use `set_process_name()`.
The spec names are still a bit cryptic ("deviceMfgDescTag"
for "device manufacturer description"), but less cryptic than
just the fourcc.
There's a private tag area, so this will only print the spec name
of tags in the current spec. Private tags are in active use, e.g.:
$ icc /Library/ColorSync/Profiles/WebSafeColors.icc
...
Unknown tag ('dscm'): type 'mluc', offset 312, size 1490
(That's a v2 file. In v2, 'desc' has that strange textDescriptionType.
In v4, 'desc' has type 'mluc' -- but in v2, it didn't yet, so Apple
invented the private 'dscm' tag which has the description as an 'mluc'.)
Also add a function to map each tag signature to its name,
that is a function that maps e.g. measurementTag to "measurementTag"sv.
To implement this without too much repetition, use an x-macro.
I used pdftotext on the icc v4 spec to extract the list of tags,
and then manually cleaned it up a bit:
https://github.com/nico/hack/blob/main/icc-tags.txt
I then converted that to an x-macro using vim macros.
There is a problem with current approach where overflow clip rectange is
calculated by aggregating intersection of absolute padding boxes of
boxes in containing block chain that resulting rectangle doesn't
respect transform properties.
To solve this problem `PaintableBox` is changed to store clip rectangle
saved from painter because it does respect transform properties of all
previously applied clip rectangles.
Here .to_string() was being called, which gives an ErrorOr<String>,
then .value() was called on that without any checks. Cases like this
should at least be .release_value_but_fixme_should_propagate_errors()
which makes it clear the error is ignored, but here it's easy to
propagate.
This was converted to an enumeration for Intl.NumberFormat V3 in commit
33698b9615, but the default value was not
updated (and it's a bit surprising it compiled at all, given that this
is an 'enum class').
Besides from a general check if a file's directory has write
permissions, this also checks if the directory has set a sticky bit,
meaning that only file owners and the directory owner can remove or move
files in such directory. It's being used in /tmp for example.
This is the same address that the x86_64 kernel runs at, and allows us
to run the kernel at a high virtual memory address. Since we now run
completely in high virtual memory, we can also unmap the identity
mapping. Additionally some changes in MMU.cpp are required to
successfully boot.
Since we link the kernel at a high virtual memory address, the addresses
of global variables are also at virtual addresses. To be able to access
them without the MMU enabled, we have to subtract the
KERNEL_MAPPING_BASE.
Compile source files that run early in the boot process without the MMU
enabled, without stack protector and sanitizers. Enabling them will
cause the compiler to insert accesses to global variables, such as
__stack_chk_guard, which cause the CPU to crash, because these variables
are linked at high virtual addresses, which the CPU cannot access
without the MMU enabled.
This is a separate file that behaves similar to the Prekernel for
x86_64, and makes sure the CPU is dropped to EL1, the MMU is enabled,
and makes sure the CPU is running in high virtual memory. This code then
jumps to the usual init function of the kernel.
This was previously hardcoded this to be the physical memory range,
since we identity mapped the memory, however we now run the kernel at
a high virtual memory address.
Also changes PageDirectory.h to store up-to 512 pages, as the code now
needs access to more than 4 pages.
As the kernel is now linked at high address in virtual memory, we cannot
use absolute addresses as they refer to high addresses in virtual
memory. At this point in the boot process we are still running with the
MMU off, so we have to make sure the accesses are using physical memory
addresses.
This function will be used once the kernel runs in high virtual memory
to unmap the identity mapping as userspace will later on use this memory
range instead.
And use it the code that will be part of the early boot process.
The PANIC macro and dbgln functions cannot be used as it accesses global
variables, which in the early boot process do not work, since the MMU is
not yet enabled.
