Monday, May 23, 2022
...and closes relatively shortly! Sunday the 12th of June 2022
You can find more information and summit your talk abstract here: https://akademy.kde.org/2022/cfp
If you have any questions or would like to speak to the organizers, please contact email@example.com
Saturday, May 14, 2022
Commercial release announcement: https://www.qt.io/blog/commercial-lts-qt-5.15.4-released
OpenSource release announcement: https://lists.qt-project.org/pipermail/development/2022-May/042437.html
I want to personally extend my gratitude to the Commercial users of Qt for beta testing Qt 5.15.4 for the rest of us.
The Commercial Qt 5.15.4 release introduced some bugs that have later been fixed. Thanks to that, our Patchset Collection has been able to incorporate the reverts for those two bugs that affected Android and Windows and the Free Software users will never be affected by those!
Friday, April 29, 2022
Why would you want to embed fonts in PDF files are you probably asking yourself?
Short answer: It fixes issues when adding text to the PDF files.
Poppler has had the feature of being able to fill in forms, create annotations and more recently add Digital Signatures to existing PDF files.
This works relatively well if you limit yourself to entering 'basic' ASCII characters, but once you go to more 'complex' characters, things don't really work, from the outside it seems like it should be relatively simple to fix, but things related to PDF are never as simple as they may seem.
In PDF each bit of text is associated with a Font object. That Font generally only supports one kind of text encoding and at most 'only' 65535 characters (65535 may seem a lot, but once you start taking into account non latin-based languages, you quickly 'run out' of characters).
What Poppler used to do in the past was just save the text in the PDF file and say "This text is written in Helvetica font", without even really care to specify much what 'Helvetica font' meant, and then let the PDF viewer (remember when we save the PDF file, it will not only be rendered by Poppler again, but potentially by Adobe Reader, Chrome, Firefox, etc.) try to figure out what to do with that information, which as said usually didn't go very well for the more 'complex' characters.
What we do now is for each character of new text that we add to the file is we make sure to embed a font for it. So if you're writing something like 'holaħŋ↓' we may end up adding a few fonts to the PDF file, and then instead of saying 'This is the text and it's in Helvetica, good luck', we will say something like 'This text is characters 4, 67, 83 and 98 of embedded Font X, characters 4 and 99 of embedded Font X2 and character 16574 of embedded Font X3'. This way when the file is opened by a PDF viewer it is 'very easy' for them to do the right thing and show what we wanted.
Enough of technical talk! Now some screenshots to show how this has been fixed for Text Annotations, Forms and Signatures :)
Writing "hello↓漢you" to a form
Signing a PDF file with my name being "Albeŋŧ As漢tals Ciđ"
Writing hola↓漢字 in a Text Annotation
Monday, March 07, 2022
This is a continuation of https://tsdgeos.blogspot.com/2022/02/okular-signature-verification-user.html
In that blog what was introduced was the new user interface to be able to see digital signatures in the mobile interface (i.e. the one that uses Kirigami instead of QWidgets).
You can use the Okular mobile interface anywhere you want, it's not really mobile-only, it's really mobile-optimized, so you can try it (though you'll have to build it manually since most distributions don't build it by default) on desktop Linux too.
Anyway, in that previous blog I talked about introducing the new user interface to be able to see digital signatures, and that worked out of the box in places that provide NSS like desktop Linux or Plasma Phone distributions (Aleix tried on the PinePhone and confirmed it works), but for Android it still did not work.
What was needed was something very similar to what we did for Windows https://tsdgeos.blogspot.com/2022/02/okular-signature-support-now-works-on.html but this time for Android.
But things are never simple enough...
For Android we use a tool called androiddeployqt, it is a tool that gathers everything needed for your project and creates the APK file for it. Unfortunately it has a documented limitation with runtime plugins, it has no way to know they are needed so they are not packaged. NSS unfortunately has plugins, so after some "why is this crashing?" hours of scratching my head and debugging i realized the problem was the missing plugins were not being "installed".
The workaround to make androiddeployqt work for plugins is basically linking the plugins to your binary, this way the plugin is a clear dependency and gets packaged, but did I say things are never simple enough?
In KDE we have binary-factory continuous integration for Android and we also have gitlab continuous integration for Android, unfortunately they use different ways of building, the first uses Craft, the second does not. This means that in gitlab CI the NSS library is not available, so I can't link to it, but i need to link to it so that Craft on the binary-factory CI creates the APK files correctly.
To try to resolve that I came up with a patch that tried to differentiate if we were building inside Craft or the gitlab CI unfortunately while that worked on my local setup it did not work on the KDE servers, so at the end I resolved for a much more pedestrian way, there's an option to enable the extra libraries and Craft enables that option when building Okular
So after that, yes, it works as you can see in the screenshot below :)
|Signature Properties User Interface|
If you want you can download the Okular APK from https://binary-factory.kde.org/job/Okular_Nightly_android-arm64/ but beware there are still some limitations that don't make Okular usable day-to-day for Android, so we've created a Google Summer of Code potential project for that, maybe you're interested?
Sunday, March 06, 2022
KDE produces amazing software, but sometimes not everyone can use it.
One of the reasons that can happen is because it's not translated to a language they understand.
For that we are calling for translators, specially for the languages listed below which had not had a single translation update in the last year [*].
Committing to help means that you will do some work every now and then, not just translate a few texts only.
We will help you learn the tools needed and hopefully if you know more people that can help you can grow a team :)
If you're interested please email me at firstname.lastname@example.org
[*] apologies if indeed there were translations and my script failed for some reason
Friday, February 18, 2022
Okular has two user interfaces, you can control which one you get when compiling okular by setting the OKULAR_UI cmake variable to desktop (the default) or to mobile (which you can build just fine on the desktop too, there's nothing "mobile only" in it).
The mobile one is built on top of Kirigami and is more oriented to use with touch screens. It also has fewer features, for example, you can't add annotations nor fill forms. I could say it's less likely you need those features on a mobile form factor but that's less and less true as time goes and computing shifts to mobile devices, but that's a story for another day.
One of the features that was missing until today is the user interface parts related to Digital Signature verification, that is, those parts that say if a PDF is signed, if the signature is valid, let you see the certificate, etc.
Now the same as with the desktop version, you get
the "This document is signed" (and it's variations) banner
The Signature tree on the sidebar/drawer
The Signature properties dialog
And the Certificate properties dialog
The last two are not super great looking but there's not much more you can do when you have to dump lots of data to the user.
Friday, February 04, 2022
Since a few hours ago the Okular version available in the Microsoft Store for Windows has the same signature support than the Linux/FreeBSD versions.
Some screenshots, though it's nothing impressive, it's the same User Interface that we already have had for a while
|A file I just signed, showing the Signature and Certificate panels|
|The PDF backend settings|
This "new feature" has been delivered with the update of the just released Okular 21.12.2.
The interesting part is that adding Signature support for Okular on Windows didn't actually require *any* change in Okular itself, its code was already good.
What we needed was to add NSS  to Craft  and also some tweaks to poppler , because sadly NSS doesn't behave exactly the same on Linux than on Windows, and once that was in, just start Okular again and voilà everything was working as expected :)
Relevant Merge Requests:
 NSS = the library poppler uses for signature support
 Craft = the meta build system we use for building KDE software on Windows
 poppler = the library that Okular uses for PDF support
Thursday, January 27, 2022
It is available at the usual place https://community.kde.org/Schedules/KDE_Gear_22.04_Schedule
Dependency freeze is in six weeks (March 10) and Feature Freeze a week after that, make sure you start finishing your stuff!
Monday, January 24, 2022
Up to today, Okular would kind of error out when opening a PDF file that contains a signature field that was unsigned (think like the old space in paper forms saying "sign here")
It would tell you "document is signed but can't be properly validated"
And that was it, you couldn't do much with the signature. When you tried to "see" it all the fields would be default like "Signed at 1 Jan 1970", etc.
With the new code we properly detect that there are unsigned signatures and we offer to sign them when interacting with it
Relevant merge requests: