this allows UIs to know that this is really okular and may show okular
instead (considering the generators are nodisplay=true)
specifically this allows the xdg-desktop-portal-kde to show okular in
its appchooser dialog even though the actual mimetype match happend
against (e.g.) okularApplication_pdf.desktop and is NoDisplay
(mobile curious has inconsistent naming, the main desktop file is
definitely org.kde.okular.kirigami.desktop)
Better enforce them now, so that the work to port doesn't increase over
time
Not a super fan of this for regular applications, but oh well the ship
has sailed
If an image URL contains a non-ASCII character (e.g. `kartöffelchen.jpg`), the html returned by the markdown parser contains the encoded path `kart%C3%B6ffelchen.jpg`. We must decode the path before checking if the image file exists.
(cherry picked from commit 8aa96484da)
If an image URL contains a non-ASCII character (e.g. `kartöffelchen.jpg`), the html returned by the markdown parser contains the encoded path `kart%C3%B6ffelchen.jpg`. We must decode the path before checking if the image file exists.
We do that by:
* Remembering all the generators we're building
* Linking the dependencies of all those generators against the app
For that to work we do three things:
* Move the creation of the app target to after the generator targets
have been created
* Have a global variable that lists all the created generators
* Move the find_package of the generator dependencies to the top level
so it can be used from the mobile app target
This is part of 451985 the other part is that KF5.91 windows build of
khtml was broken, seems the 5.92 one is good, so once we release 22.04.0
it should be all good hopefully.
BUGS: 451985
QLinkedList is gone from Qt6
The 1:1 port is std::list but we don't need iterator stability on
removal/insertion so just port to QList (one case to std::vector since
QList needs a copy constructor)
QLinkedList is deprecated in later Qt5 and gone in Qt6
The 1:1 port is std::list but in this cases all we ever do
is create the lists, push back to them, and pass then around
to be read, for that a QList is more than enough
After fixing the porting mistake done in 78d983ee, `drawRoundedRect` can
be further simplified to not use any relative sizes anymore.
We can also assume that the code in `dviRenderer::epsf_special` was
supposed to use a constant corner radius and therefore was wrong
initially. By dropping `Qt::RelativeSize` the code might become closer
to its originally intended behavior.
Test Plan:
- No change in behavior for rounded corners of "Welcome" popup message
and "No Annotations" message in sidebar.
- Could not test DVI code path.
78d983ee led to some rounded corners in the UI not being perfectly
circular anymore: Popup messages would stretch the rounding depending on
message length, and the rounded corner of the message in the annotation
bar would get distorted while changing the sidebar's width.
That commit tried to fix the following `warning: ‘void
QPainter::drawRoundRect(int, int, int, int, int, int)’ is deprecated:
Use drawRoundedRect(..., Qt::RelativeSize)` by changing to
`drawRoundedRect`, but missed to also add `Qt::RelativeSize`.
Adding the missing flag fixes both issues. The change is also
implemented in `dviRenderer::epsf_special` (introduced in be544056,
changed in 55dc43bf) for correctness.
Test Plan:
- Start Okular. The "Welcome" message and the "Document Loaded"
message have perfectly rounded corners again, not depending
on message length.
- Change width of the annotations sidebar: The "No Annotations"
message does not change its rounded corners anymore.
- Running in HiDPI mode retains the correct behavior.
- Note: There does not seem to be a trivial/convenient way to trigger
the DVI code path.
epub_open wants an utf8 in Windows
It probably also wants utf8 in Linux, but the qPrintable already gives
us an utf8 in most of the normal Linux locales, so don't touch that
BUGS: 448274
Turns out some files contain images saved in the xps archive as a directory containing multiple pieces, the first one being the image itself and the second one being empty.
Of course this is quite a weird way to save an image, but it seems that it still is valid and other viewers are able to load it correctly.
This change fixes the loading of multipiece images.
(cherry picked from commit 3506fb2ea8)
Turns out some files contain images saved in the xps archive as a directory containing multiple pieces, the first one being the image itself and the second one being empty.
Of course this is quite a weird way to save an image, but it seems that it still is valid and other viewers are able to load it correctly.
This change fixes the loading of multipiece images.
e.g. the ones in poppler issue 824
The PDF spec doesn't say (or I couldn't find it) how a user entered
string is converted to the byte array needed for password checking, so
we try both latin1 and utf8
I'm going to need to break binary compatibility to add a new feature
so may as well cleanup all the TODOs regarding that
Changes:
* Moving a few destructors to the header
* Removing a few unnecessary & in params
* Adding a few necessary & in params
* Making print return an enum instead of a bool and then having another
function that returns the enum
* Make Generator::requestFontData be a virtual
* Remove unused enum
* Remove a few filePrinter unneeded functions
* Remove unused TextDocumentGenerator::addMetaData signal
If we have code like <a><img></a><a><img></a> and the img has alt text
The old code did
remove image
insert alt text
but when we remove the image, the qtextdocument says
"i don't need the <a> anymore since there's nothing inside"
and then everything breaks because the layout has changed and we're
iterating over "unexisting" text blocks
So instead we just insert the alt text and
since we have selected the image with the cursor it will
replace it correctly
BUGS: 444971
By using Poppler 20.10 new custom image stamps APIs
Instead of the incompatible hack we used before that only worked for Okular.
This is done by modifying the update function used by PopplerAnnotationProxy in order to load the image in
the correct dimensions and send it to the poppler-Qt5 frontend.
We temporarily store the stamp annotation appearance when deleting it so that we can set it again when doing an undo undo.
This is sub-optimal since will not check if the certificate has been
revoked but is more privacy friendly since doesn't leak to the
certificate authority server that you're trying to validate a given
certificate
Okular implements various print scaling options that require the use of
the "Force rasterization" feature or else they have no effect. However
this is not communicated in the UI anywhere or handled automatically,
leading to users being confused and frustrated when the print scaling
option they chose didn't work. It wastes paper too.
This commit causes the "Force rasterization" checkbox to become checked
automatically whenever the user selects a print scaling option that
requires it, and unchecked if they return to the default scaling mode
that does not require it.
BUG: 434247
FIXED-IN: 21.08.2
