[cups.general] page ejects on epson dot matrix printer

[Gene Heskett]

On Thursday 16 February 2006 10:05, MarkA wrote:
>OK, this is getting serious.
>
>In a nutshell, I am trying to get an Epson dot matrix printer to
>understand that a 'page eject' signal should advance to the top of the
>next label on a strip of 3.5 x 1 inch tractor fed labels, and NOT
> advance 11 inches.

You will have to teach the printer (if thats possible, check the manual 
for the syntax required) how much of a feed is a formfeed, a chr$(12), 
or, if that crusty code in gs hasn't died of bit-rot over the years, to 
have it do a vertical tab.  That was, AIR, a 5/6" maximum inch feed to 
the next even inch on the page, which is exactly what you need it 
sounds like.

For some printers back in those years it should have been pretty easy, 
but today, since everyone making printers has gotten the attitude that 
the users manual that used to be 1/2" thick and came with it, in 
english, is not an $85 extra cost item and written in 13 languages and 
is still only 1/8" thick.  Everything else is friggin proprietary.

>My setup:  OS: Xandros 3.0, KDE Desktop, Epson LQ-570e 24 pin dot
> matrix printer, parallel port, trying to print on continuous tractor
> fed adhesive labels, 3.5 x 1 inch.

And these do not come in fanfold, folded into an 11 inch format for 
zig-zag feeding?

If there is no marker, or fudge in the spaceing at it goes past the fold 
when coming out of the box, it might be possible to write a macro that 
for this particular ppd, intercepted the chr$(12) formfeed, and 
converted it to the correct number of linefeeds to get to the next 
label, but that would require either some tally of linefeeds issued so 
that the lines of text in the label could vary without screwing up the 
next 3007 labels.  In other words, using linefeeds, divide the 11" page 
into as many labels as fit, 11 I'd assume, and do linefeeds like a 
tab->space conversion, but go ahead and pass the FF at the end of the 
page to maintain something like sync with the fanfold.  Not impossible, 
but might need a trip to the store for headache powders while writing 
it.  :)

Something else comes to mind too, the last time I tried to feed labels, 
the darned things would peel the edge due to the wrap around the 
platen, and get stuck in the works when the head hit the lifted edge 
and hang the printer up till it was picked out by hand, entirely too 
often to make it what I would have called a workable solution for a 
mass mailing list label print job.  That was an Oki 324, also a good 
printer in its day.

>I tried adding a definition for "Label" in the Epson PPD file.  When I
>print a cups test page, I get the usual test page, squeezed onto a 3.5
> x 1 inch space, followed by an 11 inch page eject.

Chuckle, but maybe it saves ink? :)

>When trying to print a series of labels, only the first label prints,
>followed by an 11 inch page eject, then nothing.  Looking at the
> printer with the browser interface gives the message "Processing page
> 2", but nothing happens.  I have not yet installed the 'backend error
> handler', as recommended on the linuxprinting.org site, but I'm
> hoping to teach the printer not to consider wanting to print more
> than one page as an error condition.
>
>WRT the debug output from the cups server, the filters invoked are:
>texttops, pstops, pstoraster, rastertoepson.  Next comes several pages
> of output, including lines with "PageSize = " strings, some of which
> are correct for the job at hand; others are not.

At first glance, the texttops looks like the place to do the FF to what 
is in reality for you, a vertical tab.  There was, at one time in the 
past, a command that did do a vertical tab, but I don't think any 
printer of mine newer than my old Xerox 1650-ro knew about it.

Michael, is that doable?  I don't know, and I haven't walked around in 
ghostscript since gs5.10.  And we all know how old & grey that is.

>
>So, is there a place where I need to define how far to advance the
> tractor on a 'page eject' signal for the Epson?  How do I do that?

The mistake I think that will have to be fixed, is in treating each 
label as a page in the output stream from the list file being read.

Maybe, if the vertical tab can still be done, just buffer 11 of the 
(address) labels up, doing a vtab at the end of each individual label 
except the 11th one, it still gets the FF appended, and feed those 111 
labels to texttops as a single page.  This might be the simplest way at 
the end of the day.

You'll have to configure the printer itself so as to NOT skip over the 
fanfold perf since AIR many of them will unless told not to since that 
effect will mess up the page synch, not a desireable thing.

But doing this prior to the texttops stage seems like the place to do 
it.  Maybe even just preprocess the list file into page length files 
with nothing more fancy than a bash script?  Using something like 
readln() and count the readln() calls to track where you are on the 
page?

Now I'm just thinking out loud, and probably confusing the issue so I'll 
go away. :)

-- 
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules.  I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.