The window by default showed port 993 with TLS unchecked, which was
slightly misleading as port 993 uses implicit TLS connections and
cleartext is on port 143.
This change also makes it consistent with the Mail app, as its fallback
value is also set to true.
With this, looking at page 2 of pdf_reference_1-7.pdf no longer crashes.
Why did it crash in the first place? Because due to this bug, CFF.cpp
failed to parse the font program for the font used to render the `®`
character. `Renderer::render()` adds all errors that are encounterd
to an `errors` object but continues rendering. That meant that the
previous font was still active, and that didn't have a width for that
symbol in its width table.
SimpleFont::draw_string() falls back to get_glyph_width() if there's
no entry for a character for a symbol. `Type1Font::get_glyph_width()`
always dereferences `m_font` in that method, even if the font has
a font program (and m_font is hence nullptr).
With the off-by-one fixed, the second font is successfully installed
as current font, and the second font has a width entry for that symbol,
so the problem no longer occurs.
There were two problems:
1. parse_compressed_object_with_index() parses indirect objects
without going through Parser::parse_indirect_value(), so
push_reference() / pop_reference() weren't called.
Manually call them, both for the indirect object containing
the object stream and for the indirect object within the
object stream.
2. The indirect object within the object stream got decrypted
twice: Once when the object stream data itself got decrypted,
and then incorrectly a second time when the object data within
the stream was read. To fix, disable encryption while parsing
object stream data (since it's already decrypted).
The test is from http://opf-labs.org/format-corpus/pdfCabinetOfHorrors/
which according to readme.md at the same location is CC0.
Xcode 15 betas 1-3 lack https://reviews.llvm.org/D135772, which fixes a
bug that causes trailing `requires` clauses to be evaluated twice,
failing the second time. Reported as FB12284201.
This caused compile errors when instantiating types derived from RefPtr:
> error: invalid reference to function 'NonnullRefPtr': constraints not
> satisfied
> note: because substituted constraint expression is ill-formed: value
> of type '<dependent type>' is not contextually convertible to 'bool'.
This commit works around the issue by moving the `requires` clauses
after the template parameter list.
In most cases, trailing `requires` clauses and those specified after the
template parameter list work identically, so this change should not
impact the code's behavior. The only difference is that trailing
requires clauses are evaluated *after* constrained placeholder types
(i.e. `Integral auto i` function parameter).
Using a special instruction to access global variables allows skipping
the environment chain traversal for them and going directly to the
module/global environment. Currently, this instruction only caches the
offset for bindings that belong to the global object environment.
However, there is also an opportunity to cache the offset in the global
declarative record.
This change results in a 57% increase in speed for
imaging-gaussian-blur.js in Kraken.
This counter is incremented whenever a mutating operation occurs
within the environment's set of bindings.
It is going to be used by GetGlobal instruction to correctly invalidate
cache when global declarative environment is mutated.
This prevents SVG elements referenced by "use" being repeatedly cloned
in many redundant cases. Pages that use a large svg "sprite" that then
is referenced many times with "use" elements would load extremely
slowly, or crash the page.
The `document_fully_loaded` event should use the adjective "completely"
so as to match the spec and code convention. See
`Document::is_completely_loaded` and `m_completely_loaded_time`.
I created this by typing "sup" into TextEdit.app on macOS 13.4,
hitting Cmd-P to bring up the print dialog, clicked the PDF button
at the bottom, changed Title and Author to "sup", clicked
"Security Options…", and checked "Require password to open document"
(with password "sup").
This file tests several things:
- It has a compressed stream as first object. This used to make the
linearization dict detection logic assert.
- It uses AES as encryption key using version 4 of the encryption
dict. This used to not be implemented.
PDF files can be linearized. In that case, they start with a
"linearization dict" that stores the key `/Linearized` and the value
`1`. To check if a file is linearized, we just read the first dict, and
then checked if it has that key.
If the first object of a PDF was a stream with a compression filter
and the input PDF was encrypted and not linearized, then us trying to
decode the linearization dict could crash due to stream contents being
encrypted, decryption state not yet being initialized, and us trying
to decompress stream data before decrypting it.
To prevent this, disable uncompression when parsing the first object
to determine if it's a lineralization dictionary.
(A linearization dict never stores string values, so decryption
not yet being initialized is not a problem. Integer values aren't
encrypted in encrypted PDF files.)
These three lines were added in commits 41d5531, 0f7a651 and 97aca8f all
the way back in June 2020, and went unnoticed until Lucas pointed this
out during my refactoring.
These too should be sorted alphabetically, as evidenced by the fact that
text/markdown was in there twice before this change. :^)
Also broke out tables of sufffixes and basenames we consider plaintext,
and sorted those alphabetically as well.
It makes far more sense to sort by the standard mime type strings,
rather than the ad-hoc variable names associated with each enumeration.
This way, the sort looks nicer, and also matches the corresponding
description enumerations in the file utility.
This enum used to store very precise state about the decoding process,
let's simplify that by only including two steps: HeaderDecoder and
BitmapDecoded.
