Bug 25240

Summary: Cairo backend for Qt4 wrapper
Product: poppler Reporter: Paul Gideon Dann <pdgiddie+freedesktop>
Component: qt4 frontendAssignee: poppler-bugs <poppler-bugs>
Status: RESOLVED MOVED QA Contact:
Severity: normal    
Priority: medium CC: 4pfq30f5e8ee, freedesktoporg, jeff, karl, kjslag, m.weghorn, preining, r9ku1q, realnc, samjnaa
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: Splash top, Cairo bottom
Which is which? Which rendering you like more, top or down?
Splash vs Cairo-LCD
Specific page attached

Description Paul Gideon Dann 2009-11-23 03:47:39 UTC
Splash has served Poppler very well, but I believe most will agree that it's starting to show its age.  In my opinion, this is made particularly apparent in Splash's inability to render fonts on a subpixel level.  I tried my hardest to fix Splash to allow this, but grayscale fonts are a deeply embedded concept in Splash, and I eventually gave up.

On the other hand, it seems that most current effort is going into the Cairo backend, which is used by the GTK2 wrapper (e.g. Evince), and it's certainly possible to enable subpixel-rendered fonts in the Cairo backend (see #3307).

My proposal is to introduce support for the Cairo backend to the Qt4 wrapper, so that Qt-based viewers (such as Okular) may be able to benefit from future enhancements of the Cairo backend, especially subpixel-rendering.  I created a patchset to add the Cairo backend to the Qt4 wrapper; it may be found here: http://github.com/giddie/poppler-qt4-cairo-backend.  I am only suggesting the merging of patches 1 and 2 to Poppler; the remainder of the patches are simply hacks to force subpixel rendering, but once the Cairo backend is merged, it will be possible to add more elegant support to the client applications to enable or disable subpixel rendering.

It has been suggested that adding a dependency on Cairo to a Qt application is a controversial step.  Please bear in mind that the Qt wrapper will only provide an interface to the Cairo backend if Cairo support has been enabled at compile-time, and Qt applications are free to choose between backends at run-time.  It seems unlikely that anyone would be inconvenienced by the addition of the *option* to use Cairo.
Comment 1 Albert Astals Cid 2009-11-23 05:26:06 UTC
I already told you no on the mailing list, what made you think that using the bugzilla would give a different result?
Comment 2 Paul Gideon Dann 2009-11-23 05:38:17 UTC
Well, there are two reasons:

1) Opening a bug is a more formal suggestion, and provides a more permanent forum for discussion.
2) I'm hoping that other people interested in this feature might come out of the woodwork and vote for inclusion of this feature.

Maybe it'll take some time, but I think interested people will find this bug and post a comment, which may help persuade you and others that this is a worthwhile feature.  If not, the bug will die, never to be heard of again.

It wasn't my intention to undermine or insult you by posting here; I'm just hopeful that it might prompt others to chip in.
Comment 3 Freddie Witherden 2009-12-29 12:10:32 UTC
Created attachment 32362 [details]
Splash top, Cairo bottom

