Fixes a bug that causes the extraction of a wrong bounding box:
If the request queue is not empty, signalPixmapRequestDone causes a new
pixmap request to be started, thus overwriting mPixmapGenerationThread's
mCalcBoundingBox before it is read by the if in the next line.
Now signalPixmapRequestDone is called after the bounding box is saved,
so that new requests are started only after all data from
mPixmapGenerationThread have been saved.
BUG: 257370
REVIEW: 105600
The call to FT_New_Face takes the address of the 'face' variable, whose type is a
typedef *something TF_Face;
The value of TF_Face (so a pointer to the properly filled font structure) s then
replaced inside the call of TF_New_Face; but when the latter function fails,
the value of 'face' is not reset and this leads to a crash in the distructor of
TeXFont_PFB.
So properly initialize TF_Face to 0, its address is valid, and the code works.
BUG: 303472
FIXED-IN: 4.8.5
(cherry picked from commit 99c4da2f9e)
This is especially useful if resetSearch is called because of a
document switch, because a search without results in the previous
document has no relation with the new one, and therefore keeping the red
background doesn't make sense.
Instead of directly killing the search in the core, emit a signal
caught by FindBar to tell its SearchLineEdit to reset the search
operation.
In this way, SearchLineEdit can set m_changed, and next time a new
search operation will be started, instead of attempting to use the
old one.
FindNext was early quitting because the previous search was a back search and thus never got to startSearch, now we call startSearch if m_changed
BUGS: 301248
FIXED-IN: 4.9.0
Previously it was cleaned in FIFO order
I also moved the pixmap selection logic in a separate function, that
will be needed in the next patches.
Note: This behaviour is yet not optimal for the thumbnails panel,
because it is allowed to be at a page different than the current
viewport
It actually serves three purposes:
a) Make sure all the values are there (this should be always true, but doesn't hurt making sure) because if SwapFree was there but SwapTotal was not, it'd be a mess
b) add up things in order so we don't underflow, currently the code did process stuff as it came in the file, and it happens that SwapTotal appears before SwapFree in /proc/meminfo so it actually did "MemFree:" + "Buffers:" + "Cached:" - "SwapTotal:" + "SwapFree:", which can underflow if "MemFree:" + "Buffers:" + "Cached:" < "SwapTotal:"
c) Do not underflow at all, so if "MemFree:" + "Buffers:" + "Cached:" + "SwapFree:" < "SwapTotal:" we return 0 correctly not a zillion of free memory
Aurélien you might want to update gwenviews copy of this code (there's a few other bugfixes we did a while ago you didn't update either)
CCMAIL: agateau@kde.org
BUGS: 291129
The only affected generator is poppler (because it's the only one with
saving support).
Since version 0.20, Poppler can save annotations to PDF. If the user is
using an older version, this patch warns him that annotations are not
saved.
as of Eugene Trounev sent them to me more than three years ago, just gz-compressing them now;
followup of b811186781
(apparently I forgot to commit them at that time)
It was "Note" before d2fa4c9, but it was changed to "Comment" for
compatibility reasons. Setting it to "Note", this time in UI code,
doesn't break d2fa4c9 and restores the default icon users are used to.
This patch makes sure that the file saved in the .okular file keeps
the original filename (and, in particular, the extension) even if the
user is re-exporting a .okular archive as .okular archive. Before this
patch, the file boundled in the .okular archive would be named like the
.okular file it was exported from (eg foo.okular instead of foo.pdf).
Note: Okular had no problems in reopening it, but advanced users
unpacking the ZIP file obtained a .okular file which is actually a
native file, and not an okular archive.
Script Kiddy
Fabio D'Urso
Luigi Toscano
Albert Astals Cid
Yuri Chornoivan
Pino Toscano