May or may not be of any use to anyone. I'd previously used netparlpr or similar, this time am using lpr-dev by Olaf Barthel

This little gem acts as an 'lpr' (Unix style print queue client), and with some device remapping, sends your print jobs happily on their way.

I'm using a native PostScript printer, a Color Laserjet 4500N, but this should work for text files at least for others.

System:
A1XEG4-933
512MB RAM
OS4 pre-release update 4

1. Grab the archive from the link above and extract it somewhere. You won't 'need' all of the files from it, but I prefer to keep track of where bits came from so I extract it it Utils:lpr-device folder on my system. Utils: is an assign I have into a volume I have labelled 'Apps:'

2. Copy lpr.device into DEVS:

3. The lpr.doc now talks about it's device patching utility, 'OpenDevicePatch,' but this isn't needed for OS4, as it has it's own tool to handle this. Instead, open SYS:DEVS/NSDPatch.cfg and scroll to the bottom of the file. You'll likely see something looking like the following there:
Quote:

DEVICE serial.device UNIT 0 MAPTODEVICE a1serial.device MAPTOUNIT 0 MACHINE=AmigaOne DEVICE serial.device UNIT 1 MAPTODEVICE a1serial.device MAPTOUNIT 1 MACHINE=AmigaOne #DEVICE parallel.device UNIT 0 MAPTODEVICE a1parallel.device MAPTOUNIT 0 MACHINE=AmigaOne

Make a copy of the last line (the one for parallel device) and add the following entries at the bottom of the file:
Quote:

DEVICE parallel.device UNIT 0 MAPTODEVICE lpr.device MAPTOUNIT 0 MACHINE=AmigaOne DEVICE a1parallel.device UNIT 0 MAPTODEVICE lpr.device MAPTOUNIT 0 MACHINE=AmigaOne

The first line _probably_ isn't needed, but I'm playing it safe

IMPORTANT: Do not copy the supplied tool OpenDevicePatch into C or modify your startup files, it is NOT needed!

4. Ok, so now we have to configure the lpr.device to 'point' to the remote network printer. There are several options available for the printer name (or IP), spool location and queue names, which are outlined well in Olaf's document. Refer to that for additional info.
For the name, you can specify either the hostname or the IP address of the remote lpq/printer/spooler. If you are going to use a hostname, make sure you can resolve it from your a1 by typing:
ping hostname

I'm going to just go by IP for my setup.
The next option is where to spool jobs to. You can spool to memory via using the MEMORY option, or to a specific location such as a volume, directory or assign. After learning the hard way that IB and AWeb had tendencies to occasionally hose my filesystem, I have a seperate partition on my system for caches and temp storage, so will use that, DiskCache:lpr (after creating that directory). The last option can be left blank but is the remote lpd's queue name- it will default to lpq, which is a standard default queue name on *nix printing systems. You _should_ know if you need to change this, otherwise we'll ignore it.

Create your configuration as noted in the docc, in this case using the info YOU need, the below shows my setup:
Quote:

setenv save lpr.device HOST=10.0.0.125 DIR=DiskCache:lpr

5. Almost done. Now open Workbench/Prefs/Printer and select 'Use Custom Device' and choose DEVS:lpr.device. Save the settings and reboot.

6. Test it. You can echo >PRT: "Hello World!" as mentioned in the lpr.doc file, or open a file in Notepad and print it.

Misc Notes:
Yes, even the evil OS Windows is capable of providing a Unix style print queue
in the event you don't have a network printer. This would allow you to print to your Windows connected printer via the above, once you set it up and allowed access from your A1. I _think_ the Windows lpr service is an add-on but a free one, a quick Google for 'Windows lpr' should give you what you need to set it up...

Notes added for Final + July '07 update:
Olaf has since made an OS4 native version of lpr, grab from O@4Depot.net

The lines for remapping parallel.device have changed slightly in NDSPatch.cfg
to a single entry:
DEVICE parallel.device UNIT 0 MAPTODEVICE a1parallel.device MAPTOUNIT 0 MACHINE=AMIGAONE
so you can either do as the current doc says with both entries, or simply:
DEVICE a1parallel.device UNIT 0 MAPTODEVICE lpr.device MAPTOUNIT 0
(I commented out the original remap to a1device, then added both original lines in).

