Okular: PDF Signature + Certificate support has landed

As of a few minutes ago, i merged the code from Chinmoy Ranjan Pradhan's GSOC to support showing PDF Signatures and Certificates in Okular.



Signature handling is a big step for us, but it's also very complex, so i expect it to have bugs and things that can be improved so testers more than welcome.

Compiling is a bit "hard" since it requires poppler 0.73 that was released a few days ago.

But thanks to flatpak, there's no need to compile it, you can run the KDE Okular Nightly on your system to try it

flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
flatpak remote-add --if-not-exists kdeapps --from https://distribute.kde.org/kdeapps.flatpakrepo
flatpak install kdeapps org.kde.okular

Note: if you have okular installed from another flatpak repo (for example flathub) this will switch you to the KDE Nightlies, you may want to switch back after testing.

And then you can try the adobe sample pdf
flatpak run --share=network org.kde.okular https://blogs.adobe.com/security/SampleSignedPDFDocument.pdf

And you should get stuff like this

Okular table selection mode is amazing

I case you didn't know ;)

Okular has a amazing table select mode where you select an area and Okular will auto detect rows and columns on it (you can fine-tune it afterwards) and then you can directly copy&paste to a spreadsheet :)

It's mostly tested on PDF files, but should work the same on any of the formats we support text extraction.

Update: This feature is not new, just i got to use it today ;) Video at https://www.youtube.com/watch?v=E8XWI06tltY

The dangers of stable/LTS/supported versions

Ubuntu 14.04 LTS is supported until April 2019 and ships poppler 0.24.5 http://packages.ubuntu.com/search?suite=trusty&searchon=names&keywords=libpoppler-dev

