Created attachment 84689 [details]
Result exporting with pdftoppm (and converting to PNG)

This is how it is rendered with pdftoppm (exported to PNG with smaller size to save space). Similar result can be obtained with client apps like evince.

Created attachment 84690 [details]
Result with Adobe Reader 9 for Linux

How it is displayed with Adobe Reader 9 for Linux

The pdf is DeviceN with plates:

         <xmpTPg:PlateNames>
            <rdf:Seq>
               <rdf:li>Cyan</rdf:li>
               <rdf:li>Magenta</rdf:li>
               <rdf:li>Yellow</rdf:li>
               <rdf:li>Black</rdf:li>
               <rdf:li>PANTONE DS 239-8 U</rdf:li>
               <rdf:li>PANTONE 293 U</rdf:li>
               <rdf:li>PANTONE DS 166-1 U</rdf:li>
            </rdf:Seq>
         </xmpTPg:PlateNames>

The PANTONE spots are specified as:

                        <rdf:li rdf:parseType="Resource">
                           <xmpG:swatchName>PANTONE DS 239-8 U</xmpG:swatchName>
                           <xmpG:type>SPOT</xmpG:type>
                           <xmpG:tint>100.000000</xmpG:tint>
                           <xmpG:mode>RGB</xmpG:mode>
                           <xmpG:red>190</xmpG:red>
                           <xmpG:green>231</xmpG:green>
                           <xmpG:blue>228</xmpG:blue>
                        </rdf:li>
                        <rdf:li rdf:parseType="Resource">
                           <xmpG:swatchName>PANTONE 293 U</xmpG:swatchName>
                           <xmpG:type>SPOT</xmpG:type>
                           <xmpG:tint>100.000000</xmpG:tint>
                           <xmpG:mode>LAB</xmpG:mode>
                           <xmpG:L>38.039215</xmpG:L>
                           <xmpG:A>4</xmpG:A>
                           <xmpG:B>-48</xmpG:B>
                        </rdf:li>
                        <rdf:li rdf:parseType="Resource">
                           <xmpG:swatchName>PANTONE DS 166-1 U</xmpG:swatchName>
                           <xmpG:type>SPOT</xmpG:type>
                           <xmpG:tint>100.000000</xmpG:tint>
                           <xmpG:mode>RGB</xmpG:mode>
                           <xmpG:red>102</xmpG:red>
                           <xmpG:green>0</xmpG:green>
                           <xmpG:blue>100</xmpG:blue>
                        </rdf:li>
                     </rdf:Seq>

and the DeviceNs are defined as:

17 0 obj
[ /DeviceN [ /PANTONE#20DS#20166-1#20U /Magenta /Yellow ] /DeviceCMYK 
12 0 R 16 0 R ]
endobj

and:

44 0 obj
[ /DeviceN [ /PANTONE#20DS#20239-8#20U /PANTONE#20293#20U ] 38 0 R 
39 0 R 43 0 R ]
endobj

And those colours are used in the shadings.

Neither mupdf nor gs match acro’s rendering.

A pdf-capable printer with pantone support would be definitive, in how
the rendering is supposed to appear.

Created attachment 121615 [details]
Actual rendering

Works now for me with actual sources, with splash (pdftoppm) as well as with cairo (pdftocairo)!

(In reply to Thomas Freitag from comment #4)
> Created attachment 121615 [details]
> Actual rendering
> 
> Works now for me with actual sources, with splash (pdftoppm) as well as with
> cairo (pdftocairo)!

The rendering is much better but the blue gradient (+ multiply blend) is clearly not the expected one. This is much greyer.

Created attachment 121620 [details]
Rendered and output in CMYK

(In reply to Andrés Gómez García from comment #5)
> The rendering is much better but the blue gradient (+ multiply blend) is
> clearly not the expected one. This is much greyer.

Oh, I see. But I fear that is beyond the scope of poppler if You compile it just in RGB modus. Since the colors are a wild mix between RGB, CMYK and LAB, the missing of icc profiles and the usage of blending modes we will never reach exact the same color than acrobat, which uses it's own color management. And even the screenshot you attached from acrobat 9 on linux differs a lot from acrobat reader DC on windows.

But if I configure poppler to enable CMYK (not available in cairo, but in splash)
./configure --enable-cmyk
and then call
./utils/pdftoppm -jpegcmyk -cropbox 68593.open/igalia\ header\ proof.pdf output/igalia-cmyk.jpg

I get the attached result which is a little bit more blue

(In reply to Thomas Freitag from comment #6)
> Created attachment 121620 [details]
> Rendered and output in CMYK
> 
> (In reply to Andrés Gómez García from comment #5)
> > The rendering is much better but the blue gradient (+ multiply blend) is
> > clearly not the expected one. This is much greyer.
> 
> Oh, I see. But I fear that is beyond the scope of poppler if You compile it
> just in RGB modus. Since the colors are a wild mix between RGB, CMYK and
> LAB, the missing of icc profiles and the usage of blending modes we will
> never reach exact the same color than acrobat, which uses it's own color
> management. And even the screenshot you attached from acrobat 9 on linux
> differs a lot from acrobat reader DC on windows.

Yes, you are right. I'm aware of that.

> But if I configure poppler to enable CMYK (not available in cairo, but in
> splash)
> ./configure --enable-cmyk
> and then call
> ./utils/pdftoppm -jpegcmyk -cropbox 68593.open/igalia\ header\ proof.pdf
> output/igalia-cmyk.jpg
> 
> I get the attached result which is a little bit more blue

That actually looks pretty close to what I would be expecting. I'm also aware that cairo doesn't have CMYK (nor color profile management) so I suppose we can close this as fixed.