Verified - works fine on OS4 Final + July update.

Last edited by wegster on 02-Feb-2008 at 10:01 PM.
Last edited by wegster on 02-Feb-2008 at 08:37 PM.
Last edited by wegster on 14-Feb-2006 at 05:08 PM.
Last edited by wegster on 13-Feb-2006 at 06:27 AM.
Last edited by wegster on 13-Feb-2006 at 04:52 AM.
Last edited by wegster on 13-Feb-2006 at 04:51 AM.

_________________
Are we not done with the same silly arguments and flames yet??!

@wegster

This is a useful guide, but there are a couple of points I think need to be corrected:

1) You can skip step 3 altogether. Just choosing "use custom device" and setting it to lpr.device in printer prefs is enough to do the redirection. This did NOT work for me under update 3, but it does under update 4. If you do step 3, you redirect everything from parallel to lpr.device. In the unlikely event that you have something else on your parallel port (such as an old parallel zip drive, which sucks, BTW, but somebody may have one -- are there even drivers for them on Amigas?) then you couldn't access it. So I think it's better just to use the printer prefs custom device selection.

2) In step 5, you mention also selecting "use custom device" in printerPS prefs. But printerPS prefs doesn't have this option on my system, just a lot of postscript parameters. Also, I notice that printer prefs and printerGfx prefs icons both open the same window now. I think they used to open different tabs in the printer prefs window, but now they are identical. So there is really only one place where you select "use custom device."

Hope this helps

--Stuart Anderson

@mr_homm
Thanks. Step 3 I put in there b/c I'm not convinced every app is well-behaved.

Updated/removed refs to PrinterPS Prefs, you're right.

_________________
Are we not done with the same silly arguments and flames yet??!

@wegster

I'd like to add a word of warning here, because people keep asking me about it all the time: if "lpr.device" fails to print your data, you're basically stuck. This is because the LPR protocol does not offer any diagnostic information on the printing process save for a notification that it either worked, or didn't (if it didn't work you probably know already, and if it worked you probably don't care much about the rest).

That's how the protocol works, and there is nothing you can do about it.

Well, perhaps there is: help porting CUPS to the Amiga

@wegster

My problem is not to use lpr.device, this is explained in the readme. My problem is that I dont have a postcript printer and I dont have turboprint or are willing to spent 70 Euros for it. So I tried to use my PC as a print server, meaning the Amiga sents its proscript file to the PC, then the PC translates this to my Canon printer. It took three or four days till I gave it up struggling with ghostscript and Redmon on the PC. If THERE would be a workshop I would be happy !

@olsen

Quote:

Well, perhaps there is: help porting CUPS to the Amiga

is cups still a posibility for os4.1/2? or are there other solutions the os4 team is considering rigth now?

byebye...

_________________
Michael Merkel
(Michael.Merkel@gmx.net Home)
Member of Amiga-Freunde Pfalz, OS4 Welt

@wegster

The two lines

"setenv xxx yyy" and
"copy env:xxx envarc:"

can be combined as

"setenv save xxx yyy"

_________________
cheers
tony

Hyperion Support Forum: http://forum.hyperion-entertainment.biz/index.php

@olsen

Quote:

I'd like to add a word of warning here, because people keep asking me about it all the time: if "lpr.device" fails to print your data, you're basically stuck. This is because the LPR protocol does not offer any diagnostic information on the printing process save for a notification that it either worked, or didn't (if it didn't work you probably know already, and if it worked you probably don't care much about the rest).

Now noted. It might be interesting to provide an lpq and/or lpstat command however, any chance? (If not, the source is there..someone may want to do so)

Yes, I think CUPS would be great...likely not the easiest for some to get going, but you really only set it up once and it has drivers for virtually everything.

_________________
Are we not done with the same silly arguments and flames yet??!

@tonyw
Thanks, updated!

_________________
Are we not done with the same silly arguments and flames yet??!

@Beeblebrox

Quote:

