It works for me with cairo backend, I can reproduce it with splash. 

I've just replaced the SplashOutputDev based code in my app with Cairo support and I'm getting the same results with both.

See: http://i.imgur.com/oe51z.jpg

This leads me to think it's a bug in poppler PDF drawing code rather than the graphics output devices... 

Created attachment 32826 [details]
poppler glib demo rendering the document correctly

As I said it works for me with the cairo backend. It doesn't with splash.

hmm, which revision of poppler are you using?

Also, weirdly, the numbers in the blue triangles are missing in that one you posted :(

(In reply to comment #3)
> Created an attachment (id=32826) [details]
> poppler glib demo rendering the document correctly
> 
> As I said it works for me with the cairo backend. It doesn't with splash. 
> 

fails for me in master with both splash and cairo backends too

For me the problem starts at 104f9286ceb5fcb5f4795bca7633029142d5f6a4

Thomas could you have a look? That commit is the one in which we added "Support colorizing text in pattern colorspace"

(In reply to comment #4)
> hmm, which revision of poppler are you using?
>

git master, and cairo from git master too. 

> Also, weirdly, the numbers in the blue triangles are missing in that one you
> posted :(

right, there are still some other issues. 

> (In reply to comment #3)
> > Created an attachment (id=32826) [details] [details]
> > poppler glib demo rendering the document correctly
> > 
> > As I said it works for me with the cairo backend. It doesn't with splash. 
> > 
> 

(In reply to comment #6)
> For me the problem starts at 104f9286ceb5fcb5f4795bca7633029142d5f6a4
> 
> Thomas could you have a look? That commit is the one in which we added "Support
> colorizing text in pattern colorspace"
> 
I just took a quick look at it, but I don't think, that is comes from the pattern colorspace, even if it runs several times in the added routines: If I disable support of pattern colorspace for text and masks in SplashOutputDev (just comment out fillMaskCSPattern and supportTextCSPattern in SplashOutputDev.h, then it runs the default way), the output becomes even more worth.
Do You have any other hint? Must be some other code that that results in that output. I'll take a deeper look in it, but I fear that will take a little bit!

For me it's all fault of this patch http://cgit.freedesktop.org/poppler/poppler/commit/?id=104f9286ceb5fcb5f4795bca7633029142d5f6a4 Without it works and with it does not.

The problem is detecting what part of the patch is the problematic one :D

Created attachment 32879 [details]
First step to solve it

(In reply to comment #9)
> For me it's all fault of this patch
> http://cgit.freedesktop.org/poppler/poppler/commit/?id=104f9286ceb5fcb5f4795bca7633029142d5f6a4
> Without it works and with it does not.
> 
> The problem is detecting what part of the patch is the problematic one :D
> 

Yes, You're true. The easiest way to solve it is to call

state->setRender(0);

instead of

state->setRender(savedRender);

in endTextObject (SplashOutputDev.cc and PSOutputDev.cc).
But it seems, as if there is still a small problem left, see marked area in "First step to solve it" (but this problem also exists in "poppler glib demo rendering the document correctly". But to take a deeper look into it, I need some time, and even then, I first must go to the actual poppler release (I'm still testing with poppler 0.10.2 :-( ).
So decide by yourself, if You make the smaller changes (which are quick & dirty, I don't know anything about side effects!) for the moment

I'll regtest that change and see if it gives us improvements or not, and please take a look, no matter how much time you need, it is very appreciated.

Cool, I've done some testing and this fixes the main issue. I've also done regressions tests on a few other PDFs and not noticed any issues, though I don't want to bet on it subtly breaking another edge cases.

I just wish I could've been more help, but I'm still getting my head round the XPDF/Poppler rendering pipeline (and how PDFs work in general).

Since I started working with magazine PDFs I've seen so many weirdly broken ones (yes, Adobe Illustrator... I'm looking at you) that it's been a constant nightmare trying to get things to look right... so far Poppler is doing a stellar job :D

(In reply to comment #11)
> Yes, You're true. The easiest way to solve it is to call
> 
> state->setRender(0);
> 
> instead of
> 
> state->setRender(savedRender);
> 
> in endTextObject (SplashOutputDev.cc and PSOutputDev.cc).

@Thomas: Unfortunately your patch breaks page 8 (a T in the vertical title is not rendered anymore) of this pdf http://people.freedesktop.org/~aacid/bug155022.pdf

Do you think you'll be able to have a patch before end of March? If not any hint so we can try to fix it ourselves?

(In reply to comment #14)
> @Thomas: Unfortunately your patch breaks page 8 (a T in the vertical title is
> not rendered anymore) of this pdf
> http://people.freedesktop.org/~aacid/bug155022.pdf
> 
> Do you think you'll be able to have a patch before end of March? If not any
> hint so we can try to fix it ourselves?
> 

This regression doesn't come from a pattern colorspace, this PDF code is handled wrong:
q
578.159970 476.880040 12.719971 273.359950 re
W
n
/Cs1 cs
1 1 1 sc
q
0 -0.240000 0.240000 0 580.080020 750.240050 cm
BT
42 0 0 42 0 0 Tm
/F1#2e0 1 Tf
(TRANSP) Tj
42 0 0 42 169.558590 0 Tm
(ARENT SPEAKER CABLES) Tj
ET
Q
Q

Cs1 is a ICC based colorspace. I looked at it, and either the clip rectangle is calculated wrong or the starting textposition. I would expect that it is the clip rectangle, because it seems as if the position of the displayed text is okay, but I'm not an expert in this part of SplashOutputDev.
And finally PSOutputDev with my path handles this page correctly.
Are there any other experts in this? I fear it will take a long time for me to find and correct this error!

I had a deeper look into that and examined where my code works wrong: It is in Gfx.cc, opSetFillColorSpace. because during an BT-ET bracket the pattern colorspace chnaged serveral times. The correct code should therefore be:

	if (drawText) {
		if (colorSpace->getMode() == csPattern) {
                        // start new statements
			if (out->supportTextCSPattern(state) && textHaveCSPattern) {
				GBool needFill = out->deviceHasTextClip(state);
				out->endTextObject(state);
				if (needFill)
					doPatternFill(gTrue);
				out->restoreState(state);
			}
                        // end new statements
			colorSpaceText = NULL;
			textHaveCSPattern = gTrue;
			out->beginTextObject(state);
		} else if (textHaveCSPattern) {
			GBool needFill = out->deviceHasTextClip(state);
			out->endTextObject(state);
			if (needFill)
				doPatternFill(gTrue);
			out->beginTextObject(state);
			out->updateRender(state);
			out->updateTextMat(state);
			out->updateTextPos(state);
			textHaveCSPattern = gFalse;
		}
	}

Unforunately this still not solve the regression in the cloud, therefore I'll have anothher look at it next weekend

You rock, i'll pass this through the regrssion testing asap.

(In reply to comment #17)
> You rock, i'll pass this through the regrssion testing asap.
> 

Please keep in mind that page 8 from comment #14 still not works correctly with the patch. This is not a pattern colorspace issue!

I think you didn't understand my problem with that page, the problem was that the
state->setRender(0);
call made the T in page 8 disappear (a regression), not that the images paint with "weird" colors (always has happened)

This new patch is OK for me if fixes this file and doesn't cause other regressions, i'm not asking you to fix the weird coloring on page 8 of file in comment #14, though of course if you do you'll be my hero ;-)

I've commited the patch that fixes the rendering of the main area of the file, the bubble thing is minor, but i'll leave the bug open since it also should be ideally fixed.

(In reply to comment #20)
> I've commited the patch that fixes the rendering of the main area of the file,
> the bubble thing is minor, but i'll leave the bug open since it also should be
> ideally fixed.
> 

Personally I'd just close the bug, my main problem was the masking stuff (which was fixed with setRender(0)). You guys are awesome, I stared at code for hours and couldn't think of a fix.

I have a handful of PDFs that are causing problems that I need to get around to posting as bugs, but generally the bugs are "white lines" around objects (as can be seen around the cloud in the PDF I attached).

That problem is a weird one though, I've used perhaps 4-5 different libraries/programs to do PDF rasterizing and they all come up with the white lines, except Photoshop. The only difference I can think of is that perhaps Photoshop is rounding out to the next nearest point/subpoint; I'm honestly stumped at how print shops can convert these PDFs into the magazines you see on store shelves considering how much weird stuff I've seen.

Ok, the reporter says our solution works for him, closing the bug, of course work in improvements is still more than welcome. Thanks to everyone involved, specially Thomas.