Don't know off hand. If you put Esc"&a+01R" it will go down
2 lines. This is because the command tells it to go down 1
line and without a semi-colon at the end it will go down another. CR by itself may or may not cause a line feed.
You can tell the printer to recognize CRLF or CR as a new line  sequence. So it seems just CRLF by itself would enable more lines (assuming you down 'command' it to go to a specific line or vertical point).

But if you say PRINT #printer%,CHR$(13)+CHR$(10)
it will also go down 2 lines.

I don't understand the previous post:

> If you put Esc"&a_01R" it will go down 2 lines.
> This is because the command tells it to go down
> 1 line and without a semi-colon at the end it
> will go down another.

The Vertical Cursor Positioning sequence:

     {esc}&a#R

will cause the cursor to move to a new position on the y-axis; the movement will be # rows (so for #=1, the movement will be one row); the row height is determined by the current VMI (Vertical Motion Index) setting.

The LineFeed character ({LF} = 0x0a) will also cause the cursor to move to a new position on the y-axis; the movement will be one row, where the row height is again determined by the current VMI setting.

So, assuming VMI is not changed, {LF} should produce the same vertical movement as {esc}&a1R (or {esc}&a+01R).

Where the difference may lie is in the treatment of the CarriageReturn character ({CR} = 0x0d), which may be interpreted by the printer as either {CR}, or {CR} + {LF}. So {CR} + {LF} may be interpreted as {CR} + {LF} + {LF}.

How the printer interprets these simple control codes depends on the current Line Termination setting; this may be set via the printer front panel, but can be over-ridden by the 'Set Line Termination' sequence

     {esc}&k#G

where #:

     = 0   CR = CR,    LF = LF,    FF = FF
     = 1   CR = CR+LF, LF = LF,    FF = FF
     = 2   CR = CR,    LF = CR+LF, FF = CR+FF
     = 3   CR = CR+LF, LF = CR+LF, FF = CR+FF

One point of clarification...

<esc>&a1R    Moves the CAP to absolute Row 2
<esc>&a+1R   Moves the CAP 1 row down the page from current location
              

Jim Asman

Jim

Well spotted; my earlier post was incorrect in implying that {esc}&a1R would produce the same move as {esc}&a+01R.

I still don't understand why cantubas should get different results from {CR}{LF} and {CR}{esc}&a+01R, all other settings being equal; any ideas?

It is all idle speculation without seeing the entire job. I would say that both should produce the same output all other things being equal.

But we need to see how the page is being formatted, how the linespacing is being set.

Maybe on one hand it's at 6 lpi and 8 lpi on the other. We just don't know.

Is the printing that has more lines getting past the bottom margin, or is it something else? I think <esc>&a+1R should trigger a page feed if it puts the cursor past the bottom margin.

Jim Asman

My thoughts exactly jlasman.

I used to use +1/+2R etc a lot but it makes the code harder
to debug. Still use -.5 -.25R etc. but only as needed.
Moving toward all lines with Absolute line # or Vertical
(and horizontal) motion index designations. It may make the file a little larger but is worth it when it's necessary to make a change.