PRINT field /p switch - anchor PCL Command in Form

[Guest]

I want to call a particular PCL font at a specified location in a document.
By using the PRINT field command, I can call the font, but it is replicated
to the top of the page, not the anchor location I have in the document (a
form). I can anchor an underline using the same method of PCL Command in
either a paragraph, a cell, or a text box. But, I can't get it to work with a
printer font, i.e., this font is called from the printer, not a downloaded
font from the workstation (i.e., not a TT font).

I have tried various switch parameters, e.g., para, cell, etc. to no avail.

Any ideas?

Thanks,

Peter

 

[Graham Mayor]

If the printer in question is the currently active printer, its resident
fonts should be available to Word to be selected just like the TT fonts.
Check the settings of your printer driver.

--
<>>< ><<> ><<> <>>< ><<> <>>< <>><<>
Graham Mayor - Word MVP

My web site www.gmayor.com

<>>< ><<> ><<> <>>< ><<> <>>< <>><<>

 

[Guest]

"Calling" the font is not a problem. Getting it position in the proper
location on the form is. One of the fonts is a logo, the other a MICR line
(for checks).

I can place the text boxes in the proper location, and insert the PRINT
field command to have it appear. However, the font is no longer in the proper
x/y coordinates, it has moved on the page; it's out of order as well.
Variable data on the form (XML source) is positioned in multiple tables.

Using the /p cell command is a known problem, and using text boxes allows
the most precise placement; so, I am trying to stick to text boxes for fixed
data.

That's what I am after, precise placement of the called font.

P.

 

[Peter Jamieson]

AIUI the \p stuff only works with PostScript (but I don't have a suitable
PCL printer I can test on).

Can you issue the necessary PCL positioning sequences to put the text
exactly where you want on the page, or can the text move around depending on
other items on the page?

Do you have any way to obtain/generate a Windows font of any kind (with the
necessary metric info.) for your PCL logo and MICR fonts? (A long time ago I
used to use a font design component in Corel Draw to do special fonts, but
AFAICR it could only deal with very crude font designs).

Peter Jamieson

 

[Guest]

I don't recall any limitation to the \p re: printer type. There is a known
issue with the "\p cell" and WD2000 http://support.microsoft.com/kb/220295
Use can be found at: http://support.microsoft.com/kb/135569 We have found it
best to replace a PRINT field vs. edit it, once it is in place.

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

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

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.

P.

 

[Peter Jamieson]

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

 

[Guest]

Peter,

Please accept my thanks for the help. Our trial and error process has
produced a variety of results. We can reach a point of success in one part
(finally getting the logo and MICR to print), but then lose ground (it's in a
different place). The underline test was to see if we could anchor a PCL
command; it worked, i.e., we made a test page turning it on/off in various
places within sentence text and types (table, sentence, text box).

We are using a PCL Dump utility (dumppcl) to view the commands. And, we have
edited the PCL at the binary level, i.e., take out a form feed, put MICR font
calls in, etc. Our goal is (was) to have a simple form tool (in Word) that
will generate the basic .PRN file to print on the PCL printer. We then fill
the form from a binary routine of replacement of characters (that's the "@"
command string). This allows us to 'import' variable data into the form
(which is placed in tables in Word). That works fine, as the font definitions
are coming from Word vs. the PCL codes we need to generate for the logo and
MICR (fixed data on the form).

It's a challenge for sure. I think we will give it a couple more tries, then
abandon Word altogether for this project. Ah, the joy of carving new
ground.......

Thanks again,

P.

p.s. Past experience has shown us that Microsoft sees this 'beyond the scope
of the product' and that PCL rests with the printer mfgr (who we are working
with directly), so we haven't considered them for any level of support.

 

[Guest]

Peter,

I wrote a lengthy piece here yesterday that for whatever reason, didn't show
up. Net/Net - I wanted to say thank you to you (and the Community).

Here's where we are at today. We are printing the logo and the MICR line;
but, it is drifting on the page. We are using "Text lines per page" vs.
"Lines per page" to hold a 3-up (on 8 1/2 x 11) design. We set the Top
Margin=0, too, as well as some other PCL commands.

We have reached the point of 'abandon Word'. We can program around this much
easier. We bring in an XML data file, populate the PRN (from Word) file, and
print on a PCL printer. If we could have stabilized the fonts (as PCL
commands) on the Word form, that would have made a good forms design platform.

There are too many quirks in Word functionality for this type of work. Time
to move on.

P.

 

[Peter Jamieson]

There are too many quirks in Word functionality for this type of work.

Time
to move on.

I know the feeling - thanks for the feedback.

Peter Jamieson