This page documents how I got my Samsung ML-1430 working under Linux, in case someone finds it useful. I have:
The first part is how to build ghostscript from source with a third-party driver that can generate the ML-1430's GDI page description language. I don't know what GDI stands for.
Downloads:
Unpack the tarballs ("tar xvfz <filename>"). Let $GS and $SAMSUNG be the respective unpacked directories. Copy $SAMSUNG/gdevgdi.c into $GS/src/:
$ cp $SAMSUNG/gdevgdi.c $GS/src/
Then append $SAMSUNG/smartgdi-contrib.mak to $GS/src/contrib.mak:
$ cat $SAMSUNG/smartgdi-contrib.mak >> $GS/src/contrib.mak
Now, edit $GS/Makefile.in, adding "$(DD)gdi.dev" to the "DEVICE_DEVS3=" line, yielding something like
DEVICE_DEVS3=$(DD)gdi.dev $(DD)deskjet.dev $(DD)djet500.dev $(DD)laserjet.dev ... etc.Or, just run the command
$ perl -p -i -e 's/^DEVICE_DEVS3=/DEVICE_DEVS3=\$\(DD\)gdi.dev /' $GS/Makefile.in
Now there's the issue of fonts. In the directory http://ftp.gnu.org/gnu/ghostscript/ there are several tarballs with fonts. However, my distribution already has an older ghostscript with its fonts. So I just modified GS_LIB_DEFAULT to refer to /usr/share/ghostscript/fonts, so my GS_LIB_DEFAULT line (still in $GS/Makefile.in) reads:
GS_LIB_DEFAULT=$(gsdatadir)/lib:$(gsdir)/fonts:/usr/share/ghostscript/fontsI could also have copied or symlinked the contents of that directory to where the new gs will look for them. If you mess up and don't get enough fonts, then when ghostscript is used on a .ps file you'll get "Error: /invalidfont in findfont" or some such error.
Finally, proceed to configure and build. I like stuff to go into /opt:
$ ./configure --prefix=/opt/gs-7.07-gdi $ make $ make install(Note that if you are not root, you will have to first become root and create /opt/gs-7.07-gdi. Alternatively, pick a directory for which you already have write permission.)
Now to verify things worked, run "/opt/gs-7.07-gdi/bin/gs --help" and check that "gdi" is among the list of available devices, and that at least one of the directories in the font search path has lots of .pfa, .pfb and .afm files (maybe among others).
For convenience, you may want to put a symlink in /usr/local/bin that points at the /opt/gs-7.07-gdi/bin/gs executable.
Now that you have a ghostscript that can generate GDI, use a command like the following to convert a postscript file input.ps to GDI file output.gdi:
$ /opt/gs-7.07-gdi/bin/gs -q -dBATCH -dSAFER -dQUIET -dNOPAUSE \
-sDEVICE=gdi -sPAPERSIZE=letter -r600 -sOutputFile=- - <input.ps >output.gdi
This GDI file can now be sent directly to the printer. Mine is connected to the parallel port (/dev/lp0). (I don't know how to do this via USB.)
$ cat output.gdi >/dev/lp0The document should now be being printed. If you get "permission denied", you need to adjust the permissions on /dev/lp0, for example (as root)
# chmod a+rw /dev/lp0This allows any user on the machine to send data to the printer. You might want something more restrictive depending on your setup.
In practice, I use a pair of scripts, both in my $PATH:
(Note that despite its name, lpps does not use lp or any other spooler interface; it just cats the file to /dev/lp0.)Rather than sending files directly to the printer, it's more typical to have some kind of print spool software that can buffer the requests and send them to the printer one at a time. At this point you're ready to explore spooler options if you want; the spooler will just need to know to use your new gs binary and the gdi device therein. Personally I prefer the simplicity of catting files so I have not set up any spooler.
The printer came with a CD containing some linux drivers. I was impressed with the apparent level of linux support, so wanted to try them. However, the installation software wanted to install the drivers for use with a print spooler, either LPRng or CUPS. I chose to try with CUPS since my brief assessment of the two was that CUPS was better designed; I could be wrong.
Since I didn't have CUPS already, I built it from source. That went smoothly, and I could access the CUPS configuration via my web browser.
However from there it went downhill. I couldn't figure out how to directly tell CUPS about the printer. It has an "Add Printer" button, but it didn't request nearly enough information; it couldn't possibly work. I deleted the entry.
Then I manually put ML-1430spl.ppd from the CD into cups-1.1.20/share/cups/model, and ran
root:/opt/cups-1.1.20/sbin# ./lpadmin -p ML1430 \
-E -v parallel:/dev/lp0 -m ML-1430spl.ppd
This resulted in an apparently valid printer entry, but attempting
to print yielded
unable to open print file "/opt/cups-1.1.20/var/spool/cups/d00001-001" - Permission deniedin the browser interface.
Looking online I found a suggestion in the CUPS FAQ to set LogLevel to "debug" in cups-1.1.20/etc/cupsd.conf, which I did. Then I tried printing again, and cups-1.1.20/var/log/cups/error_log contained
E [22/Jan/2004:20:15:33 -0800] [Job 1] unable to open print file "/opt/cups-1.1.20/var/spool/cups/d00001-001" - Permission denied D [22/Jan/2004:20:15:33 -0800] [Job 1] /opt/cups-1.1.20/lib/cups/filter/ppmtogdi: No such file or directory
The first problem was solved by chmodding a+rwx a bunch of directories (even though cupsd ran as root!). Whatever.
The second was "solved" by copying ppmtogdi from the CD into the lib/cups/filter directory. The samsung installer hadn't even copied that file into its own install target directory... But then the error changed to
E [22/Jan/2004:20:22:28 -0800] [Job 2] Could not find a suitable printer!which is exactly what ppmtogdi says when run manually from the console.
Now, since the .ppd is just a relatively short text file, and mentions ppmtogdi, I surmise that ppmtogdi is actually the program that does what I want (namely generate data the printer can directly consume), though I don't know what "ppm" might be. However, this program doesn't respond to "--help" and I can't find docs (let alone source) for it, so I gave up on getting it to work.
The samsung CD contained an installer (that I ran) which copied some things into an installation directory I specified. Among them was samsung-config (apparently a version of BrightQ), a GUI program that continues the Unix tradition of overusing the name "lp":
This seemed promising and all, and (as shown in the screenshot) I was able to tell it I had an ML-1430. It spewed some errors about permissions on /dev/lp0, which I fixed with some more chmodding (but I was running as root!). However, printing a test page never worked, and I never got the impression it was actually doing anything (it is frustrating that "State: Idle" is not marked as to whether it is the state of the printer (implying successful communication) or the state of the spooler (implying nothing)). I gave up.
In case anyone gives a rat's *ss, I got my ML-1430 from letterfolders.com for $200. I bought it there because they were the only place claiming to still carry the ML-1250, which I'd read good things about. But in fact they did not still have the ML-1250, and instead "automatically" upgraded me to the ML-1430. I suspect I could have gotten a better deal if I'd known in advance it was the ML-1430 I was getting. Oh well.
By far the most helpful resource was a post by Ross Vandegrift at linuxprinting.org explaining how he got the ML-1430 working. The info on this page is basically an expanded version of his post, plus a change to where to put "$(DD)gdi.dev" because of a version difference between ghostscript 7.05 and 7.07.
Most of the detailed build instructions came from the README in Samsung-SmartGDI-all-GS.tar.gz. That GDI driver, which is what makes this possible, includes contributions by Till Kamppeter and Grant Taylor, the maintainers of linuxprinting.org. It's not clear (to me) who wrote the original gdevgdi.c, but thanks!
This post and this post refer to the same "Could not find a suitable printer!" problem. No one replied with solutions, though. Also note that I didn't bother trying to contact Samsung about the problem (it would mean mentioning "Linux" to a support monkey and, well, no one wants that).
As usual Google has quite a bit to say, e.g. this search of linuxprinting.org for ML-1430 and this one of linux-related pages containing ML-1430.
linuxprinting.org seemed like a good place to start, but there is no entry for the ML-1430; the closest appears to be the ML-1250. For the ML-1250 they recommend the pxlmono ghostscript device, which didn't work when I tried it (catting the output to /dev/lp0 seemed to have no effect). Later I found the Samsung FAQ page, which does mention the ML-1430.
Despite my general linux printing (esp. spooling) ineptitude, it works. The print quality appears to be very good, but I've only had it for two days so we'll see.
I've now had the printer for more than a year, and it's still performing reasonably well.
Someone sent me email about their experiences with the ML-1430 on Gentoo with a more recent Ghostscript version. Bottom line: he got it working, but with plenty of Linux-style "excitement".