pdftops -eps -level1sep creates an invalid EPS for the attached PDF. I have a section of the generated EPS below. ghostscript gets a /limitcheck in the first few bytes of the pdfIm1Sep data. I think that PSOutputDev::tilingPatternFillL1() is generating the font as a way to implement tiling patterns in Level 1. This might have to be a case where pdftops has to rasterize in PSOutputDev::checkPageSlice(). Maybe PreScanOutputDev::tilingPatternFill() needs to do more testing that the tiled image is not an image mask. The tiling that causes the problem has painttype 1 tilingtype 1. Changing the call in PreScanOutputDev::tilingPatternFill() to gfx->drawForm(str, resDict, mat, bbox, gFalse, gTrue); (to set softMask to true) fixes this file but causes other files to be rasterized unnecessarily. William 346.332397 107.800697 343.208099 110.819 339.473389 113.085899 c 335.411713 115.526199 l 338.945007 122.620796 l h W* 8 dict begin /FontType 3 def /FontMatrix [1 0 0 1 0 0] def /FontBBox [0 0 141.7323 141.7323] def /Encoding 256 array def 0 1 255 { Encoding exch /.notdef put } for Encoding 120 /x put /BuildGlyph { exch /CharProcs get exch 2 copy known not { pop /.notdef } if get exec } bind def /BuildChar { 1 index /Encoding get exch get 1 index /BuildGlyph get exec } bind def /CharProcs 1 dict def CharProcs begin /x { 141.7323 0 setcharwidth q [141.732574 0 0 141.732574 0 0.000003] cm 268 268 8 [268 0 0 -268 0 268] pdfIm1Sep 32323b373b38393c3d3d3b3b342a2d2737383232313831383c3b3c3830323232 32321d3c383233383830383037363e323b323339323d3833343a323237363b30 30353b3a34311d25252b3737373232312b383c3a31383d38251332323d1c3531 323c3b342d233d282c32323135313c373230372e2532371832383c3c303b3a33 ... 7376766b5f220b0b0707125e5e3261610327080e7676767660666d64603f4e07 Q } def end currentdict end /xpdfTile0 exch definefont pop /xpdfTile0 findfont setfont fCol gsave [0.45376 0 0 0.42696 335 76] concat 0 1 1 { 0 exch 141.7323 mul m 0 1 1 { pop (x) show } for } for grestore Q
The attachment was too large. I temporarily copied it to http://williambader.com/R84895.pdf
This bug occurs for me with any -level1 option set, not just eps and not just sep.
I am working on a patch. Can you post a few representative files somewhere? William
Created attachment 94547 [details] [review] proposed patch to poppler/PreScanOutputDev to fix the problem This patch fixes the problem with R84895 (by forcing it to be rasterized with level1 output) without affecting any other of my test files. The patch tracks when the prescan is inside a tiling pattern and sets the patternImgMask flag in more cases. This allows PreScanOutputDev::drawImage() to differentiate a normal image (which is OK) from a tiling pattern (which requires rasterization with level1). It also knows about the optimization in PSOutputDev::tilingPatternFill() that does not use a tiling if only one instance of the pattern is required. William
Pushed
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.