I hate to add `fuel to the fire' but attached is a comparison between the Splash and Cairo backends. The PDF in question was the TeXBook (source in most TeX distributions).

It seems foolhardy to reject a patch on account that some people may mistakenly enable the functionality with which it provides and then later complain about it. Distributions will enable support for Cairo not because it sounds 'new' or 'cool' but because it provides results of an objectively superior quality. Nearly all desktop distributions ship with at least one copy of Cairo; one would be hard pushed to find a system without it.
Comment 4 Albert Astals Cid 2009-12-29 12:40:31 UTC
There is something wrong in your system, i get very similar renderings in both cairo and splash.
Comment 5 Albert Astals Cid 2009-12-29 12:42:11 UTC
Created attachment 32363 [details]
Which is which? Which rendering you like more, top or down?
Comment 6 Paul Gideon Dann 2009-12-29 14:07:46 UTC
I couldn't say for sure which is which, but I'd say the bottom one looks better to me.  It also looks like it's rendering a little larger than the top one, which may affect the quality.
Comment 7 Paul Gideon Dann 2009-12-29 14:11:29 UTC
Created attachment 32364 [details]
Splash vs Cairo-LCD

However, this proposal isn't just about Splash backend vs Cairo backend.  I'm sure we all must agree that Cairo with subpixel-rendering is easier to read that plain Splash.

Splash at the top; Cairo w/ Subpixel rendering at the bottom.
Comment 8 Albert Astals Cid 2009-12-29 14:27:37 UTC
CairoOutputDev doesn't have subpixel rendering at the moment, you should start by that.
Comment 9 Freddie Witherden 2009-12-29 14:30:03 UTC
Created attachment 32367 [details]
Specific page attached

The PDF I am using was produced circa 2003. I have a load more documents, produced in a similar time frame (2003-2005) by TeX, by myself and others, which exhibit this nasty behavior under Splash but not Cairo. There are enough PDFs like this floating around that make the Splash backend *very* hard to use.

Also worth pointing out that the bottom rendering (Cairo) in Splash vs. Cairo benefits from y-axis hinting -- which is not available by default (one needs to explicitly patch the Cairo backend to enable it).
Comment 10 Paul Gideon Dann 2009-12-29 14:46:45 UTC
@Albert => CairoOutputDev doesn't have subpixel rendering yet, no, but there's just no way to add subpixel rendering to Splash without redesigning significant portions.  The Cairo backend is clearly the future, and when future improvements are made to Poppler, it's through the Cairo backend that they'll come.  If the Qt4 wrapper is unable to make use of the Cairo backend, Okular will be forced to make do with a legacy engine as Evince enjoys the latest and best.  And for what reason?
Comment 11 Albert Astals Cid 2009-12-29 15:05:22 UTC
You have your opinions, everyone is entitled to have them. I disagree, and for now i'm the poppler maintainer. That's basically the end of the story, you can keep pressing and maybe you'll get me to step down from poppler maintainership. That will be for sure a win for us all, you'll get Cairo in the Qt4 frontend and i'll get more free time to have a real life.
Comment 12 James Cloos 2009-12-30 12:32:28 UTC
> Created an attachment (id=32367)
> Specific page attached

Note that the pdf uses type3 fonts from metafont-generated bitmaps.
(A more recent ΤεΧ install would likely use the type1 fonts, either
via pdftex or via dvipdfm.  That would avoid this issue.)

xpdf-302 shows the same rendering anomolies as your initial image.

I also get those anomolies from »pdftoppm -gray -aa yes« and somewhat
different x-height related anomolies from »pdftoppm -gray -aa no«.

(And at some point in my testing, *something* complained about the
fonts’ bounding boxes in that pdf.  But I cannot replicate that, so
I don’t know which app did that....)

But my poppler is almost a month old (compiled 12/01).  Perhaps the bug
was fixed since then?
Comment 13 Nikos Chantziaras 2010-05-11 10:23:51 UTC
Any news on that?  And is Albert Astals Cid still powertripping over this issue for no apparent reason other than "Qt sucks, let's snob it"?
Comment 14 Albert Astals Cid 2010-05-11 11:44:15 UTC
You are so intelligent that you decided to insult the maintainer to get the feature in, keep it up!
Comment 15 Nikos Chantziaras 2010-05-11 11:51:19 UTC
I don't want that feature in, really. Please keep Poppler clean of Qt junk.

Just wanted to express an opinion that's slowly forming-up all over the places about the infamous Poppler maintainer.
Comment 16 Albert Astals Cid 2010-05-11 12:02:42 UTC
Citation needed ;-)
Comment 17 Don Hopkins 2011-05-23 03:22:41 UTC
The citation you requested:

https://freddie.witherden.org/pages/font-rasterisation/#cid09

The two most popular PDF viewers under GNU/Linux, Evince (GTK+, GNOME) and Okular (Qt, KDE), are both frontends to the Poppler PDF rendering library. However, despite this, the two applications sometimes produce very different output for the same document. This is because the Poppler library has two rendering backends: a legacy one derived from the Xpdf 3.0 codebase (referred to as Splash) as used by Okular, and a newer Cairo backend which is used by Evince. While the output produced by the Cairo backend is generally of superior quality to that producd by the Splash backend, it is not currently possible to access the Cairo backend from Qt due to ‘toolkit politics’ Cid09.

Cid09
Albert Astals Cid
Cairo Backend for Qt Wrapper
http://lists.freedesktop.org/archives/poppler/2009-June/004855.html
FreeDesktop Bugzilla – Bug 25240
http://bugs.freedesktop.org/show_bug.cgi?id=25240
Comment 18 Albert Astals Cid 2011-05-23 11:29:20 UTC
Unfortunately you don't prove that Cairo has better rendering than Splash, try again?
Comment 19 Nikos Chantziaras 2011-05-23 12:10:18 UTC
(In reply to comment #18)
> Unfortunately you don't prove that Cairo has better rendering than Splash

Which doesn't really matter and is not the issue. The real issue is that the bug gets closed as WONTFIX even though it should have been closed as FUCKYOUHAHANOOBZIMAPOWERTRIPPIN.
Comment 20 Albert Astals Cid 2011-05-23 12:25:24 UTC
Yes, that convinces me, sure.

Wait, no, it does not.
Comment 21 Nikos Chantziaras 2011-05-23 12:33:02 UTC
Exactly. If the Big Man isn't convinced, nothing can happen. Bigotry at its finest.
Comment 22 Albert Astals Cid 2011-05-23 12:41:17 UTC
That's what maintainership is about, you do what you think it's best for the project, not what some random person screaming FUCKYOUHAHANOOBZIMAPOWERTRIPPIN says.
Comment 23 Paul Gideon Dann 2011-05-24 02:14:27 UTC
@Nikos => As much as I agree with you regarding the importance of this feature, I don't think you're helping matters by losing your cool.  I don't agree with Albert's decision, but he *is* the maintainer, and it's his responsibility to steer Poppler in the right direction.

I don't think Albert's going to be convinced by just two vocal advocates of this feature.  Hopefully, enough people will get involved to eventually convince him.

In the meantime, there's still work that could be done on the Cairo wrapper for Qt (available at https://github.com/giddie/poppler-qt4-cairo-backend).
Comment 24 Norbert Preining 2011-09-25 16:51:48 UTC
Just a small comment from one of the Debian maintainers seeing this game:
@Nikos: cool down, no need and no use to insult

@Albert: could you give an explanation *why* you decide like that? If you don't that might stir unrest (as it is doing) and might create forks. I see quite some activity on this issue. So please rethink your decision, or argue why you don't. But don't play the angry little boy that was stepped on the toes, there is no need for that behaviour.

Norbert
Comment 25 Albert Astals Cid 2011-09-25 16:59:18 UTC
Norbert, if you read comment #1 you'll see i gave my reasons on the mailing list, those interested can look them up. Nothing has changed since then.
Comment 26 Nikos Chantziaras 2011-09-25 17:45:51 UTC
(In reply to comment #25)
> Norbert, if you read comment #1 you'll see i gave my reasons on the mailing
> list, those interested can look them up. Nothing has changed since then.

No. You gave your reasons in comment 11:

"I disagree, and for now i'm the poppler maintainer. That's basically the end of the story"

Really awful reasons and against good open source practices and traditions.
Comment 27 Albert Astals Cid 2011-09-25 18:05:37 UTC
I really like you to explain why if you do not care about this feature neither about the poppler-qt frontend as you said in comment #15 why you keep harassing me.
Comment 28 Paul Gideon Dann 2011-09-26 02:42:29 UTC
I think comment #15 was intended ironically.

I do wonder, though: have you actually had a statement from, for instance, the Okular maintainer or anyone else in KDE about the political angle of (optionally) linking Cairo in the Qt wrapper?  I wonder if the perceived political issue is maybe not as big as you suspect it would be.

Given the benefits, it seems worth checking out.

To summarise, I'm suggesting that the benefits would be:

* New improvements and features in the Cairo backend become available to Qt applications.
* More interest in additional Cairo backend development from KDE users (more developers.)
* Potential for eventually deprecating Splash in favour of Cairo, freeing developers to focus on adding cool stuff to the Cairo backend.
Comment 29 Albert Astals Cid 2011-09-26 03:09:37 UTC
I am the Okular maintainer.
Comment 30 Paul Gideon Dann 2011-09-26 03:58:56 UTC
Ah.  So you are; that's me disarmed.  At the risk of sounding rather lame, maybe you could discuss this with the other maintainers?  I simply can't wrap my head around the desire to keep Cairo out at all costs, and I find it difficult to accept your decision because I haven't heard from anyone who agrees with you so far.

On my Archlinux system, Qt has a direct dependency on glib2.  I wonder if that means my KDE will explode...
Comment 31 Christos 2013-04-01 13:45:37 UTC
I still don't understand why this [feature is not added] / [bug is not fixed]

1. It has been at least 5 years since I first saw this issue.

2. There are patches that fix it with minimal work.

Since I am reading a lot of PDF papers using my computer, I'd like them to be easy to read.
Comment 32 Paul Gideon Dann 2013-04-02 08:40:01 UTC
In the meantime, feel free to get in touch via e-mail if you'd like any help building Poppler with the qt4-lcd patches.
Comment 33 Paul Gideon Dann 2013-08-16 08:24:31 UTC
Albert, given that Canonical in particular seems to see no issue with the idea of mixing Qt and GTK+ in one system, may I gently suggest you reconsider your opinion on merging this optional backend for Cairo to the Qt wrapper for Poppler?

Latest patches are at: https://github.com/giddie/poppler-qt4-cairo-backend
Comment 34 Albert Astals Cid 2013-08-16 08:50:48 UTC
I've considered about it again. Same process of thought brought me to same conclusion.
Comment 35 Paul Gideon Dann 2013-08-16 08:56:57 UTC
Just wanting to check I understand your reasoning correctly: you don't want to merge this because you think people will dislike the idea of linking Qt with Cairo (a GObject-based library), because the two camps are traditionally politically opposed (Qt vs GTK).  Is that right?

If so, can you explain how that point of view is compatible with Canonical's integration of Qt in Ubuntu Edge, which I assume (at least with your Canonical hat on) you're at peace with?  (Not intended aggressively; I genuinely don't understand.)
Comment 36 Albert Astals Cid 2013-08-16 18:14:18 UTC
(In reply to comment #35)
> If so, can you explain how that point of view is compatible with Canonical's
> integration of Qt in Ubuntu Edge, which I assume (at least with your
> Canonical hat on) you're at peace with?  (Not intended aggressively; I
> genuinely don't understand.)

The fact that you say "non agressively" is because you know it is agressive. So I'm going to "non agressively"  say: it's none of your business.

Have a good weekend :-)
Comment 37 Paul Gideon Dann 2013-08-16 18:38:02 UTC
Subtlety of tone and body language are not available in written text, and so I sometimes find it helpful to clarify the tone and my mood explicitly. Sometimes I use smilies; in this case, I was aware that you were in danger of interpreting any question I asked as aggressive, whether it was or not, so I tried to clarify that I'm interested in an actual answer, not to start an argument.

Regardless, I have no particular desire to enter into another debate. I simply don't understand why you're blocking this, and it seems no explanation is forthcoming. Ho hum.
Comment 38 Martin Spacek 2014-06-14 07:55:40 UTC
(In reply to comment #34)
> I've considered about it again. Same process of thought brought me to same
> conclusion.

Could you please explain that thought process? If not, might you kindly provide those of us reading through this bug with a link to the mailing list arguments you referred to 4.5 years ago in comment #1?

Much to my joy, I've recently discovered qpdfview (https://launchpad.net/qpdfview), but I'm rather dismayed that it's unable to use Cairo. I'm not the only one with such dismay: https://answers.launchpad.net/qpdfview/+question/212582
Comment 39 Paul Gideon Dann 2014-06-16 08:46:41 UTC
Martin, the thread can be found here:

http://lists.freedesktop.org/archives/poppler/2009-June/004865.html

Patches are available here:

https://github.com/giddie/poppler-qt4-cairo-backend
Comment 40 Jeffrey Baitis 2015-07-16 17:57:21 UTC
I recently became aware of this patch set, and I would love to see it included in the main qt4wrapper distribution.

I fail to see how inclusion necessitates dependencies because, as we say in software, all problems are solved by abstraction. If "purists" don't want Cairo dependencies, make it a compile-time option to enable dependencies on the Cairo backend :-)
Comment 41 Cris 2016-02-06 03:33:16 UTC
I find it genuinely appalling that a patchset that considerably improves font rendering is being rejected on the grounds of mixing gtk and qt. What an absolute luddite.

What's worse is that Albert has YET to explain his reasoning as to why he doesn't want to add a compile-time _option_ to the project.
Comment 42 Matthias Berndt 2017-04-18 19:20:03 UTC
Hi Albert, Hi Cris, Hi Paul,

Cris, there is no point in calling people names, that will not convince anybody. Albert, I call upon you to not let name-calling as practiced by Nikos and/or Cris to affect your judgement one way or the other.

I understand that the problem here isn't just the mixing of Qt and Cairo, it's that you, Albert, disagree that the Cairo backend provides better font rendering than the Splash backend. Paul provided some screenshots for comparison on his Github:
https://github.com/giddie/poppler-qt4-cairo-backend

Or more specifically:

https://camo.githubusercontent.com/7b7666f5e7430e950dff8f943a02cd51fbf9e3ac/687474703a2f2f636c6f75642e6769746875622e636f6d2f646f776e6c6f6164732f6769646469652f706f70706c65722d7174342d636169726f2d6261636b656e642f6265666f72652e706e67

vs.

https://camo.githubusercontent.com/d17e13b23523bb29832fe6fe43ea03d182db1d10/687474703a2f2f636c6f75642e6769746875622e636f6d2f646f776e6c6f6164732f6769646469652f706f70706c65722d7174342d636169726f2d6261636b656e642f61667465722e706e67

Albert, please look at these and compare them (you might want to open them in separate browser tabs so you can easily switch back and forth between them). I'd like to point out some specific details here:

– compare the 'm' in the word "them" (4th line, last word). In the Cairo rendering, both arches of the m are equally wide. In the Splash rendering, the right arch is wider, leading to an asymmetric appearance.
– in the word "library" (4th row, 1st word), the letters 'r' and 'y' should end at the same height on the top. This is the case in the Cairo rendering but not in the Splash rendering; the top edge of the 'r' is higher than the top edge of the 'y'.
– Also in the word library, Splash rendering, the strokes that compose the letter 'r' look thicker than those of the letter 'y'. In the Cairo rendering, the strokes have the same thickness.
– zoom in and you'll see that some of the pixels in the Cairo rendering are coloured, aka subpixel rendering. People generally agree that this leads to a better visual impression on LCD displays, especially those with limited resolution.

Based on these things, can we agree on these?
1.) The renderings are different
2.) The Cairo one generally looks better

If we can, then I would like to know why you nevertheless oppose merging these patches. Specifically, why do you believe that loading Cairo is a problem? Please keep in mind that
– Cairo is probably already installed anyway (most people have some GTK program installed)
– The library is 1.2 MB, in a day and age where hardly any computer has less than 1 GB of memory (my phone has 1 GB and it was a low-cost device when I bought it two years ago)
– the feature can be disabled when running in resource-constrained environments.

Trading a little bit of RAM for improved font rendering seems like a reasonable trade-off to me, but I would like to hear your side of the story.

Best regards,
Matthias
Comment 43 Kevin 2018-03-30 23:29:10 UTC
There appears to also be many performance issues that result from splash being significantly slower than cairo. Allowing the qt backend to use cairo may be the best way to resolve this.

Splash performance issues:
https://bugs.freedesktop.org/show_bug.cgi?id=23991
https://bugs.freedesktop.org/show_bug.cgi?id=78728
https://bugs.freedesktop.org/show_bug.cgi?id=81211
https://bugs.freedesktop.org/show_bug.cgi?id=105827
Comment 44 Kevin 2018-03-31 22:46:28 UTC
In case anyone is interested, I modified Paul's patches so that Poppler's Qt5 bindings use Cairo [1]. I also make an Arch Linux package that applies these patches [2].

[1] https://aur.archlinux.org/cgit/aur.git/tree/?h=poppler-qt5-cairo
[2] https://aur.archlinux.org/packages/poppler-qt5-cairo/
Comment 45 Paul Gideon Dann 2018-04-03 09:06:42 UTC
Thanks for putting in that work to port the patches to Qt5, Kevin. Would you mind putting in a pull request on Github (https://github.com/giddie/poppler-qt4-cairo-backend) against the `maint` branch?
Comment 46 GitLab Migration User 2018-08-21 10:55:55 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/poppler/poppler/issues/435.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.