See http://bugs.linux-foundation.org/show_bug.cgi?id=158 The bug occurs on integration of legacy drivers into the PDF printing workflow (PDF as standard print job format): A driver (here "pxlmono") has options which are based on PostScript code to be embedded in the incoming PostScript data stream. This means that the driver cannot be controlled when Ghostscript is fed with PDF. These cases are auto-detected by foomatic-rip and fommatic-rip does the following then: PDF --Ghostscript-> PS --embed options-> PS --Ghostscript-> PCL-XL The PostScript which the first Ghostscript process produces (with output device "pswrite") leads the second Ghostscript process to loose characters and print them as squares when converting to PCL-XL with "pxlmono". See the scanned printout in the above-mentioned bug report. See also sample files there. Or do gs -q -sstdout=%stderr -sDEVICE=pswrite -sOutputFile=- -dBATCH -dNOPAUSE -dPARANOIDSAFER /home/till/walking-map-portland-1.pdf > test.ps gs -q -sstdout=%stderr -sDEVICE=pxlmono -sOutputFile=- -dBATCH -dNOPAUSE -dPARANOIDSAFER test.ps > test.pxl and send the text.pxl unfiltered to a PCL-XL printer.
Created attachment 4286 [details] Original PDF file used for the test
Created attachment 4292 [details] Bug690025.ps Result of running the pdf file through gs r8999 pswrite, using the command line above.
Created attachment 4293 [details] Bug690025.pxl Result of running the second command line above, convertion pswrite output to pxlmono.
Confirmed with HEAD. Bug6890025.ps displays fine with the x11alpha device, but the text is mangled in the pxlmono output, as displayed by ghostpcl. The pxlmono output from Bug6890025.pdf is fine.
This is another example of the increasingly important 'stroke and fill' issue. Some of the text has been artificially emboldened by using PDF text render mode 2 which first fills the text, and then strokes the outline. Using the same colour for both operations makes the text slightly bolder. As noted in other reports (#689970, #688267, 689692) this has been a long standing issue. The current implementation is better than previous ones, but has some specific problems, in particular the stroke width can be created incorrectly leading to very 'fat' strokes. This issue is the next one I plan to address. Marking as a duplicate of #689970. By the way, please upload sample files by attaching them to the bug report. *** This bug has been marked as a duplicate of 689970 ***
This does not appear to be a duplicate
The patch: http://ghostscript.com/pipermail/gs-cvs/2008-November/008827.html In conjunction with several other patches (especially including revision 9196) should resolve the parts of this issue relating to pdfwrite, where the resulting PDF file has excessively bold glyphs. Please note, this relies upon the existence of several previous fixes for text rendering modes, outline fonts etc, I would not attempt to apply this patch in isolation, a full update to revision 9248 is recommended. I am not closing the issue as I have no idea of the status wrt the pxlmono driver.
I have built the current SVN (rev 9249) and run again the two command lines from my initial posting and printed the result without filtering. The problem still persists. I attach the two files.
Created attachment 4624 [details] test-9249.ps
Created attachment 4625 [details] test-9249.pxl
For the test I did not install the new Ghostscript into my system, I did CFLAGS="-fPIC" ./autogen.sh --prefix=/usr --sysconfdir=/etc --with-ijs --with-jbig2dec --with-jasper --with-x --disable-gtk --enable-dynamic --with-omni --enable-cups --disable-compile-inits --with-drivers=ALL --disable-cairo --with-fontpath=/var/lib/defoma/gs.d/dirs/fonts:/usr/share/cups/fonts:/usr/share/ghostscript/fonts:/usr/local/lib/ghostscript/fonts:/usr/share/fonts make GS_LIB=./Resource/Init/:./lib bin/gs -q -sstdout=%stderr -sDEVICE=pswrite -sOutputFile=- -dBATCH -dNOPAUSE -dPARANOIDSAFER /home/till/walking-map-portland-1.pdf > test.ps GS_LIB=./Resource/Init/:./lib bin/gs -q -sstdout=%stderr -sDEVICE=pxlmono -sOutputFile=- -dBATCH -dNOPAUSE -dPARANOIDSAFER test.ps > test.pxl nc -w1 <printer IP> 9100 < test.pxl I am on Ubuntu Intrepid, x86_64. I mark this bug as NEW as Ralph Giles was able to reproduce it, at least before the update.
The problem is still there with SVN HEAD. There are less broken characters than with Ghostscript 8.63, but the problem is still not solved.
Till, I'm somewhat confused here, I'm no longer sure what (if anything) I should be looking at. I originally looked into this because ps2write was getting the artificial emboldnening incorrect for this file, and so the PostScript output from ps2write was wrong. In this sense I don;t think the problem was with the pxlmono driver, but with ps2write. I think this is fixed, and converting the original PDF file into PostScript using ps2write yields a file which looks pretty much OK to me. Of course I could easily be missing the fault. Can you describe where on the page you see the problem, and what process you are using to reproduce it please ?
Created attachment 4695 [details] walking-map-portland-1.png I have scanned the printout now. Squares appear at the following places: 1. "a" in "Portland Street Car" on 10th and 11th Avenue 2. Ellipse with destination at the upper end of the MAX Light Rail (SW Morrison) 3. Ellipse at the right end of the Portland Street Car line 4. "Park Blocks" between the two Park Avenues 5. Pioneer Court House between the 5th and the 6th Avenue 6. "Saks Fifth Avenue" between the 4th and the 5th Avenue ("S" missing) 7. Tiffany & Co. between the 3rd and 4th Avenue
Ah.... I've been using the 'Original PDF file used for the test' file, the PNG is obviously from the 'test-9249.ps' file. Taking the file test-9249.ps' and running it through the current HEAD of 8.64 it looks OK, so I conclude this is something to do with the pxlmono driver. That is, the PostScript file renders correctly, so I believe the output of ps2write is OK. I think Ray and Henry own this one, so I'll leave it up to them. It is of course still possible that the black squares are a problem with ps2write, but I think they'll be able to tell that far quicker than me.
The problem also occurs when converting PostScript input data into PDF and then running the "pxlmono" driver with PDF input: gs -q -sstdout=%stderr -sDEVICE=pswrite -sOutputFile=- -dBATCH -dNOPAUSE -dPARANOIDSAFER /usr/share/system-config-printer/testpage-a4.ps > test.pdf gs -q -sstdout=%stderr -sDEVICE=pxlmono -sOutputFile=- -dBATCH -dNOPAUSE -dPARANOIDSAFER test.pdf > test.pxl In this example the "s" of the work "Grayscale" at the upper left appears as a black square. The reporters of the following Ubuntu bug https://bugs.edge.launchpad.net/ubuntu/+source/cups/+bug/361772 have the problem with Ghostscript 8.64, I have found it also with the current SVN state.
Created attachment 4990 [details] testpage-a4.ps PostScript input file of the example in the previous comment.
Created attachment 4996 [details] pswrite.ps The result of running the file 'testpage-a4.ps' through GS to the pswrite device.
Created attachment 4997 [details] pswrite.pxl Result of converting pswrite.ps using the pxlmono driver. Default settings. This renders the 's' in Grayscale and the '1' in the 100% as solid rectangles.
Marcos, Henry suggested I assign this to you as you've been handling pxl devices. The problem is that files passed via pswrite or pdfwrite (according to Till, I've only tried pswrite) when converted via the pxlmono and potentially the pxlcolor devices, some of the text is rendered as solid fills. I've attached two files, one is the result of converting the testpage-a4.ps file to PostScript using pswrite. You should be able to run this to GS on any device and see the correct result. I've tried pdfwrite, tiff32nc and one of the bitmap drivers. The pswrite.pxl file is the result of passing pswrite.ps through the pxlmono driver, when rendered by Ghostpcl I see that some glyphs are rendered as solid fills (or possibly solid images).
I do not see any chance currently to reproduce this with the pdfwrite device. I will need some more input for the people who reported this to Ubuntu.
Note that in comment #16 I did the copy-and-paste wrong when testing and in the first line I converted the incoming PostScript file to Ghostscript's PostScript with pswrite instead of converting it to PDF with pdfwrite. So this test did not reproduce the bug of pxlmono/pxlcolor showing characters as squares with Ghostscript's PDF as input. Repeating the test with the first line corrected (s/pswrite/pdfwrite/) yields a correct printout.
When I use ps2write in pswrite the problem disappears, but ps2write's PostScript is not DSC-conforming, so not much suitable fopr the CUPS filter chain.
Below is a copy of an IRC discussion which we had about this bug today (everything not about this topic is removed): <tkamppeter> Anyone had a look at bug #690025 recently? <tkamppeter> It does not only occur when Ghostscript applies the "pxlmono" driver to its own PostScript but also when it applies this driver to its own PDF. So it is most probably the driver. <tkamppeter> And it breaks a PDF-based printing workflow, as many apps still send PS which needs to be converted by Ghostscript. <kens> tkamppeter I did look today at #690025 but wihtout any insight. I haven't so far been able to look at the pxl file to see what it looks like. <kens> My assumption is that the problem is the PDF text rednering mode, Tr 3 or Tr 2 where the text is either stroked, or filled and then stroked. There is an open bug against that at present. <kens> However, that ebing the case, it should also fail when the PDF or PostScript is sent to other drivers, which I gather it does not. <tkamppeter> kens, the problem only occurs with the pxlmono (and probably also pxlcolor) driver and it occurs with both Ghostscript-created PostScript (from pswrite) and Ghostscript-created PDF (from pdfwrite). <kens> tkamppeter Not surprised that PostScript and PDF from GS both cause the issue if it is indeed text rendering modes, as the code is the same. However I can't see why the pxl drivers would be the only one to exhibit problems. I'll try again to get my PCL installation working and view the output. <tkamppeter> It does AFAIK not occur with other output devices nor does it occur with pxlmono/pxlcolor and PostScript or PDF input coming from other sources than Ghostscript. <kens> tkamppeter Till, I have managed to run the PostScript file and I do see the 's' in Grayscale rendered as a solid black square. Also the '1' in 100% is a solid rectangle either black or white. <kens> This does not happen when rendering to any other device I've tried (same version of GS, same PostScript file, ie the output from pswrite). <kens> I don't think this is a pswrite/pdfwrite problem per se, since it doesn't happen with other devices, and I don't think it can be text rendering modes, since we started with a PostScript file... <henrys> kens:so you have a postscript file that only produces bad output on the pxl devices? <kens> henrys It seems that wya yes, weird huh ? <ray_laptop> morning, all <henrys> marcos has been handling pxl devices, assign it to him. <kens> OK, I'll pass it his way, I can't really see what the problem is. <henrys> kens:sometimes using -Z# and looking for problems in the gdevpx.c helps. <kens> henrys tried that, no errors reported :-) <henrys> there could also be a resolution issue if a bitmap got into the picture. <rillian> henrys: now I have <henrys> I guess -r600 works... <kens> henrys there are a *lot* of bitmaps. All the text is converted into imagemask operations when using pswrite. Haven't tried -r 600 yet, will give it a go as well. <tkamppeter> kens, pswrite converts all text into bitmaps? Can this also be a problem why GS can run into problems with big input files? <ray_laptop_> tkamppeter: yes, pswrite converts text to bitmaps, ps2write does "real text" <henrys> kens:I guess marcos would be thankful if you could isolate the imagemask that is the source of the 's' being rendered as a square. <tkamppeter> ray_laptop, and pdfwrite, does this real text? <ray_laptop> tkamppeter: yes, pdfwrite also does 'real text' <ray_laptop> tkamppeter: to be more precise, pswrite creates a type 3 font of bitmaps and then paints text referring to the bitmaps in the pseudo font <ray_laptop> tkamppeter: this is from memory -- it's been a long time since I looked into pswrite (caveat emptor) <tkamppeter> ray_laptop: this is bad for the CUPS pdftops filter. if this filter is used, for example to print a PDF file on a PostScript printer the PS file gets much bigger than the PDF input and so the pstops filter or the printer can crash on big input files due to lack of memory. <kens> Apologies, been away updating the bug report. Text 'usually' ends up as bitmaps but I believe sufficiently large glyph will be uncahced and rendered as outlines (with pswrite) <kens> pdfwrirte will usually embed teh original font, and therefore 'real' text. However, there are conditions under which it will resort to bitmaps as well. <henrys> we are trying to deprecate pswrite and move folks to ps2write <kens> tkamppeter the file size inflation and the lack of scalability are why I've been reluctant to have you continue to use pswrite. <kens> However until I get a chance to revisit ps2write and make it DSC compliant there is no choice. <ray_laptop> tkamppeter: so there is stuff that relies on DSC comments later in the workflow ? <tkamppeter> ps2write will only be usable in the CUPS pdftops filter if we have the PDF workflow everywhere, as then the page management is done by pdftopdf and afterwards pdftops makes PS for PS printers. Then non-DSC PostScript is OK. <tkamppeter> If a distro did not adopt the PDF workflow the pdftops filter is run as the first filter and afterwards page management is done by pstops. pstops needs DSC-compliant POstScript. <kens> tkamppeter are you sure that this also occurs when using pdfwrite ? I just tried the testpage-a4.ps file here, running to PDF then converting the PDF to PXL using the pxlmono driver, this works OK. <tkamppeter> kens is this exactly what I did in comment #16 of bug #690025? There the "s" in "grayscale" gets a black square. <tkamppeter> Ghostscript is current trunk on Jaunty. <kens> tkamppeter your comment #16 describes using pswrite, not pdfwrite. <kens> Sorry, the description says pdfwrite, but the command line says pswrite. <alexcher> ps2write can be easily mede DSC-compliant by copying PDF part to a reusable stream and writing DSC-compliant reader in the style of pdf2dsc. Do we want this? <kens> If I use PDF as the input, then it is OK, if I convert the same PDF to PostScript using pswrite then I see the identical problem to starting with the original pswrite output. <kens> alexcher yes we do want this, we need ps2write to be DSC compliant <alexcher> Bot reusable streams are level 3 feature and the whole file is stored in the core. <kens> Would be nice to have level 2 DSC output too of course. <tkamppeter> kens, now I see, this test is wrong, seems that I converted PostScript to PostScript with the first command line .. <kens> tkamppeter agreed, but while using PDF as an input works (for me) converting the PDF to PostScript gives the same wrong result. <tkamppeter> kens, if I correct the test of comment #16, using pdfwrite in the first line I get correct output. I will need another input file. <kens> tkamppeter Given that there's definitely a problem with the pswrite-produced PostScript and the pxl driver, maybe we should just concentrate on that for now. <henrys> tkamppeter or kens:can you simplify the test to 1 character for marcos, that would let him focus on the driver issue. <tkamppeter> kens, in the linked Ubuntu bug it happens when incoming PS is turned to PDF by the pstopdf CUPS filter (calls ps2pdf13) and afterwards fed into GS with the pxlmono driver. <kens> tkamppeter I was just ing regular GS and the pdfwrite driver so I hadn't restricted the version. Possibly there is some reason for this. Could be converting fonts to bitmaps, which might explain the commonality of the issue. I'll try that too. <kens> tkamppeter just setting -dCompatibilityLevel=1.3 doesn't cause a problem for me, teh PDF is still OK with pxlmono, will look further tomorrow. <tkamppeter> kens, I will ask the Ubuntu users on the Ubuntu bug top supply sample input files for me, as I cannot reproduce the problem with pdfwrite. <kens> tkamppeter, OK thanks Till, in the meantime I will reduce the PostScript problem and hope Marcos will work on it. <tkamppeter> ray_laptop, kens: With ps2write there are no squares, but the problem is that it is not DSC-conforming. <kens> tkamppeter yes, we know that ps2write is not DSC compliant. Its a useful clue that it is OK though, like the PDF file, it suggests the problem is the fact that text has been turned into images. <kens> henrys When do you want to start ? ;-) <tkamppeter> DSC conformance is also needed for the PDF workflow, as then the cpdftocps CUPS filter converts PDF to PS at first (using the pdftops CUPS filter) and then applies the PPD options to the PS data (using CUPS pstops filter, required DSC compliance). <tkamppeter> This is needed for PS printers. <kens> tkamppeter I think we just need to accept that we need to make ps2write DSC compliant. It son my little list of things to do. <tkamppeter> So replacing pswrite by ps2write in the CUPS pdftops filter is not (yet) possible. <tkamppeter> kens, In which time frame will this happen? <kens> tkamppeter I'm afraid there is no time frame, its an enhancement, and there are ltos of those to do. Mostly from commercial customers.
I have got answers to my questions on the Ubuntu bug report https://bugs.launchpad.net/bugs/361772 and with this I found out that the squares are NOT produced when the input is PDF from the pdfwrite device. The PPD files of the users are broken and this lead foomatic-rip convert the incoming PDF to PostScript (with Ghostscript and pdfwrite) and then another instance of Ghostscript was feeding the pswrite output through the pxlmono driver triggering this bug. So the bug definitely happens only if the input is PostScript generated by the pswrite device.
Created attachment 4999 [details] pswrite-small.ps A very much reduced version of pswrite.ps. This file contains a single glyph represented as an imagemask, the lower case 's' from Grayscale in the original file. This is the first image to be incorrectly rendered by the pxlmono driver, though there are others in the original file. I've checked the file with the pxlmono driver (on Windows) and the Windows display driver. The pxlmono driver renders this incorrectly (or GS renders the PXL file incorrectly, possibly), the window driver renders it correctly. Hopefully this will reduce the complexity of the problem and help debug it.
THis seems to be the same problem as 690830 - there it caused black characters on transparent background to becomes black blocks, here it caused white characters on colored background to appear as white blocks, (you can say in both cases, the background gets the color of the letters). but both are using a black on transparent code-path.
The test file has both black-on-transparent and white-on-transparent, and is fixed by the improvement mask code in r10303/10305 'implements white on mask (and added black on mask) in copy_mono' . Till: I am not sure why https://bugs.edge.launchpad.net/ubuntu/+source/cups/+bug/361772 and http://bugs.linux-foundation.org/show_bug.cgi?id=158 refers to this as ps2write problem (the problem is in a part of pxlmono/pxlmono known to be "incomplete") - please review, update, retest as appropriate.
Hin-Tak, the references to this bug were added to the mentioned bugs as it was not yet clear whether the problem was caused by bad PostScript input (output of Ghostscript's "pswrite" and "ps2write" devices) or whether the "pxlmono"/"pxlcolor" drivers have a bug.
Till: it is in a part of pxlolor/pxlmono which needs some new code to cover 'all cases', the 'all cases' meaning combination of white or black with a transparent color; so it is an enhancement. It is likely that until recently the compositing (showing the bits below the transparent color) were done by the graphic core, so the driver gets "ready-made" images with black/white plus background, rather than background then black/white+transparent. You can see that it is only done for certain glyphs. I do not know how the decision is done, but this issue in pxlmono/pxlcolor is documented by a very short one-line comment even back in gs 6.0. In any case, the change is just r10303 and r10305 and should apply cleanly to 8.70 or even 8.64. (r10303 is for reverting an earlier change in the 8.6x timeframe; so if r10303 does not apply it is not needed; for gs 6.0-7.0-early 8.x you just need r10305). Feel free to test.
I have checked now with the walking-map-portland-1.pdf (very first attachment) and with Hin-Tak's changes (I have applied them to GS 8.70 of Ubuntu Lucid) and it works perfectly now. Thanks for the fix, Hin-Tak.