My problem is not to use lpr.device, this is explained in the readme. My problem is that I dont have a postcript printer and I dont have turboprint or are willing to spent 70 Euros for it. So I tried to use my PC as a print server, meaning the Amiga sents its proscript file to the PC, then the PC translates this to my Canon printer. It took three or four days till I gave it up struggling with ghostscript and Redmon on the PC. If THERE would be a workshop I would be happy !

Well, you can also copy the correct print driver from SYS:Storage/Printers to DEVS:Printers and then select that in Prefs/Printers, assuming that a suitable driver is available, and still use lpr.device as outlined above. It seems the sanest choice for printers right now is basically an HP, and in general, a lot of HP drivers are interchangeable, at least for basic printing.

_________________
Are we not done with the same silly arguments and flames yet??!

@Beeblebrox

I think I understand what you are trying to do. I used a setup like you described up until a few years ago with my Amigas and my networked PCs at home. I uploaded a file with instructions on how to do it to the PageStream Yahoo group called "AmigaPrinting.txt". Here is that file...

=====AmigaPrinting.txt======

Amiga Printing Solution
-----------------------

This solution is particularly relevant if you have a printer with no
Amiga driver and if your Amiga is part of a home or office network with
PCs.

This solution may also be relevant for other platforms on the network
that do not have drivers for a desired printer.

Requirements:
=============

Windows equipped PC, Amiga with working Samba installation networked to
PC. Desired printer to be connected to PC.

Solution:
=========

Any printer attached to the PC can be emulated as a Postscript printer
using Ghostscript and a few utilities that complement Ghostscript
(gprint & redmon). Output from PageStream on the Amiga (or any other
application on the network) can then be sent to this new virtual
'Postscript' printer as if it was an actual Postscript printer.

Method:
=======

PC: Download & install Ghostscript, GSView (includes gprint) and Redmon
onto the PC. All are available from the Ghostscript site at
http://www.cs.wisc.edu/~ghost/. Add a new printer to the PC with the add
printers wizard. From the list of printers, you must select a postscript
printer such as an Apple LaserWriter. Re-direct the output from this
printer to gprint using redmon. Gprint then prints the postscript file
to the PC's printer. Make sure you enable sharing and give it a name for
use over the network. That's it. Now every computer on the network (as
well as the host PC) sees the new Postscript printer on the network.

