[poppler] Bug 69485

[Adrian Johnson]

On 05/01/14 07:52, Ross Moore wrote:
> Hi Adrian,
> 
> On 04/01/2014, at 1:39 PM, Adrian Johnson wrote:
> 
> 
>>> Ross, 
>>> thanks a lot for the detailed analysis. 
>>>
>>>
>>>    I tried turning it into a procedure and it fails with ghostscript and my
>>>    printer. It turns out it was correct. See example 4.26 on p311 of the PS
>>>    Ref.
>>>
>>> Adrian, 
>>> I'm not sure I fully understand your answer. Do you think this
>>> PostScript code is actually correct?
>>
>> The PostScript code is correct. I've updated cairo to remove the
>> duplicate /Interpolate but it was not incorrect. According to p568 of
>> the PLR if "def" is used when the key already exists the existing value
>> is overwritten. So the dict size of 8 is not exceeded but even if it was
>> according to p572 with language level 2 and 3 the dict size is
>> automatically increased if the initial size is exceeded.
>>
>> The DataSource is correct. The filter operator returns a file object.
>> The sequence "currentfile /ASCII85Decode filter /FlateDecode" results in
>> a single file object on the stack which meets the requirement that the
>> data source must be a file, procedure, or string.
> 
> Yes, the syntax here is indeed correct.
> 
> I've done a lot more testing now and think that I know the reason
> for the problems.
> It is a matter of context, not the syntax per se.
> 
> Let's look at a larger chunk of the PS source:
> 
>>> << /PatternType 1
>>>    /PaintType 1
>>>    /TilingType 1
>>>    /XStep 2190 /YStep 2190
>>>    /BBox [0 0 24 15]
>>>    /PaintProc { CairoPattern }
>>>>>
>>> [ 0.652971 0 0 0.652968 83.654401 292.766344 ]
>>> makepattern setpattern
>>> q
>>> 83 303 17 -11 re W n
>>> [ 0.652971 0 0 0.652968 83.654401 292.766344 ] concat
>>> 8 dict dup begin
>>>   /ImageType 1 def
>>>   /Width 24 def
>>>   /Height 15 def
>>>   /Interpolate false def
>>>   /BitsPerComponent 1 def
>>>   /Decode [ 1 0 ] def
>>>   /DataSource currentfile  
>>>     /ASCII85Decode filter /FlateDecode filter def
>>>  % /Interpolate false def
>>>   /ImageMatrix [ 1 0 0 -1 0 15 ] def
>>> end
>>> imagemask
>>> Gar8O!!3<."p5&6Mu*H<lMpm`s8T;%s*la!#Nl!cb6!e-!5&ILgA~>
>>> Q
> 
> The  makepattern setpattern  has changed the Colorspace to become
> that of a Pattern .
> None of the operators following this have changed the Colorspace,
> but the coding then tries to define a new pattern/image dictionary
> via  imagemask .
> This is the dubious operation, within such a Colorspace context.

Where does the PLR say that imagemask defines a new pattern? My
understanding is it uses the mask to paint the current color (which may
be a pattern).

> 
> To get what I think you want, you need to switch the Colorspace to
> /DeviceRGB (or /DeviceCMYK or similar).

The problem is this PS code is for painting an image with a bilevel
SMask. The image is output as a pattern color and then imagemask
(created from the SMask) is used to paint the pattern. So changing the
color will not produce the correct output. It just happens that with
this particular PDF the image is all red. But that won't be the case in
general. So as far as I can see it is still valid PS code.

I suggest filing a bug for cairo and when I get time I will look at
changing the PS output. For PS level 3 a type 3 image can be used which
includes the mask with the image. There is already code in cairo for
doing this but due to the way poppler uses cairo this code path does not
get activated.

For now the work around is to print as PCL or if your printer supports
it print as PDF.


> e.g. just insert a single line, as below, 
> 
>>> makepattern setpattern
>>> 1 0 0 setrgbcolor
>>> q
>>> 83 303 17 -11 re W n
> 
> 
> or 
> 
>>> makepattern setpattern
>>> q
>>> 1 0 0 setrgbcolor
>>> 83 303 17 -11 re W n
> 
> This indeed results in file processing fully,
> showing the red arrow.
> 
> 
> In summary, within a complicated Colorspace, you seem not to be able
> to setup a Pattern, which is kind of setting up for a new Colorspace.
> 
> Whether this is meant to be a feature of the PS language, or is
> a criterion imposed by Distiller, is the bit that I do not yet know.
> 
>>
>> Another observation is that the PS output you attached is not the direct
>> output of pdftocairo. It has CUPS stuff inserted into it. Maybe you
>> could try printing with the pdftocairo output without any additional
>> filtering to see if it makes a difference. See the lpr man page.
>> Something like "lpr -l" should bypass all filtering.
> 
> 
> 
> Hope this helps,
> 
> 	Ross
> 
> ------------------------------------------------------------------------
> Ross Moore                                       ross.moore at mq.edu.au 
> Mathematics Department                           office: E7A-206      
> Macquarie University                             tel: +61 (0)2 9850 8955
> Sydney, Australia  2109                          fax: +61 (0)2 9850 8114
> ------------------------------------------------------------------------
> 
> 
> 
> 
> 
> 
> _______________________________________________
> poppler mailing list
> poppler at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/poppler
>