All posts by Christoph Cullmann

Dr.-Ing. Christoph Cullmann is a Senior Software Engineer at AbsInt Angewandte Informatik GmbH. His work is focused on static analysis of both binary and source programs and the WCET analysis of embedded systems. In his spare time, he works on the KDE project and maintains the Kate editor application and component.

Rendering issues and the power of open source

After a long time of constant distraction by my daily work, I finally found again a bit time to take care of KTextEditor/Kate/… issues.

One thing that really started to be an itch I wanted to scratch is some rendering fault that occur with ‘special’ font sizes.

Given I wanted to do again a bit work on the macOS port, I was really annoyed that on my screen the only application with text rendering issues was “my” one :/

I assume a lot of people have sometimes seen stuff like that in KTextEditor based applications like Kate or KDevelop:

These small white lines really stick out like a sore thumb 🙁 It looked like some off-by-one rounding issue, surely one should be able to find it…

I tried to track down where in our rendering in KTextEditor we do create these artifacts, but I never found any place that looks like a possible cause.

After a bit more tinkering it became obvious that actually it would be more or less impossible for the KTextEditor code to mess up the painting in such a way, as we normally draw one line more or less as one thing using QTextLayout that handles the painting of the selection background, too.

Using QtCreator as an non-KTextEditor based application that uses the Qt layouting & rendering it was possible to get similar effects on macOS (or X11):

:=) Good thing that Qt is open source. A quick look into the qtextlayout.cpp and a qt5 compile later, I was able to trace the issue down to some qFloor calls for painting the selections.

I hope my patch is correct and will be accepted (QTBUG-66036 / Gerrit 219804)  or at least helps others to do the correct fix.

At least for the syntaxhighlighter example shipped with Qt I was able to reproduce the issue before my patch but not afterwards.

Would Qt not be open-source, I would have been at the end of the line after seeing no “error” in our codebase in KTextEditor.

With Qt as some open-source project, it is a completely different story.

Besides, the Qt documentation for “how to build it” and “how to contribute” on the Qt Wiki are well enough to understand that I was able to nicely compile the stuff from scratch on macOS and provide the Gerrit review request in no time.

FirstAid – PDF Help Viewer

Hi,

in the recent months, I didn’t find much time to spend on Kate/KTextEditor development. But at least I was now able to spend a bit more time on OpenSource & Qt things even during work time in our company. Normally I am stuck there with low level binary or source analysis work.

For our products, we were in the need of some online help. As our documentation is delivered as PDFs generated by the tools of the TeX Live distro, a natural idea was to use some PDF viewer and integrate it more tightly in our software than just “open the manual at page 1”.

We did review PDF viewers out there, but most (like Okular) have too many dependencies to be just bundled with our product (or a license not permitting that).

Without bundling, we can’t ensure that the tight coupling is working, without starting to test the integration with X different viewers which more or less all need other kinds of command line arguments to open the right page or even lack that feature or will not reuse an already running instance, ….

Therefore, as our GUIs are developed with Qt anyways, we did take a look at libpoppler (and its Qt 5 bindings), which is the base of Okular, too.

Easy enough, taking the small demo program shipped with the library and adding a small stdin based interface to tell it “goto <named reference>” we arrived at some small PDF viewer that is fit enough for our use case.

We named the thing “FirstAid”, the sources can be grabbed at github.com/AbsInt/FirstAid. Like libpoppler and the demo, its licensed as GPLv2+.

As already the README states, the aim of this small project is not to replace some full fledged viewer like Okular, the design goal is to have a small viewer that is auto-started by some host application and will jump to the requested labels for a tightly coupled online help. It can be used as a pure standalone PDF viewer, too, but that is more intended for testing it e.g. on the documents that should later be shown as online help.

FirstAid

I already annoyed Albert with some small issue I had with libpoppler, perhaps I will provide more useful fixes in the future if more things come up during FirstAid development. In any case, already THANKS A LOT for the Qt 5 bindings around libpoppler, they work nicely for us!

I really think this small project shows the benefit of OpenSource: We needed a PDF viewer, we were able to create a small one in less than a month based on OpenSource libraries and we can give back the results to the community (if it is useful for others is a different story, but perhaps other people have the same itch to scratch, if not, ignore it). I hope more possibilities for such things come up at work in the future.

For building: It should build out of the box if you have some recent Qt and libpoppler-qt5-dev installed, at least the Travis CI is able to build it out of the box with the given config. For me, it shows some small bugs if used with Qt 5.6/7 compared to the Qt 5.8 Beta I used here for testing.