Created attachment 23852 [details] color problems 1) Install a relatively recent Linux distribution (Mageia 8) 2) Notice that printing on a Samsung CLP-315 printer using the free driver is far too dark. 3) Go to https://github.com/koenkooi/foo2zjs/blob/master/INSTALL . I don't know if this is the official location for foo2qpdl since it hasn't been updated in a long time but it's the one I found. Install an .icm file as described. 4) Notice that it still doesn't work. Then read the section "GHOSTSCRIPT BUGS" which states that ghostscript past 8.71 has a bug. Get ghostscript 8.71 and build it, copying it to /bin/gs.foo as described. (foo2qpdl actually looks for something specifically with the odd name "gs.foo".) 5) Notice that printing now works. 6) Get and compile Ghostscript 10.0.0 and copy that to /bin/gs.foo. 7) It's bad again. Copy the 8.71 back and it once again works. Optional: Go to your distro and explain this, and they tell you that they are not going to include a very old GS version with their distro, and that this should be reported to you: https://bugs.mageia.org/show_bug.cgi?id=16315 (Yes, the printer has some problems so there are black areas later down the page. No, these black areas do not have anything to do with the dark color problem; notice that the black caused by printer problems goes across the whole page including the white margins.)
(In reply to Ken Arromdee from comment #0) > 1) Install a relatively recent Linux distribution (Mageia 8) > 2) Notice that printing on a Samsung CLP-315 printer using the free driver > is far too dark. There's no way we can do this. We don't have one of every printer in the world to try out. > Optional: Go to your distro and explain this, and they tell you that they > are not going to include a very old GS version with their distro, Perfectly reasonable I feel. > and that > this should be reported to you: https://bugs.mageia.org/show_bug.cgi?id=16315 We don't maintain foo2qpdl, it seems to me that your first port of call should be the maintainer of that. If (as their Github page says) they found bugs then the maintainer should have reported them to us. While I see the section you mention in the Github page, there is no indication that the maintainer has ever reported these problems. I'm inclined to doubt that they are real; if we had genuine colour problems I think we would know by now, we do have a number of customers working in commercial printing to whom colour fidelity is crucial. We're perfectly willing to look into and fix bugs in Ghostscript, but to do so we need to be able to reproduce the problem using Ghostscript. We can't debug some other application's use of Ghostscript. I suspect the change to using ICC profiles to do colour management is the 'problem' and that the application is using these incorrectly, but obviously I can't tell from the information here so far. I'm afraid that sending us pictures of the output doesn't help. If you want someone to look at the 'problem' then we'll need an input file and a command line which reproduces the problem.
The problem is independent of the input file. Color files print properly when I use Ghostscript 8.71. They print improperly when I use 10.0 (or when I use the 9.53.3 that came with my distro.)
(In reply to Ken Arromdee from comment #2) > The problem is independent of the input file. Color files print properly > when I use Ghostscript 8.71. They print improperly when I use 10.0 (or when > I use the 9.53.3 that came with my distro.) We would still prefer to see a file which demonstrates a problem, otherwise we go back and forth with 'I can't see a problem', 'Well I can' which isn't helpful. And we *do* need a Ghostscript command line which demonstrates the problem.
Created attachment 23855 [details] original file that I tried to print
I've attached the original file, which I printed by opening it in Firefox and printing. I have no idea what the command line is. You may need to contact the foo2qpdl maintainer, but I have no idea who that is or if it has a maintainer at all. I just reported the problem in that Github repository and and in response the owner archived the repository, removing all its bug reports. So I don't think he was actually a maintainer, even though he has the only public repository that I know of.
(In reply to Ken Arromdee from comment #5) > I have no idea what the command line is. You may need to contact the > foo2qpdl maintainer, but I have no idea who that is or if it has a > maintainer at all. Sorry, that's not the way Open Source works. That's why the Linux distros won't look at the problem for you either. The way this works is that you report it to the maintainer of the OSS project you are using. They investigate and if the problem is in a 3rd party component they report the problem upstream. And so on until the bug report reaches the top (or bottom) of the chain. At each stage the report made against the project should contain the minimum necessary to reproduce the problem on that project. For example we get reports from Lilypond and TeX sent upstream to us after investigation of reports on their packages from their users, and we upstream bugs to FreeType when our users find problems Software maintainers don't expect (and won't) to have to go and get downstream applications, potentially written a language they don't use, fulfilling a need they may not understand or be completely at home with the subtleties of. For example I can't read music and so am unable to use Lilypond to reproduce Ghostscript bugs. I'm afraid we aren't in a position to go rummaging around in other people's software to try and identify how they are using Ghostscript. We need bug reports to be made in a way we can reproduce. > I just reported the problem in that Github repository > and and in response the owner archived the repository, removing all its bug > reports. So I don't think he was actually a maintainer, even though he has > the only public repository that I know of. Then it sounds like the project is orphaned or moribund, or simply dead. You need to find the current maintainer or find someone to take on the maintenance or create a fork of the project. If you can't manage that then I'm afraid you'll have to regard the project as dead and find some other solution. I'll leave this open for a while in case you manage to find a way to get a Ghostscript command line. As a possibility; from the Github page: DEVELOPER AND DEBUGGING TIPS ---------------------------- If you want to work on this program, I recommend creating a "raw" printer queue directed at the printer, with no protocol conversions. OR, simple copy the file to /dev/usb/lp0 (USB) or nc (netcat) the file (network). Then, you can use the "foo2zjs-wrapper" program to convert Postscript test programs to ZjS format, and inspect them with "zjsdecode" before deciding whether to print them or not. For example: foo2zjs-wrapper testpage.ps > testpage.zm Since that is taking PostScript as an input it seems very likely that 'foo2zjs-wrapper' is invoking Ghostscript, and I'm betting that's a shell script. So looking inside that might be a place to start. Also I see: 7) If it is OK, send "testing.icm" to rick.richardson@comcast.net for inclusion in foo2zjs. So you could try contacting that email address, but it does look like this Github repo is nothing more than a copy of an old tool. So perhaps not surprising it hasn't worked for 10 years.
The call to Ghostscript is in the file "foo2qpdl-wrapper" which is part of foo2zjs. It's a shell script so I can look in it. I've tried to produce a simplified test case but it's possible I simplified too much and this doesn't actually demonstrate anything at all. If necessary I can try again. But: Unzip files.zip to create these four files. icc108710.usecie.ps icc108710.crd.ps icc108710.selcrd.ps input.ps The icc files are created by foo2zjs. The input.ps is actually the output of foo2zjs-pstops but seems to be just a ps version of the file I tried to print. Where gs.foo is Ghostscript 8.71 and gs is a modern Ghostscript: gs.foo input.ps: Displays original file gs input.ps: Displays original file gs.foo icc108710.usecie.ps icc108710.crd.ps icc108710.selcrd.ps input.ps: Displays file, but uses the information in the icc files to change the colors. Presumably, they would look correct if printed. (Of course on screen it looks odd.) gs icc108710.usecie.ps icc108710.crd.ps icc108710.selcrd.ps input.ps: Displays original file *without* using the icc files to change the colors.
Created attachment 23857 [details] 4 files
So looking at the files, this is an archaic way to do colour management, and the workflow risk poor quality. The 'input.ps' file is the output from the Ghostscript ps2write device which only emits level 2 PostScript. Features of level 3 PostScript and some features of PDF, are not supported in level 2 requiring the device to output images instead, which potentially leads to degraded quality. I'm not at all sure why the workflow does this, it isn't necessary and never was. The code then sets up a ColorRendering Dictionary derived possibly from an ICC profile, and sets UseCIEColor. UseCIEColor is a frankly hacky and little-used PostScript means of doing colour management by converting all incoming colours into CIEBased colours and the using the CRD to map them back to device space. It never worked well. It also sets a specific halftone screen. The correct way to deal with this would be to use Ghostscript's built-in colour management and supply the ICC profile directly instead of using UseCIEColor and CRDs. Having said all of that (as a note for the future should it be required); One of my colleagues points out that foo2qpdl is (now?) part of Open Printing, and we suggest that you take the problem there. This page: https://www.openprinting.org/driver/foo2qpdl/ specifically mentions the printer you describe in comment #0 of this thread, and the driver is described as being from 16th February this year. It may be that the problem still exists in that code, but if that should be the case it is more likely that we can work with the Open Printing developers to solve the problem. Probably by not going through this convoluted process with UseCIEColor and the ps2write device. This would have the additional benefit of solving the problem for all users (if it still exists in the OpenPrinting driver), not just those who stumble upon the Github repository.
Created attachment 23858 [details] hand-crafted specimen file It appears that PostScript colour management (the use of Color Rendering Dictionaries) does not work, at all. The attached fie is produced from the files originally attached to this report. It sets UseCIEColor to true, establishes a Colour Rendering Dictionary and sets the PostScript colourrendering to use that CRD. It then fills a rectangle with an RGB colour which should exhibit a clear difference. With 8.71 (before the ICC colour management) the PostScript file renders differently to the output from current HEAD. Adding -sOutputICCProfile= and pointing to the ICC profile also attached here does render the file differently. Not precisely the same as 8.71 but certainly similarly. I've checked through the PostScript interpreter and the UseCIEColor parameter is certainly being set, and is loading the DefaultRGB ColorSpace resource to map the RGB colours into CIE space. It seems that the Color Rendering Dictionary, however, is not being used. I will note that, since -sOutputICCProfile does work, I don't regard this as a high priority. Replacing this: gs icc108710.usecie.ps icc108710.crd.ps icc108710.selcrd.ps input.ps With: gs -sOutputICCProfile=<path to ICC profile> input.ps should be sufficient to resolve the problem, since the 'input.ps' file also contains the specific halftone screen setup. It should be possible to improve the quality by **not** converting the original input file to PostScript using ps2write, though this depends on the entire pipeline and I have no details of this. If the pipeline were altered to use the input file directly, along with the ICC Profile, and the halftone was still desired then you would have to still supply some of the content of icc108710.usecie.ps: %!PS-Adobe-3.0 << /UseWTS true >> setuserparams << /AccurateScreens true /HalftoneType 1 /HalftoneName (Round Dot Screen) cvn /SpotFunction { 180 mul cos exch 180 mul cos add 2 div} /Frequency 137 /Angle 37 >> sethalftone
Created attachment 23859 [details] ICC profile ICC profile apparently for the printer described in comment #0
>ICC profile apparently for the printer described in comment #0 The ICC profile is not the one attached, although that one may be close enough to work. The page https://github.com/koenkooi/foo2zjs/blob/master/INSTALL also describes how to obtain the (proprietary) profile involving a script getweb (which may or may not still work). The one I have saved is samclp315-argyll-0.icm. >gs -sOutputICCProfile=<path to ICC profile> input.ps I confirmed that if I modify the script foo2qpdl-wrapper to do this, then it works with current gs. But it's still a workaround--I just hardcoded the location of the profile file and ignored the result of the previous steps. >https://www.openprinting.org/driver/foo2qpdl/ You'd think so. But it isn't. That page namedrops foo2qpdl, but if you look at the actual link for foo2qpdl it provides at the top of the page, it links to the same old site that hasn't existed for years. If you follow the links to https://github.com/OpenPrinting/ghostscript-printer-app/blob/master/snap/snapcraft.yaml and look at that it says: foo2zjs: # Upstream source is not available any more, using Debian packaging # GIT instead If you then go to that Debian GIT, it's a little newer (foo2qpdl-wrapper is 2014 now) but it still contains the references to gs.foo. And I don't understand how to compile the snap version from Debian as a regular program under my distro, so I can't test it to see if the changes mattered.
Created attachment 23862 [details] ICC profile I was using
(In reply to Ken Arromdee from comment #12) > >ICC profile apparently for the printer described in comment #0 > > The ICC profile is not the one attached, although that one may be close > enough to work. The page > https://github.com/koenkooi/foo2zjs/blob/master/INSTALL also describes how > to obtain the (proprietary) profile involving a script getweb (which may or > may not still work). The one I have saved is samclp315-argyll-0.icm. I didn't even try I just pulled what appeared, from the description, to be the relevant ICC profile. To be honest, I don't really care which one is used, the one I attached is sufficient to demonstrate the problem. > >gs -sOutputICCProfile=<path to ICC profile> input.ps > > I confirmed that if I modify the script foo2qpdl-wrapper to do this, then it > works with current gs. But it's still a workaround--I just hardcoded the > location of the profile file and ignored the result of the previous steps. To be honest, I don't really mind if you want to describe it as a work-around, but IMO its a solution, and a better one than the old hackery. In my opinion its long past time to retire the old, poorly supported and difficult to use PostScript colour management. It never worked well. Using the ICC profile directly works, and means (as I pointed out) that you don't necessarily have to convert everything to PostScript first, with attendant potential quality problems. While I'd like to see this fixed I don't consider it at all urgent. I'd also point out that you are complaining that a project which hasn't been supported for 9 (?) years doesn't work with a project which is still in active development because the actively maintained project has moved on. A work-around for the dead project seems to me like a bonus. > >https://www.openprinting.org/driver/foo2qpdl/ > > You'd think so. But it isn't. Well, it's got the same name and it claims to support the printer you say you are using. > That page namedrops foo2qpdl, but if you look at the actual link for > foo2qpdl it provides at the top of the page, it links to the same old site > that hasn't existed for years. You should probably mention that to the Open Printing people then.
>Well, it's got the same name and it claims to support the printer you say you are using. It has the same name because it's a reference to the same project. But they're not actually *supporting* the project. It's in a section # Unmaintained printer drivers which come as complete package of either # CUPS filter(s) or filters to use together with Ghostscript ... They just pull the project in from Debian and it's not clear that Debian is supporting the project either. (Incidentally, splix also supports this printer. Trying to use that was nightmarish, involving getting files from the manufacturer that were left out of the most recent drivers, requiring archive.org, and ultimately, the output was still too dark.)