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.
I already told you no on the mailing list, what made you think that using the bugzilla would give a different result?
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.
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.
There is something wrong in your system, i get very similar renderings in both cairo and splash.
Created attachment 32363 [details]
Which is which? Which rendering you like more, top or down?
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.
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.
CairoOutputDev doesn't have subpixel rendering at the moment, you should start by that.
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).
@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?
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.
> 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?
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"?
You are so intelligent that you decided to insult the maintainer to get the feature in, keep it up!
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.
Citation needed ;-)
The citation you requested:
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.
Albert Astals Cid
Cairo Backend for Qt Wrapper
FreeDesktop Bugzilla – Bug 25240
Unfortunately you don't prove that Cairo has better rendering than Splash, try again?
(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.
Yes, that convinces me, sure.
Wait, no, it does not.
Exactly. If the Big Man isn't convinced, nothing can happen. Bigotry at its finest.
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.
@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).
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, 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.
(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.
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.
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.
I am the Okular maintainer.
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...
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.
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.
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
I've considered about it again. Same process of thought brought me to same conclusion.
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.)
(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 :-)
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.
(In reply to comment #34)
> I've considered about it again. Same process of thought brought me to same
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
Martin, the thread can be found here:
Patches are available here:
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 :-)
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.
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:
Or more specifically:
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.