[poppler] Bug 69485
Ross Moore
ross.moore at mq.edu.au
Sun Jan 5 16:51:21 PST 2014
Hi Thomas, Alex, Adrian,
On 05/01/2014, at 10:02 PM, Thomas Freitag wrote:
> 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):
I've now tested PS to PDF conversion of the file china-visa-application.ps
using 3 different converters:
1. Adobe's Distiller (from Acrobat Pro XI)
2. ps2pdf (front end to Ghostscript)
3. pstopdf (Apple Computer, BSD Unix utility, on MacOSX 10.6.8)
Only #2, based on Ghostscript, succeeds.
#1 and #3 give similar errors:
viz.
>> [GlenMorangie:~/PDFTeX/test-PDFs/no-print] rossmoor% /usr/bin/pstopdf china-visa-application-1.ps
>> PAGE: 1 1
>> PAGE: 2 1
>> PAGE: 3 1
>> %%[ Error: undefined; OffendingCommand: imagemask; ErrorInfo: ImageType --nostringval-- ]%%
>>
>> Stack:
>> -dict-
>>
>>
>> %%[ Flushing: rest of job (to end-of-file) will be ignored ]%%
>> %%[ Warning: PostScript error. No PDF file produced. ] %%
>> /usr/bin/pstopdf failed on file china-visa-application-1.ps with error code -31000
Here is the clean run via Ghostscript:
>> [GlenMorangie:~/PDFTeX/test-PDFs/no-print] rossmoor% ps2pdf china-visa-application-1.ps
>> PAGE: 1 1
>> PAGE: 2 1
>> PAGE: 3 1
>> PAGE: 4 1
Here also is the Distiller Log:
>> Distilling: china-visa-application-1.ps
>> Start Time: Monday, 6 January 2014 at 7:42 AM
>> Source: /Users/rossmoor/PDFTeX/test-PDFs/no-print/china-visa-application-1.ps
>> Destination: /Users/rossmoor/PDFTeX/test-PDFs/no-print/china-visa-application-1.pdf
>> Adobe PDF Settings: /Users/rossmoor/Library/Application Support/Adobe/Adobe PDF/Settings/Press Quality(1).joboptions
>> Error %d: PAGE: 1 1
>> Error %d: PAGE: 2 1
>> Error %d: PAGE: 3 1
>> %%[ Error: undefined; OffendingCommand: imagemaskDistiller; ErrorInfo: ImageType --nostringval-- ]%%
>>
>> Stack:
>> -dict-
>>
>>
>> %%[ Flushing: rest of job (to end-of-file) will be ignored ]%%
>> %%[ Warning: PostScript error. No PDF file produced. ] %%
>> Distill Time: 2 seconds (00:00:02)
>> **** End of Job ****
So Apple seems to agree with Adobe on this one, and it is Ghostscript
that is the odd one out.
However, there is nothing in the PS Ref that indicates this kind
of error.
That doesn't surprise me, as there have always been problems with
Adobe's reference documentation. Typically they give an example
that works; but does not cover the full range of coding that one
would expect to be syntactically valid. Thus (as here) you just
have to try out different possibilities until you discover
a way to get working the effects that you want.
>
> 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!!!
That agrees with my tests.
> 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!!!
Using:
pdftops version 3.03
Copyright 1996-2011 Glyph & Cog, LLC
...
> 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 !!!
... I have no such problem with AD XI.
However, there are 2 instances of what looks like a "missing glyph" artifact
on page 3 of the PDF recreated using Distill, as can be seen in one of the
attached screenshots.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen shot 2014-01-06 at 8.38.50 AM.png
Type: image/png
Size: 23652 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/poppler/attachments/20140106/dac25409/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen shot 2014-01-06 at 8.38.32 AM.png
Type: image/png
Size: 19073 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/poppler/attachments/20140106/dac25409/attachment-0004.png>
-------------- next part --------------
The artifacts do not occur using pstopdf nor with ps2pdf.
So this time it is Distill that is the odd one out.
In the .ps file, we have:
lines 23178?23181
>> /F40_0 8 Tf
>> (2.\)\011 What plans are in place for the trainee/intern to part\
>> icipate in American cultural activities?)
lines 23755?23758
>> /F40_0 8 Tf
>> (1.\)\011 What specific knowledge, skills or techniques will be \
>> learned?)
The octal \011 is ASCII Decimal 9, which character may not be in the font.
So this artifact may be related to a Font Substitution that was made when
the .ps file was generated; viz.
>> [GlenMorangie:~/PDFTeX/test-PDFs/no-print] rossmoor% /usr/local/bin/pdftops -level3 84240-orig.pdf
>> Syntax Warning: Substituting font 'Helvetica' for 'arial'
but then some PDF converters leave out the suspect character,
but AD does not ????
Note also that some of the content on that page occurs in reverse
order within the .ps file. Was it so in the original PDF ?
> 4. All other ps files can neither be opened with Adobe Acrobat X nor be rendered by Adobe Distill X
I'd doubt that there is any difference between v.X and v.XI of Adobe's Distill.
>
> My conclusion, especially because of 2. and 3.: It is a bug in the Adobe PS engine!
And Apple's also?
Or is Apple's pstopdf just a minor variant of Adobe's code?
In any case, it would be great for an Adobe engineer to have a look
at these issues.
Also, some response from the Ghostscript guys would be nice too.
Is this a problem already known to them?
How do they side-step around it, with confidence that no other
problems should result?
More below !!!
>
> Cheers,
> Thomas
>
> Am 05.01.2014 03:31, schrieb Alex Korobkin:
>> Ross, Adrian,
>>
>> 2014/1/4 Adrian Johnson <ajohnson at redneon.com>
>> 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 ]%%
OK. I can reproduce this.
Again ps2pdf has no problem with it, but Apple's pstopdf
also fails to do the conversion.
This is most perplexing as the xyshow command is handled
correctly 10 times, but fails on the 11th usage.
It seems that the difficulty is first encountered
when handling the chinese characters in the heading of
the Form.
(Preceding this are the characters of: "Form V.2013"
at top-right of page 1. These are done OK. )
Here's how I can check this:
>> % text string operators
>> /xyshow where {
>> pop
>> /xyshow2 {
>> dup length array
>> 0 2 2 index length 1 sub {
>> 2 index 1 index 2 copy get 3 1 roll 1 add get
>> pdfTextMat dtransform
>> 4 2 roll 2 copy 6 5 roll put 1 add 3 1 roll dup 4 2 roll put
>> } for
>> exch pop
mark /xyshow where pstack cleartomark %<--- insert this line
>> xyshow
>> } def
>> }{
>> /xyshow2 {
>> currentfont /FontType get 0 eq {
... etc ...
This causes the contents of the stack to be written to the Log
immediately before xyshow is called.
The indication is that xyshow is indeed well-defined,
yet something still goes wrong.
Thus the error must be happening at an internal level,
not within the user-level PS coding.
>>
>> 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
By commenting out groups of lines like this, I can process
further and further into the file.
It seems that the errors occur with chinese characters,
always when coming from the font referenced as: /F243_0
which is:
/F243_0 /ZJWNJQ+SimSun 0 pdfMakeFont16L3
%%BeginResource: font ZJWNJQ+SimSun
%!PS-TrueTypeFont- 1
20 dict begin
/CIDFontName /ZJWNJQ+SimSun def
/CIDFontType 2 def
/FontType 42 def
/CIDSystemInfo 3 dict dup begin
/Registry (Adobe) def
/Ordering (Identity) def
/Supplement 0 def
end def
/GDBytes 2 def
/CIDCount 28762 def
/CIDMap 57524 string
0 1 28761 {
2 copy dup 2 mul exch -8 bitshift put
1 index exch dup 2 mul 1 add exch 255 and put
} for
def
/FontMatrix [1 0 0 1 0 0] def
/FontBBox [-2 -37 256 220] def
/PaintType 0 def
/Encoding [] readonly def
/CharStrings 1 dict dup begin
/.notdef 0 def
end readonly def
/sfnts [
<00010000000b00800003003063767420072903f0000000bc000002be6670676d
...
Thus it would seem that there could be something badly wrong
with this font, or with the way it is being used in this document.
Note carefully what I am saying here.
Not every instance of this font's usage causes an error,
but all the errors that I have found are associated with
an instance of this font's use.
>>
>> 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.)
Yes.
Almost all of the first 87% of the file is devoted to the fonts.
>> 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 did not encounter a problem at this point in the file;
but yes this also corresponds to an instance of /F243_0 !
>>
>> 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
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
------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo.png
Type: image/png
Size: 5257 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/poppler/attachments/20140106/dac25409/attachment-0005.png>
-------------- next part --------------
More information about the poppler
mailing list