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

[MarkA]

On Fri, 17 Feb 2006 22:04:34 -0500, Gene Heskett wrote:

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

Just to let you know where things stand... 

I have the label printer working.  Since each label follows the same
format, I didn't really have to worry about counting lines.  By happy
coincidence, translating the x0c character to a x0a results in the correct
spacing, so I just wrote a little sed command to do the translation,
sending the resulting stream to the printer with the -o raw option.  As
soon as I write a little shell script to set all the correct parameters
for the printer at the start of the job, I'll be done.  Epson recommends
that a x0c be sent at the end of a job, so I may still keep working on
getting that to behave correctly.

The OTHER problem is trying to get a Brother MFC printer to work correctly
from OpenOffice 2.0.  It will print the first job correctly, but
subsequent attempts to print result in an output with multiple character
substitution errors.  I am in the process of exchanging e-mail with the
Brother support center on this issue.  I suspect that it is the printer
itself, as the same jobs sent over the network to a CUPS server on a
different computer print correctly.

Thanks again to everyone who took the time and interest in my little
struggles.

-- 
MarkA
(still caught in the maze of twisty little passages, all different)