How to extend print area for columns

[syuol]

I have the following PCL code:

<1B>&l2a1o5.50C<1B>(s0p16.67h0T

This prints out things exactly how I need them with the exception of the columns. It prints out landscape and everything fits on the page. However the lines go a little over half the page then wrap on the next line. I can play with the numbers to get the amount of columns I need, I just need the starting point (what the code will look like). Messing with page length, text length, and HMI don't seem to be working but I could be doing it wrong.

Secondly does it matter if you put breaks between the commands?

For instance is the the same as the one above:
<1B>&l2A<1B>&l1O<1B>&l5.50C<1B>(s0P<1B>(s16.67H<1B>(s0T

I've wasted way too much paper trying to figure this out.

 

[DansDadUK]

The first set of sequences:

<Esc>&l2a         Page Size: Letter
       1o         Orientation: Landscape
       5.50C      Vertical Motion Index (5.50/48 inches)
<Esc>(s0p         Primary Font: Spacing: Fixed
       16.67h     Primary Font: Pitch (16.67 characters per inch)
       0T         Primary Font: Typeface (identifier = 0)

is just the 'combination sequence' equivalent of the second set:

<Esc>&l2A         Page Size: Letter
<Esc>&l1O         Orientation: Landscape
<Esc>&l5.50C      Vertical Motion Index (5.50/48 inches)
<Esc>(s0P         Primary Font: Spacing: Fixed
<Esc>(s16.67H     Primary Font: Pitch (16.67 characters per inch)
<Esc>(s0T         Primary Font: Typeface (identifier = 0)

and should have exactly the same effect.

 

[DansDadUK]

>> ... the lines go a little over half the page then wrap on the next line ...

Without seeing an example of how your 'lines' are output, in relation to the above initialisation sequences, it is difficult to offer any advice.

Attached is a simple .PRN print file, containing your first set of sequences, followed by three (LineFeed terminated) lines of data (the longest being 132 characters long) and a 'reset' sequence (to cause the printer to end the job and eject the page).

It prints fine on my local LaserJet 1320n when the contents of the file are 'sent' to the printer.

 

[DansDadUK]

... and here's an analysis of that simple print file:

<Esc>&l2a         Page Size: Letter
       1o         Orientation: Landscape
       5.50C      Vertical Motion Index (5.50/48 inches)
<Esc>(s0p         Primary Font: Spacing: Fixed
       16.67h     Primary Font: Pitch (16.67 characters per inch)
       0T         Primary Font: Typeface (identifier = 0)
 ..data..                  1         2         3         4         5  
                         6         7         8         9        10    
                      11        12        13
<CR>              Carriage Return
<LF>              Line Feed
 ..data..         1234567890123456789012345678901234567890123456789012
                  3456789012345678901234567890123456789012345678901234
                  5678901234567890123456789012
<CR>              Carriage Return
<LF>              Line Feed
 ..data..         Above is a long line consisting of 132 characters
<CR>              Carriage Return
<LF>              Line Feed
<Esc>E            Printer Reset

In the above analysis, the long lines are wrapped to provide a readable display, but in the print file, the lines are not wrapped - and they should not be wrapped when the .PRN file is 'printed'.

 

[syuol]

Thank you dansdaduk! I appreciate your help. I'm trying to get this working at work and I'm home right now. On Monday I'll scan in a sample of the problem. It seems as if the logical page is set to only 60% width wise and that's if the windows generic/text driver is set for landscape. I can print all the way across the page using the specific printer driver but then i cant set the pcl or all settings i need. The printer I'm testing on is a Lexmark t630. The main printer I need to get it working on in the end is a Lexmark t652. I have others I can test it on though (hp, dell, Savin, etc). In the end I'm hoping it won't matter what printer it's printing on.

We actually had this working just not using PCl code. The print job came from a Solaris box to a cups print server then to the printer. The printer PCl emulation settings were set for landscape/fonts/lines per page. We are switching out the cups server for a windows print server. I think everything will work as is if the windows print server is using a postscript driver. I'm trying to make this change to remove the need to make the hard changes on the printer.

 

[jlasman]

A couple of things. Don't scan anything. Post the actual PCL file that is failing and we will get to the bottom of this very quickly.

In the meantime, I would suspect a Unix printer interface script to be the likely source of your problem. How was the PCL file created? My guess is that the script is inserting the LF's.

Use the "raw" option, however it is done with your interface. On my SCO box, simply adding -o raw to the lp command will do the trick. That should keep it from meddling with your data on the way to the printer.

In raw mode, you may have to add <esc>&k2G to your printer setup in the PCL file to prevent the text from running of the page on the right hand side.

Make sure that ALL the printers you intend to use are PCL5 printers.

Jim Asman

http://www.spectracolorservices.com

 

[syuol]

I'm not sure exactly what you mean by the "actual PCl file". From the file provided earlier it looks like the raw data. If I change the port to file, it doesn't have the PCl code in it. The only way I've generated that in the past is putting the printer into hex dump mode and generating a printout with it.

I can try adding -o raw to the lp command though

 

[jlasman]

Wait a minute.

How exactly is the document being created?

And then how does it get to the printer and how are the PCL codes injected into the print stream.

It will be very telling when you simply 'lp' the test file that dansdad posted.

Let us know.


Jim Asman

http://www.spectracolorservices.com

 

[syuol]

It's reports out of our erp system. The printer setup in the system is just name and lp command. Then the underlying solaris os has the printer conf file redirecting the job to the windows print server. I have that set to generic text printer to set the options in my first post. Previously the jobs routed through a cups server and the physical printers settings were set to default to landscape, lines per page, etc.

Once I get a second on Monday I'll test things out and let you know the results. Thanks for the assistance Jim.

 

[jlasman]

Assuming the erp report is created on Solaris to begin with and through the printing mechanism is spooled on a windows server, then it might be possible to take the destination printer offline and grab the spool file from the windows server before it prints.

If you can do that, I suspect you would find that the LF's are physically in the file and weren't there in the original "text" file. If there isn't a raw mode or queue, then look for a binary mode or something similar.

I think we are close.

Jim Asman

http://www.spectracolorservices.com

 

[DansDadUK]

>> ... and that's if the windows generic/text driver is set for landscape ...

To reinforce what Jim has said about using 'raw' mode, you need to determine if and where additional LineFeed characters are being inserted - so 'capturing' the output at various stages is going to help enormously in determining what is going on.

Problem could be on the *n*x side (which Jim has already discussed), or perhaps on the Windows side?

We need to be clear about whether the Windows printer instance is being used as a 'normal' local printer (in which case the driver will set its own printer controls, which are very likely to conflict with your injected PCL sequences) or just used to identify the 'transport' (i.e. destination port).

I can't remember off-hand what setting is required to ensure that an incoming spool, which already contains formatting/control sequences, is just 'passed-through' to the target port, rather than being processed by the associated driver.

... nor what criteria are used to determine that the incoming spool is already formatted (i.e. 'raw').

 

[jlasman]

One sanity check in a PCL context.

It is possible that the interface script is setting the right margin and enabling "end of line wrap" which would explain the behavior you are seeing. Before chasing any of this you might add onto the end of the PCL setup code <esc>&a1C which disables the end of line wrap.


Jim Asman

http://www.spectracolorservices.com

 

[DansDadUK]

@Jim

Slight typo, perhaps; your suggestion:

<Esc>&a1C = Cursor Position Horizontal (column 1)

should be:

<Esc>&s1C = End-of-Line Wrap: Disable



It would still help enormously if we could see 'captures' of output at various stages, rather than trying to piece together (in the right order) what may (or not) be in the source document, together with what is injected (at different points?) by model scripts, or transport mechanisms, or printer drivers, etc.

 

[jlasman]

dansdad,

YES! You are correct.

Thank you for catching that. Put <esc>&s1C at the end of your PCL configuration and see if the problem goes away.




Jim Asman

http://www.spectracolorservices.com

 

[syuol]

I added the line wrap code to disable PCL, I think I tried that already but it never hurts to try again. So I have right now:

1) Added Line Wrap Code so now I have: <1B>&l2A<1B>&l1O<1B>&l5.50C<1B>(s0P<1B>(s16.67H<1B>(s0T<1B>&s1C
2) Added -o raw to my lp command command on the Solaris Source box.
3) I was going to set the print processor to RAW on the windows box but looks like that's the default for Generic/Text only print driver. The protocol for the port is also set to RAW.

I tested a printout at this point and it still had the line wraps.

I changed the port configuration on the windows box so the job would get stuck and I could try and track it down. I found windows sticks it's spool files in:
c:\windows\system32\spool\Printers
The job created to spool files:
00219.SPL - This contained just the data, no PCL
00219.SHD - This looked to be binary

4) I tested sending Dan's test file using just an lp command from the Solaris box. . . .and it looks good. All 132 characters print without the line wrap. This leads me to believe that the ERP software is entering the linewrap, like you guys said. I'm a bit confused though. I put the Lexmark T630 in hex mode and printed the job using the windows generic text driver and I can see the line feeds (carriage returns or whatever they are) where I expect the line to continue. However if I change the driver on the windows box to PCL and print, the lines don't wrap were they did with the generic text driver and instead run to the end of the page (then wrap since they are out of physical space). This seems to indicate that the generic text driver on the windows box is adding the lf/cr's. . . .

I'm severely confusing myself now. I think I'm losing my mind. I printed my test file using the generic text driver then switched to the pcl and printed. I'll admit I did it pretty quickly. But one of the print outs came out completely correct. I've never had that in all my testing. I've tried my worst to replicate it printing out correctly with no luck.

I really do want to capture the data/output at various steps. I'm just not sure how to do that.

 

[syuol]

I'm fairly certain this has something to do with the windows generic text only print driver.

If I set the driver to portrait I get less columns before it wraps. I changed it back to landscape and changed the driver from "Letter" form to "Letter Extra". I printed more then it has been but still wrapped before it should have.

 

[syuol]

Using the paper size: "WIDE132" in the windows generic text print driver seems to have fixed the wrapping problem. I don't quite understand why the paper size would force a set number of columns but I'm not going to complain if this ends up fixing the problem. I'm going to do a bunch more test printing and a few different printers to see how it goes. I'll let you know.

 

[syuol]

Looks like picking the WIDE132 and setting it landscape in the Windows Generic Text Driver was the fix. It's printing correctly on a few different printers. Thank you guys for all the work!

 

[DansDadUK]

Don't know if it's relevant, but I came across the following Microsoft Knowledge Base item, which describes how:

"The LPD service can be reconfigured to ignore the format control command from the LPR client and always assign the RAW data type".

I think that what this is saying is:
[ul]
[li]Regardless of what parameters are in the cfa control file sent (along with the dfa (data file)) in an lpr print job to Windows from *n*x, the data file will be interpreted as raw.[/li]
[li]Without this reconfiguration, it seems (at least on the referenced versions) the print processor may conclude that the data is text (rather than raw / binary), and apply page formatting controls.[/li]
[/ul]

The item is for Windows XP Pro and Windows Server 2003 (and some earlier versions), but may perhaps still be applicable to current Windows versions?

 

[DansDadUK]

... but perhaps if would be best to first ascertain just what parameters are written to the cfa file when your report is printed.

i.e. perhaps the -o raw suggested earlier does NOT cause the *n*x end to pass the file across as binary (i.e. as perhaps -o l might do if Windows lpr was the sender?)