(The above is just a summary of the installation. The detailed setup
instructions can be found at
http://pnm2ppa.sourceforge.net/PPA_networking/PPA_networking-4.html.).
Follow the instructions to the letter. I have the same setup as the
author and can attest to their being correct (HP722C, Win98SE)

Amiga: This is quite simple. If you already print to this PC printer
with smbclient (or spool jobs with `spooler'), add another printer using
the network name of the new postscript printer installed above.
Reconfigure your existing printing scripts or add add scripts to spool
jobs to this new printer. I personally use the spooler utility. I have
setup a spool directory for the postscript printer. From PageStream, I
print to this spool directory using the AppleLaserWriter II NT
postscript driver and within seconds this postscript file is sent to the
PC and printed automatically.

Performance? Fantastic. I have tested this setup with PageStream 4.1
using jpeg photographs. Output is exactly the same as from Windows
PageStream printing the same file to the same printer (as it should be
as they are both using the same Windows driver).

My Setp:
=======

Amiga: 2500/060 PageSteam 4.1 (latest) using AppleLWriter II NT
Postscript driver, OS3.9, Samba 2.07, MiamiDx

PC: Win98SE, AMD800MHz Duron, 256 MB Ram, Ghostscript 8.xx,
PageStream 4.1 (latest)

Advantages:
===========

1. Speed - Fast. Postscript code is created within seconds from
PageStream and is then sent across the network to the postscript
printer. Your Amiga is then free to continue working on other things.
The Windows machine then does all of the Ghostscript processing work.

2. Output quality - Excellent. Since gprint processes the postscript
file and sends it to the printer using the Windows driver, output is a
good as from any Windows application.

3. Driver - you don't need to worry about having an Amiga driver for the
printer - or substituting for something close. There is no Amiga driver
for my printer (HP722C). I had been printing across the network using
HP550C drivers previously. These drivers could not make use of all of
the printer's capabilities though.

4. Free.

If you have any questions or need assistance please let me know,

====end AmigaPrinting.txt========

hope this helps.

Brian

@wegster

Quote:

wegster wrote: @olsen Quote: I'd like to add a word of warning here, because people keep asking me about it all the time: if "lpr.device" fails to print your data, you're basically stuck. This is because the LPR protocol does not offer any diagnostic information on the printing process save for a notification that it either worked, or didn't (if it didn't work you probably know already, and if it worked you probably don't care much about the rest). Now noted. It might be interesting to provide an lpq and/or lpstat command however, any chance? (If not, the source is there..someone may want to do so)

What lpr.device implements is a transport mechanism, very much like parallel.device transports data to be printed to a desktop printer. It does not implement a print spooler, although it might end up talking to one which then transports the data to be printed to the final destination. Because no spooling is involved, lpq and lpstat would have nothing to report or change. You'd have to do that on the system which implements the print queue.

The problem you run into when something goes wrong with printing through the LPR protocol is that you may not notice that something didn't work, and the printer is very unspecific as to what it didn't like. Every step until the data finally starts flowing into the printing session should prompt an error message if it goes wrong. But once the printer has started to listen to the print request, it can only "nod" or "shake its head" to what came in so far. This is what annoys many users who expect to get at least some sort of human readable error message out of a failed printing attempt. Sadly, that's not to be.

Since the LPR protocol is so old and was intended to be used with line printers which often didn't do much more than to translate ASCII characters and a small set of control characters (backspace, tab, line feed, carriage return; no escape sequences of any kind) into black and white printing on tractor-fed paper of poor quality, it probably doesn't support better error reporting because the printers of that age were so unsophisticated that they didn't produce any better error reports either.

Quote:

Yes, I think CUPS would be great...likely not the easiest for some to get going, but you really only set it up once and it has drivers for virtually everything.

This will definitely take quite an effort to pull off. I've just bought a WLAN bridge with a built-in CUPS client that allows you to hook up a USB printer to it. That might come in handy should my ever trusty LaserJet 4m break down in the distant future. But without Amiga software to interact with it, that CUPS client is useless to me. So here's my motivation to get CUPS running in some form on the Amiga

@Sandpiper

Thanx, this is what I mean and already spent many hours for now. At least I tested this a few minutes ago with your descriptions. Sadly it wont work, I mean redirection of this windows-testpage works. It starts GhostView f.e. after printing to the Apple Laser driver but there is no document given to ghostview. It just says "no document". Thats why there is no output to gsprint either. Maybe there is something different in Win2k, because I dont have a Win98 anymore (or wont use it). I tried 4 Printerdrivers now with all the same result. Dont have an idea why it doesnt work.

@wegster

There is now also an OS4 specific lpr.device (ported) on os4depot.net

lpr_dev

Mark

_________________
IceStar Media Ltd.

@wegster
Hi wegster,
I recently tried using Olaf Barthel's lpr-dev utility for use with my Epson Stylus Color 777 to print jobs through my mac mini which has the gimp-print driver built in. It seems the job appears to travel through the network transom but is either deleted or doesn't make it to the printer queue on the mac mini side. Wondering if I'm missing a configuration entry in my workbench:prefs/internet directory? My current 'lpr.device' file in DEVS: has the line "HOST 192.168.1.3 MEMORY". I'm using the postscript printer driver in the workbench:prefs/printer directory. Got the share printers with other computers checkbox activated on the mac mini printer utility window as well. Any assistance would be greatly appreciated.

Kind regards.

@wegster/all

I have succefully been using my HP ColorLaserjet 2605dn network printer on my OS4 (AmigaOne), with the lpr.device. So it dos work

/Micam

Just bumping for kindergip, as well as checking my writeup, re-installed the A1 and going through it all again

_________________
Are we not done with the same silly arguments and flames yet??!

@janimator

Which version of lpr.device do you use? The OS4 version on OS4depot never worked for me, so I have to continue with the 68K version (v 44.9)

@busytech

Using the OS4 version currently, works fine here.

_________________
Are we not done with the same silly arguments and flames yet??!

@busytech

I also was running the OS4 version just fine on my A1, until the PSU connector fried and killed it.

Still can't afford to get the parts and replace that connector.

_________________
This posting, in it's entirety, is the opinion and/or statement of the author and does not reflect the views and/or position of this site.