RHEL 7.3 ships poppler 0.26.5 (I may be wrong, https://git.centos.org/summary/?r=rpms/poppler is the best info i could find, Red Hat does not make easy to know what you're buying)

Debian stable (Jessie) ships poppler 0.26.5 https://packages.debian.org/search?suite=jessie&searchon=names&keywords=libpoppler-dev

Current release is poppler 0.49 https://poppler.freedesktop.org/releases.html

This means that people are running stable versions and thinking they are secure, but if we trust security specialists, [almost] every crash can be exploited, and I'm almost sure neither Ubuntu nor RedHat nor Debian have backported all of the crash fixes of the more than 20 releases and 2 years of development behind those *very old* versions they are shipping.

I don't know how/if this can be fixed, but i honestly think we're giving users a false sense of security by letting them run those versions.

No one "works" on Poppler

I thought that was obvious, but today someone thought that i was "working" as "paid working" on it.

No, I don't get paid for the work i do on Poppler.

It's my computing hobby, and on top of that it's not even my "primary" computing hobby, lots of KDE stuff take precedence over it, and i guess Gnome stuff may also take precedence for Carlos (second top commiter according to the git shortlog)

Aside a few paid contributions and some patches that may have come from people that use the software on their business (and we could file them under "paid" since they did the fix as part of their job) no one has a paid job that is mainly "work on poppler".

I guess we've done a good enough job as hobbyist :)

Obviously we could do better, so if you have lots of money and are interested in making free software PDF rendering beter please hire someone to help us (no, this is not me asking for money, I've a good enough job already).

And if you don't have money but you have some free time and like to help, join us :)

And if you really really have some free time or lots of money you could port Okular, Evince et al to pdfium and see if it's actually better/worse than poppler.

4.9.0 is out!

Yay! I'm so happy that we got it out of the door, 4.9.x is going to be amazing :-)

Personally I'd like to thank Fabio d'Urso for being my new Okular co-developer (actually he did more commits than me, but don't tell anyone) and implementing the store annotations to pdf files feature both in Okular and in poppler. Fabio you rock :-)

Some Okular testing, please?

There are three newsworthy things today in Okular world:
* Michel Ludwig merged into master the branch he had been developing to help him use Okular better from Kile. This should had no impact in regular Okular users but as this is a biggish change it would be great if you all master branch okular users update, recompile and complain if you see any regression
* I committed a patch that will make the UI more responsive on opening for documents whose pages are slow to render. There is no real speedup, but the fact that you have the UI up and running sooner is nice. Again this should be pretty innocuous but if you run master and see any new weird thing on opening files let us know.
* I created a new branch named kill_poppler_thread whose only commit removes a lot of code from the PDF/poppler backend that is not needed anymore since there is now generic code that provides the threading functionality that code had. This should also be innocuous but i am a bit hesitant of merging it into master so it would be cool if some that use okular with PDF files intensively switched to the kill_poppler_thread and verified everything works as it should. If you do, please tell me and it will make my decision of whether merging into master or not easier.

Poppler 0.18.0 released

Poppler 0.18.0 is here! It took 9 months and was delayed around 3 months because of my infamous laptop dead but I was finally able to release 0.18.0 today.

The changes are too big to explain in detail (12000 lines changed in 236 files) but I'll give a few highlights:
* General speed improvements
* Quaility and speed improvements in the Splash renderer (used by Okular)
* Quaility improvements in the Cairo renderer (used by Evince)
* Better Annotation support
* Better Form support
* Introduction of pdftocairo, a command line utility that uses the Cairo renderer to render pdf pages to png, etc.
* Introduction of pdfseparate, a command line utility that extracts pages of PDF files
* Introduction of pdfunite, a command line utility that can merges multiple PDF files into a single one
* Removal of pdftoabw as it was unmaintained
* Removal of the Qt3 frontend as it was unmaintained

You can have a look at the full changelog going to the Poppler releases page and having a look at the changes of 0.18.0, 0.17.4, 0.17.3, 0.17.2, 0.17.1 and 0.17.0

Poppler-Symbian pdf viewer

So yesterday, i grabbed poppler, freetype and Qt sources and in 45 minutes hacked together a proof of concept PDF viewer for symbian. Pretty cool if you ask me, the ugly side is that if i ever get some more work on it and want to get it into OVI store I need to pay 50€ to register into it and around 200€ more to get the app to go through Symbian signed, of course what i'm not going to do is spend 250€ to get a free app into OVI store, on the other hand i could of ask for some € for the application (3€?), but i'm not sure it's a good idea either.

Okular, PDF and file permissions

There seems to be some controversy about how Okular handles file permissions (sometimes called DRM) in PDF files. I will put here my personal opinions (weird i have to say this since this is *my* blog so when i write here it's always *my* personal opinion).

As a note for those that don't know me much, i was KPDF maintainer from 2004 or so till it's death, mentored the SoC project that created Okular, a regular Okular developer and i'm also the maintainer of poppler since a few time ago, so well, i think we'll agree i know what i'm talking about ;-)

Let's analize the bug-reporter sentence:

"So what I want to know is: why are people putting code into Debian
that limits our freedom? Why are people putting such code into KDE?"

So he wants to KNOW why *we* did this, yet he mails Debian bug tracker. First weird thing man, we have the okular irc channel, the okular mailing list and the kde bug tracker, all this are MUCH BETTER places for knowing.

First question:
"why are people putting code into Debian that limits our freedom?"
is very similar to
"why is people coding in GPL that that limits our freedom?" from the BSD fanboys. It all boils down to your freedom ends where other people freedom starts. And someone freely decided he doesn't want you to copy his PDF, you may hate him for that, but it is his freedom, *his* license, and we all like people respecting our license (GPL) so we should respect others, or are we just going to respect licenses we like?

Second question:
"Why are people putting such code into KDE?"
because it's what the PDF specification says and we want to have a PDF reader, don't we?

Now, there's even a LWN article talking about it (sorry folks, you have to pay them to read that unresearched article), but i'll quote here a small part (under the fair quotation law i hope)

Applications which do implement this "feature" tend to disable it by default.

he means evince has it disabled by default and okular enabled by default? I don't see a "tend to" here

Perhaps this behavior is result of the relative newness of this application; as it accumulates more users, the pressure for more user-friendly behavior is likely to grow.

KPDF had the exact very same behaviour since 2005. And well, if Okular is not called KPDF in KDE 4 it's just because we decided to support more formats but for the rest it's the same program.

Linux, at all levels, has felt free to ignore standards when following them makes no sense.

Repeat with me Okular is not Linux, Okular is KDE, Okular runs in Linux, Okular runs in Solaris, Okular runs in FreeBSD, Okular runs in Windows, Okular runs in Mac OS X.

And now my final words. I hate DRM, i don't buy DRM enabled things (or try as hard as i can not to) BUT KDE is not the place to protest about that. The place to protest against that is with your wallet (don't buy DRM'ed things), with your vote (don't vote politicians that pass pro-DRM laws) or even in the streets in demonstrations.

Looking for PDF with Japan2 fonts

The other day we realized poppler did not correctly supported Adobe-Japan2 fonts, so i went on and did some work that should make it work, but then i have no file to test, so if you could do

cd /
find -name "*pdf" -exec grep -H Japan2 {} \;

or

locate -0 .pdf | xargs -0 -n 1 grep -H Japan2

and send me (aacid@kde.org) a link to the pdf or the file pdf itself of all the files that match i could try to see if i did really fix it or not :-)

Poppler 0.7.1 (0.8 Beta 2) released

Available from
http://poppler.freedesktop.org/poppler-0.7.1.tar.gz

This is the second release of what will be the 0.8 stable series. We will be having a roughly weekly release schedule until we hit 0.8 stable version. Target is March 19 for 0.8.0

Major Changes:
* Really distribute CMake files as optional build tool
* Initial Optional Content support in core and in the Qt4 frontend

Minor Changes:
* Allow grouped checkboxes to be selected individually
* Qt4 demo program improvements
* Keep cairo and cairo_shape consistent
* Safety checks on Splash renderer so that it does not draw outside the
allocated bitmap
* Do not try to display bitmaps of invalid size
* Fix building with exceptions
* Improvements for building with MSVC and CMake

Testing, patches and bug reports welcome.

You've got to love Free Software developers

So one fellow poppler developer tells me he his having problems with a new code he is developing and a PDF created by scribus and asks for help to see if it's a problem on scribus or on poppler code. I have a look at the spec and the pdf and reach the conclusion that it's their fault, so i go into the #scribus IRC channel speak there with their nice developers, i convince them that it's a bug, and 10 hours later the bug is fixed. This rocks :-)