Make sure you commit anything you want to end up in the KDE Gear 22.08
releases to them
We're already past the dependency freeze.
The Feature Freeze and Beta is this Thursday 14 of July.
More interesting dates
August 4, 2022: 22.08 RC (22.07.90) Tagging and Release
August 11, 2022: 22.08 Tagging
August 18, 2022: 22.08 Release
Tuesday, July 12, 2022
Make sure you commit anything you want to end up in the KDE Gear 22.08
Sunday, June 19, 2022
Commercial release announcement: https://www.qt.io/blog/commercial-lts-qt-5.15.5-released
OpenSource release announcement: https://lists.qt-project.org/pipermail/development/2022-June/042659.html
I want to personally extend my gratitude to the Commercial users of Qt for beta testing Qt 5.15.5 for the rest of us.
Commercial Qt 5.15.5 release introduced some bugs that have later been
fixed. Thanks to that, our Patchset Collection has been able to
incorporate the reverts for those bugs     and the Free Software users will never be affected by those!
Wednesday, June 01, 2022
This is the release schedule the release team agreed on
Dependency freeze is in five weeks (July 7) and feature freeze one after that.
Get your stuff ready!
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 firstname.lastname@example.org
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?