32-bit ghostscript, required for ImageWriter and other printers using CUPS

The complexity of this build is remarkable. But I did not read anything except the instructions, and look for some 64-bit references, and did not read or modify anything else.

If you can move around Terminal and type a few terminal commands, or as you suggested, use HomeBrew, the whole process is not overwhelming.

I expect that if I needed to modify it in some way I could probably slog in there, make the changes, and do a little debugging and get it working the way I wanted. But I do not want each and every ImageWriter user to have to do this.

What I would dearly love to find is a compiled installable version somewhere, for Users who can't run a MAKE to save their lives. Dr. Koch may have done this work already (see previous postings on this thread). Provided his version works and is 64-bit.

<<Grant, the gs I've been using resides at /usr/local/bin/gs on all my Macs.>>

I see now that is the change Made by Mathew Broughton's script, which I am reading through now. Since his suggested patch borked my computer-to-computer CUPS, I never used his script, relying instead on another suggested location.

Unencumbered by any knowledge of where these things ought to be placed, I copied faithfully another user's suggestion. But I agree

/use/local/bin is probably the right place for that stuff, so I will need to move a bunch of files over there.

IWhi has traditionally been inside Ghostscript. I have a listing of IWhi. That sections is surrounded with multiple levels of conditionals, as if it were meant to include or leave out.

I expect it was left inside Ghostscript because 'the wonky way the rasterized bits are sent' is specific to that printer, not general enough to transfer to other printers so it would "never be needed elsewhere".

That is probably good news. If Dr. Koch's Installer does not include it, it may just be a change in the Make procedure to include IWhi in the compile of ghostscript. And you may be able to "borrow" (or copy) his Installer.

If your ImageWriter printed out "IWhi could not be found" did it use the built-in ASCII characters (i.e., NOT bitmapped fonts that require multiple passes) when it printed that? That would ad weight to the conjecture that IWhi was just not included in that build.

In my opinion, Matt Broughton's script to modify those PPD files is rather a hack, compared to the elegant parameterizations throughout CUPS. The entire CUPS system uses parameter from CUPS.conf to specify the directories where the CUPS component parts can be found. His script makes a quick and dirty patch, directly to the PPD file, referencing a specific directory structure. It is unlike anything else in any PPD or elsewhere in CUPS.

I would like to find a way to preserve the elegance of CUPS.Conf file references, rather than having to revert to an inelegant specific directory reference in the PPD files.

--------

I mentioned elsewhere that his suggestion (and I believe his script) deletes one line from the PPD. But deleting that line makes Sharing these Printers across a Network collapse. (I think this may be because the Sharing file-format between most Shared Printers is now PDF, so you cannot just delete that line without substituting another PDF converter).

The reason to delete was that the foomatic converter to PDF files was not as good as the one built onto CUPS.

I think I may have found a solution, sitting in the middle of Generic Printer PPD. These lines:

*% The generic Printer is a PDF capable Printer

*cupsFilter: "application/vnd.cups-pdf 0 -"

DO Indeed work if substituted for the line from the ImageWriter PPD:

*cupsFilter: application/vnd.cups-pdf 0 foomatic-rip

That substitution appears to invoke the CUPS version of PDF conversion, rather than the foomatic version. Once there is an explicit conversion to PDF, Networked CUPS works again.

If you do the ghostscript build, creating the makefile takes as long as or longer than the compile. If you inspect the input, it has settings that can be changed for anything you can imagine.

I expect one of those is whether to build-in IWhi or not, just like you can build for 32 or 64.

I made an archeological dig on a specific junk pile and came up with my IWhi c paper source code listing from 2010.

Apple Dot Matrix printer/ ImageWriter driver (modified to also support the ImageWriter LQ) -- About 10 pages of C code and comments when printed out. Internal routines and common code for DMP, IWLO, IWHI, and IWLQ.

my listing is from a file:

Ghostscript-8.64/base/gdevadmp.c

in ghostscript 9.27, that file is not in the 'base' source-code directory, but several other gdev files are present. Looking back to what is in Artisoft's repository on Github, the oldest is 9.18, and gdevadmp is not in that one either. So at some point before 9.18, it was set aside. 9.18 repository has 64-bit versions compiled there.

I think someone will have to troll the LinuxFoundation printing web support site or contact Artisoft and find out where the gdevdmp.c code went. We don't need the latest features for ImageWriter (we have been using Ghostscript 8.71 forever) but we do need 64-bit to carry it into Mojave and beyond.

I started at Linux Foundation web site and tried to find source for Ghostscript 8.71. I found an old source code repository. Source for Ghostscript 9.04, and gdevadmp.c is present in the base folder -- (circa August 2011).

base/gdevadmp.c not present in 9.05: it looks like at that point Artisoft is moving more strongly toward GhostPDL, built on top of Ghostscript. That may be the motivation for "streamlining".

A search shows notes about changes for 64-bit versions occurring in early 2011, so this may be the version that still supports ImageWriter (and older gdev's) AND 64-bit versions.

I am trying and failing to coax that source code out of its GitHub repository. I know very little about GitHub. I can inspect the code, but can not manage to get it to send it to me. The list of releases is here:

http://git.ghostscript.com/?p=ghostpdl.git;a=tags

scroll down and there is a

Ghostscript-9.04

... line item. Some of the buttons take you to the directory and thence to the files, which can be individually displayed.

After more digging, the situation looks MUCH more hopeful.

at version 9.05, the log shows that gdevadmp (containing iwhi and iwlo and iwlq) was not removed, it was MOVED to the 'devices' folder.

The records show it survived in 'devices' up to and including version 9.20.

Dr Koch has a pre-built Macintosh installer for 9.20 sitting on his site, referenced above.

At version 9.21, it looks like gdevadmp was removed in a single operation targeting just that file and its supporting files, not a whole batch of things.

If Dr Koch's installer does not do the trick, the files for Ghostscript 9.20 are sitting in a MUCH more recent repository, and look like they could be complied and built in a very straightforward way.