This change also adds non-deprecated text() and set_text() functions and
helper constructors for Button, CheckBox, and RadioButton to call the
strings directly.
The whole codebase at this point is still using the deprecated string
functions, which the class will quietly convert to a new String.
The first iteration has enough SIDs to display simple documents, but
when trying more and more documents we started to need more of these
SIDs to be properly defined. This is a copy/paste exercise from the CFF
document, which is tedious, so it will continue in small drops.
This commit fills all the gaps until SID 228, which covers all the
ISOAdobe space, and should be enough for most use cases. Since this is a
continuous space starting at 0, we now use an Array instead of a Map to
store these names, which should be more performant. Also to simplify
things I've moved the Array out of the CFF class, making it a simpler
static variable, which allows us to use template type deduction.
This doesn't appear to have had a measurable impact on performance,
and behavior is the same.
With the tiles using independent BooleanDecoders with their own
backing BitStreams, we're even one step closer to threaded tiles!
I went through all callers of adopt_own() and replaced them with
try_make<>() if possible or adopt_nonnull_own_or_enomem() else
in cases where it was easy (i.e. in functions already returning
ErrorOr).
No intended behavior change.
It's not needed in such case, and in the near-future when we would want
to use this utility in an initramfs environment where there's no service
such as LookupServer being running, it's still useful to have the option
to invoke this utility with the mentioned limited output functionality.
The curve data in lutAToBType and lutBToAType can store 'para' data, but
other than in the main ICC tag table, the size of the tag data isn't
explicitly stored. So it must be computed from the data contents.
Extract the function body into a helper can call that from both
variants.
The curve data in lutAToBType and lutBToAType can store 'curv' data, but
other than in the main ICC tag table, the size of the tag data isn't
explicitly stored. So it must be computed from the data contents.
Extract the function body into a helper can call that from both
variants.
It's not needed in such case, and in the near-future when we would want
to use this utility in an initramfs environment where there's no service
such as LookupServer being running, it's still useful to have the option
to invoke this utility with the mentioned limited output functionality.
This allows the logic for keeping track of whether to resume to the
paused or the playing state when exiting these states. The new
StartingStateHandler also uses the class, since it can also be paused
and unpaused while waiting for samples.
The pause/play actions on the handlers inheriting from the resuming
handler will also now notify the owner that the state has changed so
that it can change icons, etc.
The PlaybackStateChangeEvent wasn't connected up anymore, so the player
wouldn't change icons when stopping playback due to reaching the end of
the stream or encountering an error.
This new state handler will retrieve and display the first frame, while
ensuring that playback can start as soon as possible by buffering two
frames on top of the first frame for the PlayingStateHandler to set its
next frame timer by.
Previously, we assumed the timer was hitting at the correct time. This
meant that if we changed states and the previous state handler had
prepared a next frame, we would immediately display it without checking
the timestamp.
If we encounter an error in the video decoder, we can set a timestamp
for the error item in the queue so that it will display the error only
when the frame that caused the error would have been displayed.
Previously we had dispatch_decoder_error and on_decoder_error serving
the same function, with one not handling the end of stream properly.
There is also a new function to dispatch either an error or a frame to
the owner of this playback manager, so that PlaybackStateHandlers don't
have to duplicate this logic.
The way this was set up before, this function would return "true" if
the underlying stream had ended, which would cause us to try to read
past the end in some edge cases.
The PDF spec allows incremental changes of a document by appending a
new XRef table and file trailer to it. These will only contain the
changed objects and will point back to the previous change, forming an
arbitrarily long chain of XRef sections and file trailers.
Every one of those XRef sections may be encoded as an XRef stream as
well, in which case the trailer is part of the stream dictionary as
usual. To make this easier, I made it so every XRef table may "own" a
trailer. This means that the main file trailer is now part of the main
XRef table.
