[9fans] An Important Node

[9fans] An Important Node

[Akshat Kumar]

With one network- and PS- incapable printer* in
the household, and several computers with at least
a few users, there was a need to have some sort of
network capable printing device.

The printer is hooked up via (just for added complexity)
USB to the Plan 9 CPU server. Printing amongst Plan 9
computers is easy enough - run usb/print, export /dev,
etc. (maybe a cleaner way? the problem is with /dev/lp7,
which only shows up once usb/print is run), ending with
an lp(1) command. However, other computers are running
Windows or Linux.

So, in order to have Windows see the CPU server as a
network printer, I simply "[Added] a New Printer" on TCP,
port PORT, and IP that of the CPU server, with the device
being Adobe's Generic PostScript Printer, which produces
basic PS pages (something lp(1) on Plan 9 can deal with).

On the Plan 9 side, then, the CPU server listens:

aux/listen1 -tv tcp!*!PORT $home/bin/rc/print &

where the script `print' contains:

#!/bin/rc

lp -H -d officejet5610 >>[2] /sys/lib/lp/log/officejet5610

... and that's all she wrote.


Best,
ak

* OfficeJet 5610 - I highly discourage this product.
  (welcome, HP)

Re: [9fans] An Important Node

[erik quanstrom]

> On the Plan 9 side, then, the CPU server listens:
>
> aux/listen1 -tv tcp!*!PORT $home/bin/rc/print &

makes more sense to put this script in /rc/bin/service/tcpPORT

- erik

Re: [9fans] An Important Node

[Akshat Kumar]

I tried this initially, with the following in the file:

exec /rc/bin/lp -H -d officejet5610 >>[2] /sys/lib/lp/log/officejet5610

however, the program runs as user none, and
requires access to /dev/lp7 (which I believe is
not in its namespace, in the first place).
Perhaps this approach would work better if I
ran usb/print on boot up - although still, the
file /dev/lp7 is chmod 660 for user and group
bootes. Ideas on that one?

The other thing is, I wonder if the data coming
in on the port is actually being piped to lp(1) -
but I can do some tests to figure that out.


Best,
ak

On Mon, May 3, 2010 at 7:05 AM, erik quanstrom <quanstro@quanstro.net> wrote:
>> On the Plan 9 side, then, the CPU server listens:
>>
>> aux/listen1 -tv tcp!*!PORT $home/bin/rc/print &
>
> makes more sense to put this script in /rc/bin/service/tcpPORT
>
> - erik
>
>

Re: [9fans] An Important Node

[erik quanstrom]

> however, the program runs as user none, and
> requires access to /dev/lp7 (which I believe is
> not in its namespace, in the first place).
> Perhaps this approach would work better if I
> ran usb/print on boot up - although still, the
> file /dev/lp7 is chmod 660 for user and group
> bootes. Ideas on that one?

if you put your script in the listen -t directory,
you won't be none.

- erik

Re: [9fans] An Important Node

[Akshat Kumar]

OK, placing this in /rc/bin/service works well now.
Thank you for that suggestion.


Best,
ak

On Mon, May 3, 2010 at 12:07 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> if you put your script in the listen -t directory,
> you won't be none.
>
> - erik

Re: [9fans] An Important Node

[lucio]

> So, in order to have Windows see the CPU server as a
> network printer, I simply "[Added] a New Printer" on TCP,
> port PORT, and IP that of the CPU server, with the device
> being Adobe's Generic PostScript Printer, which produces
> basic PS pages (something lp(1) on Plan 9 can deal with).

What version of Windows are you using?  The XP I have does not seem to
have a mechanism to specify the parameters you mention.  At least not
as such.  On the other hand, how hard would it be to use the http:
alternative?  Anyone know where such a printing protocol is described?

++L

Re: [9fans] An Important Node

[Akshat Kumar]

I've setup Windows 7 and Windows XP to do this.
For XP:
Control Panel -> Printers and Faxes -> Add Printer
Add Local Printer -> Create New Port (or some such)
with Type of Port: Standard TCP/IP
fill in IP and port information, using RAW type of data.
Upon choosing a printer from the provided list, select
any PS printer so you are only sending PostScript
data to lp(1) over the port.
Simple enough.

That was just from memory. Here's a guide that works:
http://www.sketchpad.net/postscript-printer-winxp-1.htm
(but instead of printing to File, select TCP/IP, as mentioned
above).

Since this isn't a Windows help form, I can take further
queries in private on this setup. If there's enough demand,
I can make a web page detailing the procedure. It's really
simple (which is the whole coolness facture due to Plan 9).


Best,
ak

On Tue, May 4, 2010 at 11:48 PM,  <lucio@proxima.alt.za> wrote:
>> So, in order to have Windows see the CPU server as a
>> network printer, I simply "[Added] a New Printer" on TCP,
>> port PORT, and IP that of the CPU server, with the device
>> being Adobe's Generic PostScript Printer, which produces
>> basic PS pages (something lp(1) on Plan 9 can deal with).
>
> What version of Windows are you using?  The XP I have does not seem to
> have a mechanism to specify the parameters you mention.  At least not
> as such.  On the other hand, how hard would it be to use the http:
> alternative?  Anyone know where such a printing protocol is described?
>
> ++L
>
>
>

Re: [9fans] An Important Node

[lucio]

> Add Local Printer -> Create New Port (or some such)
> with Type of Port: Standard TCP/IP

I'm way out of touch.  I never even thought of looking for such a
feature!

++L

Re: [9fans] An Important Node

[lucio]

> ... and that's all she wrote.

Hm, you also added an entry for officejet5610 in /sys/lib/lp/devices,
I presume, as I have nonesuch.  But that's to be expected.  What I
find ultimately disappoining is that I can't get the parallel port on
my server to behave in any reasonable way.

The man pages seem to lie, because they state that:

	The specifiers 1, 2, and 3
	correspond to the parallel interfaces at PC ports 0x3bc,
	0x378, and 0x278 respectively.

whereas it seems that lpt1 is at 0x378.  I don't have the patience to
try all possible combinations.  I know that trying 0x3bc failed
spectacularly, as opposed to 0x378, where the readable registers
return resonable values, but the data port triggers an error message:

	% echo sadfasjdfhgakjsdfhgsakj > /dev/lpt1data
	echo: write error: i/o error

...  no matter the print device setting: I did try each of SPP, EPP,
ECP and ECP+EPP.  Is this bit rot in the printer driver or mere
ignorance on my part?

++L

PS: I also tried USB to drive the printer with equally little success,
but I find that easier to forgive.  And for those who have read this
far, I also found that disconnecting devices from the USB port on the
Sheevaplug cause the (USB outwards) console to disconnect, which
smacks of something being overlooked rather than an unsurmountable
obstacle.

[9fans] plan9 lpt1

[Steve Simon]

It did work for me some years ago,
however I no longer have a parallel printer, sorry.

-Steve

Re: [9fans] An Important Node

[Akshat Kumar]

On Wed, May 5, 2010 at 5:08 AM,  <lucio@proxima.alt.za> wrote:
>> ... and that's all she wrote.
>
> Hm, you also added an entry for officejet5610 in /sys/lib/lp/devices,
> I presume, as I have nonesuch.  But that's to be expected.

Yes, I had to do a fair bit of work to get my OfficeJet 5610 working
with Plan 9. That topic was taken care of in a separate series of
posts a while back. I documented the procedure in my contrib:

/n/sources/akumar/gs


Best,
ak

Re: [9fans] An Important Node

[lucio]

> Yes, I had to do a fair bit of work to get my OfficeJet 5610 working
> with Plan 9. That topic was taken care of in a separate series of
> posts a while back. I documented the procedure in my contrib:

I recall now: my poor memory should not be taken as a reflection of
the value of your efforts and contributions :-)

++L