I think we are probably talking at cross-purposes.
Please don't get confused here: if you need to talk to Microsoft directly,
submit a support incident through one of their standard mechanisms. Most of
the people in here are volunteers.
AIUI what you are saying is that the PRINT field doesn't place the text
where the PRINT field is located, and that using the \p switch doesn't help.
Personally I would have hoped that Word would be smart enough to position
text starting from where you inserted the { PRINT }, but that obviously
isn't working.
I don't recall any limitation to the \p re: printer type
I recall that
a. it doesn't work for printer drivers that do not support the necessary
GDI passthrough facilities
b. Word Help papers over that and talks about PRINT working with PCL and
PostScript. In earlier versions of WIrd/Windows, PRINT used to work with
Epson escape codes, for example.
c. Al the examples in Word Help concerning \p are PostScript examples, and
IMO only really make sense if you're working with PostScript, because PCL is
really about emitting a sequence of control codes, whereas PostScript is
rather more about describing the layout in logical terms, then filling in
the data.
Perhaps your experience with PCL and PRINT says that it should work, in
which case talking to MS directly is more likely to be fruitful.
However, if \P doesn't work, the only approach I can think of is to issue
your own PCL positioning sequences, and that's where I start getting a bit
lost in your message.
We have tried all versions of Office, inc. 2007. No change. We are editing
the .PRN at the binary level for the variable data, so if push comes to
shove, we can edit the x/y, too.
OK. But have you tried issuing PCL positioning commands within the PRINT?
(You can issue a sequence of codes using numbers e.g. { PRINT 1B 00 25 }
etc. - ugly but perhaps feasible)
We are using .RTF as the source file to try
and strip out any of WD formatting that is unnecessary (.DOC or .RTF work
the
same way).
OK, I agree that .doc and .rtf would work the same way in this respect.
We think that underline works because it's an attribute and not a font,
per
se. And, unlike the underline, in this example, there is no on/off to the
PCL
sequence (begin lower case, end upper case).
OK, underline previously unmentioned: does underline "work" in the sense
that Word puts the underlines in the right place even if it doesn't display
the characters/font data you want?
All other form elements stay in place, e.g., tables and text boxes; the
font
overwrites the area that it "lands" on.
We use our own control characters to place variable text, e.g., "@BA",
that is replaced as a binary transfer.
This > doesn't move the form elements. So, it's something in Word that is
allowing
these form elements (table, paragraph, text box) to move when they only
have
a PRINT field command string as the only 'value' in that element.
I got lost at this point & suspect I could not follow without having a
similar PCL printer to experiment with. But can you for example see what
Word is outputting in the PCL stream?
Peter Jamieson