KDE Gear 22.08 branches created

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

https://community.kde.org/Schedules/KDE_Gear_22.08_Schedule
 

The KDE Qt5 Patch Collection has been rebased on top of Qt 5.15.5

 

Commit: https://invent.kde.org/qt/qt/qt5/-/commit/2ab84b12b09a6c642d7c16de392d85bbcd49bb6a

 

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.

 

The 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 [1] [2] [3] [4] and the Free Software users will never be affected by those!

KDE Gear 22.08 release schedule finalized

This is the release schedule the release team agreed on

https://community.kde.org/Schedules/KDE_Gear_22.08_Schedule

Dependency freeze is in five weeks (July 7) and feature freeze one after that. 

 

Get your stuff ready!

Akademy 2022 Call for Participation is open

The Call for Participation for Akademy is officially opened!

...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 akademy-team@kde.org

The KDE Qt5 Patch Collection has been rebased on top of Qt 5.15.4

Commit: https://invent.kde.org/qt/qt/qt5/-/commit/5c85338da3c272587c0ec804c7565db57729fd48

 

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!

Poppler finally has support for embedding fonts in PDF files!

 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.

Long answer:

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

Before

 

Now

  

Signing a PDF file with my name being "Albeŋŧ As漢tals Ciđ"

Before

 

Now

 

 

Writing hola↓漢字 in a Text Annotation

Before

 

 Now

Okular: Signature support now works on Android

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.

I added a way for Craft to build NSS for Android and told it to not disable NSS when building poppler for Android that should have been all.

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?