Tuesday, March 07, 2017

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

Wednesday, March 01, 2017

Okular Form Field auto-updating (Work In Progress)

You can see it in https://www.youtube.com/watch?v=fCLFkpaW3Ug

As the description of the YouTube video says:

Form 14 updates from Form 13 values as defined by the PDF file.
There's a few bugs left:
* To make the page contents update i need to edit another form in the page of the form that is being auto updated
* The contents of the "editable" Form are not updated. (The form is actually not editable since it's readonly)

And also a pile of uncommited and unreviewed patches, and probably only works for very simple files like this one, but it's a start :)

Update: It works fine now and everything has been commited :) https://www.youtube.com/watch?v=S-zmHc3WUhs

Thursday, February 16, 2017

Wednesday, December 07, 2016

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.

Tuesday, November 15, 2016

Finding a valid build order for KDE repositories

KDE has been lately been growing quite a bit in repositories, and it's not always easy to tell what needs to be build before, do i build first kdepim-apps-libs or pimcommon?

A few days ago i was puzzled by the same question and realized we have the answer in the dependency-data-* files from the kde-build-metadata repository.

They define what depends on what so what we need to do is just build a graph with those dependencies and get a valid build order from it.

Thankfully python already has a module for graphs and stuff so build-order.py was not that hard to write.

So say you want to know a valid build order for the stable repositories based on kf5-qt5

Here it is

Note i've been saying *a* valid build order, not *the* valid build order, since there are various orders that are valid since not every repo depends other repos.

Now i wonder, does anyone else find this useful? And if so to which repository do you think i should commit such script?

KDE Applications 16.12 branches created

The dependency freeze for KDE Applications 16.12 is on since November 10

For all repositories part of the KDE Applications 16.12 release the Applications/16.12 branch has been created.

The list of modules+branches that will be part of the release is at https://cgit.kde.org/sysadmin/release-tools.git/tree/modules.git?h=Applications/16.12

Please make sure the list is correct. If it's not please email release-team at kde.org *NOW*

From now on master is open for feature changes, but remember that all your fixes also should get to the Applications/16.12 branch (my suggestion, commit fixes to Applications/16.12 and then merge that branch to master)

KDE Applications 16.12 Beta (version number 16.11.80) will be tagged November 17 at 23:59 UTC

Once the Beta is tagged no more features can be added.

Sunday, October 23, 2016