I installed the cups and ghostscript8.51 on Tru64(OSF1 V5.1 1885 alpha). the cups as the spooler and the ghostscript as a ps interpreter. My programm produces the ps file and then it is sent to cups for printing, but, some .png pictures int the ps file can't be printed correctly and just a block, but, the ps file is shown correctly by gs. so I think the ps file which my programm produced is correct, the wrong place is the process of translating the ps to printer-specific format file, the the driver for ghostscript is "pxlcolor" and the printer is hp5100 laserjet. I also found some errors when using gs for printing on hp5100 laserjet, and the printer reported the pcl errors.
Please provide your command line, a PS file that doesn't print, and an output file generated from the PS file by pxlcolor driver.
Created attachment 1763 [details] PS file as input to gs the file input.ps is input to gs for printing on hp5100 jaserjet.
the command line is " gs -q -sDEVICE=pxlcolor -sOutputFile=output.tmp input.ps -c quit" because the output file is too large to create an attachment, I don't attach the output file which the gs produces. My printer is hp5100 laserjet. gs version is 8.51
Would be useful to know what kind of error it is... "I also found some errors when using gs for printing on hp5100 laserjet, and the printer reported the pcl errors." PXL errors tends to print out something like: PCL XL error: Subsytem: ... Error: ... Operator: ... Position: ... These information are *very* important. Since X11 works, it is possible that the "allerged" problem is in the pxl driver. pxl is quite endian-specific and in part 32-bit specific; I have access to a Tru64 box and I can try, but (sigh...) is it possible to have more details symptoms, etc? (the same bug reporter seems to have submitted a few bugs lacking crucial details lately). Also - the hp5100 laserjet is probably also pcl5 or postscript capable? One can try to narrow down to problem with pxlcolor by using the ljet4 driver or send directly, or ps2ps to down-grade to postscript 1/2.
I am Sorry for lacking of detailed description of the errors In hp5100lasterjet, the printer dont't output the errors on paper , but just some png picture don't print on paper correctly ,these png picture are printed to black block on paper, Now I try to use esp ghostscript and cups, the filter system is pstops, pstoraster, rastertohp, the png pictures can be printed correctly, but, the Chinese font can't correctly be printed,I am a Chinese, How can I do? In my country , printing Chinese font on unix platform by ghostscript+cups is a big difficulty. Thank you again ,
I have not tried on tru64 yet, but interesting enough, I have tried sending the postscript direct and sending the output of pxlcolor (gs v8.53 x86 linux) to an HP 4100 (which is both PS and PXL capable), and the pxlcolor print has indeed got many of the graphics missing, compared to the postscript print. The 5100 should also be postscript-capable. In addition, your postscript file looks for 4 chinese fonts which are not embedded. So you will need to configure ghostscript to font-substitute also: MSung-Light-GBK2K-H CFangSong-Light-GBK2K-H MKai-Medium-GBK2K-H MHei-Medium-GBK2K-H So it looks like it is a bug in pxlcolor, and is not tru64 specific, but also applies to the "x86 linux + v.8.53 +pxlcolor + HP 4100" combination also. Will look further.
As for the gs font substitution configuration, you need something like: /MSung-Light <</FileType /TrueType /Path (somefont.ttf) /SubfontID 0 /CSI [(GB1) 4] >>; in your cidfmap. The detail is specific to your site, as you need to decide on "somefont.ttf" yourself and what is available. I can probably provide a config based on the arphic fonts if needed.
There are two other pxlmono/pxlcolor bug reports, which are probably related. Tried pxlmono on the submitted ps file to hp4100 also, and same problem with some graphics gone.
Created attachment 1779 [details] cidfmap the cidfmap file in my system
I have modified the cidfmap , but the last line Chinese font in the ps file can't print correctly. I use the ghostscript(exactly be ESP ghostscript) as "pstoraster" filter in the cups. but gs shows it correctly when type "gs input.ps" on command line. other fonts in this ps file use the TrueType font. I am so confused!! sign!
The cidfmap file seems to be correct, so if you have the font files it refers to (/users/ems/open2000e/data/NariFont/ttf/NariSong.ttf, etc), and the font files are well-formed - with unicode cmap, etc, you should be able to print chinese using the "pswrite" as the filter, instead of pxlcolor. (will need to look at why pxlcolor doesn't work - it should also work). The 5100 is ps capable, (and pcl 5 capable as well), so pswrite, ljet4, should do what you want. if you run "gs -sDEVICE=x11 file.ps" directly, you should get some info on which font it is not happy with and need substitution done.
Created attachment 1780 [details] a simple ps file using chinese text.
this ps file is so simple that it only draws line and show one line chinese font. when I run "gs -sDEVICE=x11 this_file.ps" directly, ghostscript shows this ps file correctly, but when I print the ps file to hp5100 laserjet printer using the ghostscipt as pstoraster filter. the Chinese font cann't print correctly. Why?????
This is crossing over from gs bug report to providing tutorials on cups... and a lot of ambiguity with "can't print" really does not help. All I can say is, as I said, use the pswrite device - try: ps2ps file.ps - |lpr if it prints correctly, then it is a cups configuration problem, and you *should* read the cups manual before filing cups "bug reports". If by "pstoraster", you mean running "lpr file.ps" - that simply does not work and is not expected to work, for very obvious and very basic reasons which you can read up yourself if you type "printer resident font problem" on any search engine.
I am about to have a look ("OSF1 <hostname> V5.1 1885 alpha") so it should be quite close to the reported system whichever way things go, but I am somewhat alarmed by the number of unusual components which are not shipped with Tru64; e.g. Tru64 come with its own spooler and the consequence of having cups grafted on (which may overwrite some of the lpr/lp tools) is unknown. In any case, there are two important questions: The postscript file says "%%Creator: Qt 3.3.4" and have Trolltech notices inside - What program generates this? Tru64 is not shipped with QT. Where do the NariFont come from? Also, does "ps2ps file.ps - |lpr " do what you want?
My programm is based on Qt library, The printing function is provided by Qt, Qt produces the ps file that is sent to cups, Qt only invokes the lp command. NariFont is a TrueType font which emulates the CID font that appears in ps file. NariFont is a commercial font that my company buys. cups invokes GS as the filter, GS is invoked with "pxlcolor" driver. the ps file which Qt produces is correct, the output file after the GS processes is correctly.
(comment 13) what version of ghostscript and what system exactly it is that display attachment 1780 [details] correctly? I have three versions of ghostscript, 8.51, 8.53, and 8.51 patched with fix for bug 688047 on the Tru64 box. With suitable cidfmap (I can read Chinese), the last two do process attachment 1780 [details] correctly, but *not* unmodified 8.51, and for very obvious reasons - using a truetype font for display Chinese is affected by bug 688047. So besides a customized cidfmap, what change were made? and was the fix for bug 688047 applied directly or indirectly (i.e. using 8.52 or 8.53 instead of 8.51 as initially reported?)? the graphic icon disappearing (comment 6) does happen as it does on x86 linux, so it is a generic pxlcolor/pxlmono problem, and can be verified with ghostpcl.
Other than the chinese font config issue (not a bug), there is a genuine problem in the pxlmono/pxlcolor driver drawing white on mask - apparently it has been there since at least gs 6.0 but so far no test ps file has triggered it. Around line 1200 of src/gdevpx.c, there is a comment: /* * The following doesn't work if we're writing white with a mask. * We'll fix it eventually. */
Created attachment 1817 [details] cidfmap using the GPL'ed Arphic Chinese fonts. Here is a cidfmap config using the GPL Arphic chinese fonts to render the text in attachment 1763 [details] and 1780 correctly, for reference as a replacement for attachment 1779 [details], as the fonts referenced there are proprietary and not easily available.
Created attachment 1818 [details] simple file showing one icon of white on mask A trimmed down version of attachment 1763 [details], with just one problematic icon to show effect. gs -sDEVICE=pxlcolor -sOutfileFile=test.pxl test.ps would show the mask problem (either by sending to an HP printer, or via ghostpcl).
Created attachment 1819 [details] trial patch for src/gdevpx.c This is a patch which I have created, to make the pxlmono/pxlcolor driver bebaves much better in the white-on-mask situation, without breaking normal drawing. I haven't quite work out all the details nor understand the reverse-mask-draw code properly yet, but this patch improves the situation a great deal, to the point all the icons are shown correctly except for having its background draw solid white rather than transparent. Will carry on working on it.
Comment on attachment 1780 [details] a simple ps file using chinese text. separating the test cases for the two issues of chinese versus pxlcolor white-on-mask.
The simplified test 1818 seems to be working now. Reassigning back to support and Marcos, he recently worked on this device.
I have forgotten about this - the remaining issue (background) could be related to or similar to bug 690830 and probably worth looking at together. I see my patch (attachment 1819 [details]) was commited as r8733 with a little editing (two brace position and stripped of two debug statements). Somebody trusts my suggestion more than I do...
Created attachment 5513 [details] simple file showing one larger icon of white on mask plus pink rec slightly modified version of the one-icon test file (attachement 1818) bigger and a pink filled rectange at the back. Solid fill seems to also work well Will look at attachment 1763 [details] and see if we can close this.
Created attachment 5514 [details] diff of (pxl->ppm) vs ( ->ppm) at -r300 of the large icon diff of test 5533. Both the original (attachment 1763 [details]) and test 1818 'seems to be working' - having test 5533 is useful, as it looks like there is still a white vertical stripe of about 1/20 inch or 15-pixel as an artifect (which is about 4 pixels for attachment 1763 [details]/1818 and would be missed). It seems the solid-white background I wrote about has become a white stripe on the left on some of the image masks. The test image is exercising the 'else' clause in the middle of patch 1819 exclusively. Probably a little more code there is needed.
Created attachment 5641 [details] new patch Unfortunately the previous patch (which was commited a year or two ago) was wrong. This is the correct version: it does exactly what the 10-year old comment does: setting the mask color to white and also source-transparent only works for non-white + mask; so this patch adds the treatment for white + mask: white + mask is treated by setting the mask color to black, invert it and combine with the background and write it back. See the comments for more details.
The patch was committed with some addition as a bunch of patches leading up to r10305 'implements white on mask (and added black on mask) in copy_mono' (and r10304 which reverts the previous fix).