Bug 690025

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.