Bug 25240

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:

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

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

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
> 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

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

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:
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

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

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/

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?

-- 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.