| Summary: | pdfwriter gray-text converted to black text and printed opaque. | ||
|---|---|---|---|
| Product: | GhostPCL | Reporter: | norbert.janssen |
| Component: | PDF Writer | Assignee: | Henry Stiles <henry.stiles> |
| Status: | NOTIFIED DUPLICATE | ||
| Severity: | normal | CC: | htl10 |
| Priority: | P2 | ||
| Version: | master | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Customer: | 661 | Word Size: | --- |
| Attachments: |
pcl testfile
jpeg output page pdf output simpler pcl-xl testfile pdf output for test1.bin simplified testfile generated pdf for simplified testfile disassembled test2.bin using rop3 PSDPxax disassembled test3.bin pdf output from tst3.bin |
||
Created attachment 11652 [details]
jpeg output page
Created attachment 11653 [details]
pdf output
If the PCL uses raster ops then its quite likely that the result will be incorrect. PDF does not have raster ops in its graphics model, and so ignores them. The reference to 'transparent' makes me think this is likely. This is a known limitation of pdfwrite when used with PCL input, and its unlikely we'll be able to address it, other than the obvious solution of rendering to a bitmap and wrapping that up as a PDF file. I'm reassigning this to Henry in the first instance, because he can reduce the PCL file much more easily than I can, and can quickly tell if the problem is likely to be ROPs (well, more quickly than me anyway). Henry, if you think its a genuine pdfwrite propblem, please pass it back to me (with a smaller file if you can please) Created attachment 11654 [details]
simpler pcl-xl testfile
a somewhat simpler testfile
Created attachment 11655 [details]
pdf output for test1.bin
Created attachment 11656 [details]
simplified testfile
Created attachment 11657 [details]
generated pdf for simplified testfile
Created attachment 11658 [details]
disassembled test2.bin
Well, I'm not a PCL expert, but this: ubyte e_P ROP3 // Operator Position: 13 SetROP and this: ubyte e_DSa ROP3 // Operator Position: 28 SetROP Seem like fairly compelling evidence to me that this file uses ROPs. Again I'll have to leave it to Henry to tell me whether there's any real likelihood of us handling these in PDF. My initial impression is that we probably can't (and we already know it isn't possible in the general case with ROPs). The only way to get the output you expect is to render to a raster and wrap the raster up as a PDF file. Created attachment 11659 [details]
using rop3 PSDPxax
1 extra image placed, using the PSDPxax rop.
Created attachment 11660 [details]
disassembled test3.bin
Created attachment 11661 [details] pdf output from tst3.bin this testfile (test3.bin) also uses PSDPxax rop3. See also info below that I found using google. 1) The ROP code 00B8074A is the boolean function B8 (bits 16-23 of the ROP code, hence the 'B8' in 00B8074A). It corresponds to the boolean function 'PSDPxax' (in postfix notation) which does the following: XOR destination and pattern AND the result with the source XOR the result with the pattern again. 2) >The ROP code >B8- 0x00B8074A- PSDPxax >To handle this rop operation is it that, the destination rectangle is to be >filled with downloaded pattern or just downloading the pattern to printer >will do the need. Actually that ROP says "use the pattern (usually monochrome) as a mask to choose between source and dest". Where the pattern is 1, the source is used. Where the pattern is 0, the destination is left alone. It is the way transparency was done before GDI supported transparency. This ROP is used, for example, to draw the icons on your desktop: the mask digs a hole for the useful pixels in the source. Seems to me that this should be possible with PDF. (In reply to norbert.janssen from comment #12) ... > 2) > >The ROP code > >B8- 0x00B8074A- PSDPxax > >To handle this rop operation is it that, the destination rectangle is to be > >filled with downloaded pattern or just downloading the pattern to printer > >will do the need. ... FWIW, I think it isn't possible to do it "easily" in the pdf imaging model. ROP3 involving the destination (i.e. "reading" what's already inked/printed back and do stuff on it and send it back) isn't a native pdf operation, so it would involve buffering and flattening the page image, which isn't a nice way to do things. I fixed a pile of bugs in the pxl driver a while ago with ROP3's, and one of the last changes were to make ROP3 *not* involving the destination work. PXL does support ROP3 natively (and PXL to PXL should be ideally a no-op pass-through), so ROP3 involving the destination would need to be implemented by passing it through - which is, AFAIK, still an unfixed enhancement bug. I think Henry closed the report as "LATER". ( see http://bugs.ghostscript.com/show_bug.cgi?id=693056#c4 ) Though this is a PXL and not PCL like the referenced duplicate, it is the same issue. Ken describes in comment #3 of that bug the pdfwrite device doesn't even know about the rop and we don't really have a plan as to what we could do if pdfwrite could intercept the rop loading. As Hin-Tak and Ken have said the fallback is rasterize the entire page after previewing which is something we don't want to do. *** This bug has been marked as a duplicate of bug 692853 *** |
Created attachment 11651 [details] pcl testfile with attached testfile. obj/pcl6.exe -sDEVICE=jpeg -sOutputFile=test.jpg -r100 testfile.pcl obj/pcl6.exe -sDEVICE=pdfwrite -sOutputFile=test.pdf testfile.pcl test.pdf shows some artefacts for displayed state-names (NEVADA, UTAH, COLORADO etc). the text is shown 'black' i.s.o. grey, and opaque (with white background) i.s.o. transparent.