Hi all!
I skimmed through this thread and the bug report itself, but I'm not
really sure what is the state of the investigation, but I made some
tests today morning, and here my results (forget it, if You already come
to the same conclusion):
1. All ps files pointed to by the thread and the bug report and all I
produced by my own with pdftops -level3 can be rendered with gs 9.0.6
without any problems!!!
2. The postscript output of Form DS-7002.pdf
(https://bugs.freedesktop.org/attachment.cgi?id=89534), produced with
pdftops -level3, can be opened with Adobe Acrobat X under Windows!!!
3. But the same ps file can't be rendered with Adobe Distill X under
Windows, then I get the same error log as in
https://bugs.freedesktop.org/show_bug.cgi?id=69485#c2 !!!
4. All other ps files can neither be opened with Adobe Acrobat X nor be
rendered by Adobe Distill X
My conclusion, especially because of 2. and 3.: It is a bug in the Adobe
PS engine!
Cheers,
Thomas
Am 05.01.2014 03:31, schrieb Alex Korobkin:
Ross, Adrian,
2014/1/4 Adrian Johnson <[email protected]
<mailto:[email protected]>>
On 05/01/14 07:52, Ross Moore wrote:
>
> 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.
Ross,
That is amazing, thanks again.
While we're on this subject, maybe you could have a look at the PS
output produced by pdftops, when processing the same file?
The resulting level 3 PostScript cannot be parsed by Distiller either,
the error is
%%[ Error: undefined; OffendingCommand: xyshow ]%%
Stack:
[26.046 0.0 26.046 0.0 26.046 0.0 26.046 0.0]
(Añ+cB'>~)
[1.447 0 1.447 0 1.447 0 1.447 0]
(Añ+cB'>~)
762.6
363.275
The PS file can be retrieved from here, it is 18Mb in size. (Unlike
pdftocairo, pdftops generates huge PS files. This particular one gets
10x larger when I provide licensed fonts to pdftops.)
https://docs.google.com/uc?export=download&id=0B-vV7Qx5rjpEVWxVSWtFZU5UX2s
I suspect that there is a similar problem somewhere along the
lines 284962-284999:
/DeviceGray {} CS
[0] SC
[0] SC
0.514 w
0.447 Tc
-0.447 Tw
2 Tr
[18 0 0 18 154.68 762.6] Tm
0 0 Td
/F243_0 1 Tf
(\004]\011~\004\352"A)
[1.447
0
1.447
0
1.447
0
1.447
0] Tj
My very basic knowledge of PS doesn't allow be to get any deeper :(
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.
Thanks Adrian,
I will certainly file a bug to cairo postscript component. We're on
poppler mailing list here, prhaps you could provide any advice to
poppler team on how to invoke that part of code that currently is not
getting activated?
For now the work around is to print as PCL or if your printer supports
it print as PDF.
Unfortunately, it's not just this one file that was reported to me as
unprintable. I use pdftops and pdftocairo on my printservers, and a
numer of other files fail to print on Ricoh printers with the same
"xyshow" error, as mentioned in the bug. I hope we can debug it until
it is fixed both in pdftops and in pdftocairo. We already made great
progress.
-Alex
_______________________________________________
poppler mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/poppler
_______________________________________________
poppler mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/poppler
