[poppler] Bug 69485

[Alex Korobkin]

Hi Ross,

2014/1/5 Ross Moore <ross.moore at mq.edu.au>

>
> >> 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.
>
>
Just to be sure I understand this correctly: I only see xyshow being used
once in the document, when defining Tj macro.
Do you refer to the 11th invocation of Tj macro?


> 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.
>
>
Thank you for the hint, I will try to do more debugging using this
technique.


> 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.
>
>
Does it mean that the error is not caused by any particular call to xyshow,
but more likely by the number of such calls made consequently?
Maybe it is some kind of nesting issue, or stack not been freed properly
issue?


> 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.
>
>
I kind of wonder why pdftops embeds so many instances of the font, while
both pdftocairo and pdf2ps somehow avoid this problem and create smaller PS
documents. But, that's a subject for another discussion.


> >>
> 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 only point to this location because it's the first mention of the [1.447
0 1.447 0 1.447 0 1.447 0] sequence, referred to by Distiller error
message. Perhaps I misinterpret Distiller's message.


> Hope this helps,
>

It helps greatly, thanks again.


-Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/poppler/attachments/20140107/418afa88/attachment.html>