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

Gene Heskett gene.heskett at verizon.net
Fri Feb 17 19:04:34 PST 2006


On Friday 17 February 2006 16:26, MarkA wrote:
>On Thu, 16 Feb 2006 12:42:18 -0500, Gene Heskett wrote:
>> 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.
>
>This model printer has a straight-thru paper path - labels feed in
> from the bottom and out the top, so there is no problem with the
> labels peeling off.
>
>>>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.
>
>I was probably being imprecise in my terminology.  Between each label,
> the output stream contains a '0x0c' character, which is, I believe, a
> 'Form Feed' or 'Page Eject' in ASCII terminology.  The Vertical Tab
> (0x0b) does not appear in the output stream.  I am just starting to
> pour over the references for ESC/P2, to see if a simple character
> translation would do the trick.
>
>Why do you suggest the texttops filter?  I was thinking that the
>rastertoepson filter would be the place to look, since that is the
> step that ties the output to a specific printer control language.

Mmm, wherever you were looking at that output stream and saw the 0x0c go 
by would be the place to put that filter.  Count 10 of them, 
translating them to 0x0b's, and let the 11th one go by.

Possibly this could be done right in the output stage of rastertoepson.  
I haven't looked at that as I doubt my install has such an animal.  
Ahh, yes I do by golly! brb.

It doesn't appear that the 0x0c is coming from there.  There is 2 
mentions of 0x0c in this file, one in this context starting at line 
490:
===========
    /*
      * Check adjacent bits...
      */

      if ((temp & 0xc0) == 0xc0)
        temp &= 0xbf;
      if ((temp & 0x60) == 0x60)
        temp &= 0xdf;
      if ((temp & 0x30) == 0x30)
        temp &= 0xef;
      if ((temp & 0x18) == 0x18)
        temp &= 0xf7;
      if ((temp & 0x0c) == 0x0c)
        temp &= 0xfb;
      if ((temp & 0x06) == 0x06)
        temp &= 0xfd;
      if ((temp & 0x03) == 0x03)
        temp &= 0xfe;

      *comp_ptr++ = temp;

     /*
      * Check the last bit in the current byte and the first bit in the
      * next byte...
      */

      if ((temp & 0x01) && comp_ptr < line_end && *comp_ptr & 0x80)
        *comp_ptr &= 0x7f;
============
and another case where its camophlaged a bit by useing a putchar(12) at 
about line 360:
============
/*
  * Eject the current page...
  */

  if (EjectPage)
    putchar(12);                /* Form feed */
  fflush(stdout);

============
main() has a linecounter, 'y' but it probably not global & therefore 
invisible to that function.  There is a carriage return being issued at 
line 591 also, and this could be wrapped in a counter keeping track of 
the lines fed so far per page.  I believe that I would wrap that 
putchar(0x0d) there with some logic that had 2 more global ints to work 
with so that a vertical tab could be dummied up by taking the 
modcount=mod(linecount,6) as the result, then using that value, wrap 
the putchar(12) in an if/else conditional so that the if (EjectPage) 
would get translated to enough putchar(0x0d)'s to satisfy the mod 
result for the first 10 times it was encountered, effectively doing a 
vertical tab even if the printer does knwo about it, then let it pass 
on the 11th while reseting everything for the next page.

Don't forget to keep a current tally in the added linecount var by 
incrementing it for every putchar(0x0d) done.  If you do a 
--name_of_mod_var in the same context at the ++linecount you should be 
fine.

And of course you'll need some way to switch this behaviour on/off 
according to the print job, so theres a third added variable that might 
have to be gotten from the environment somehow.

Am I making any sense?

>> 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. :)
>
>Your suggestions are most appreciated.  I am going to keep chipping
> away at it, and let you know what comes up.

I'll be listening.  And maybe Michael will accept a well tested patch 
for this added functionality.  It does seem rather usefull to me.

-- 
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.





More information about the cups mailing list