Proform does not understand how to print a graphic image, such as a .tiff file or a .bmp file. I can tell you how I would do what you are suggesting creating the template with Word Perfect.
a. Scan document to .tiff, .gif, or .wpg format.
b. create a new wp document, include the graphics file, set the size to be the entire page, and set "don't wrap the text around the graphic" option.
c. place the [texthere] in the upper left hand corner in the correct font for the data.
d. print to disk and use the result.
Why do you have to print on full size paper? I run all sorts of small stock through our printers? (just a question)
What kind of paper are you using? Are we talking plain white paper which costs practically nothing? Or is this some special paper? My initial advice is to waste paper and print each on its own page.
> Since I have 6 types of tickets/vouchers, I could define 6*4 = 32 page size > forms to cover all possibilities but in case of modification ...
Or you could say that your page is made up of four different sections, each of which could contain any of 6 different forms. Each form could be designed separately, then printed to disk 4 times with 4 different sets of print margins to force it into the correct section of the form. Your progress program then needs to select each file in sequence.
The extra trick to doing this is you would have to go into each print file and remove any codes which do a printer reset (1b45) or page feed. Then you would need to create a file which only does a page feed. Let's call it DONE.hpl. (check http://www.mnopltd.com/profdiag.htm for tools which can help you do this. In the case of PCL you can zap the characters to hex 00.)
For instance, you have Tickets A, B, C, D, E, F. These can print in locations 1, 2, 3, 4. Your progress program generates data which looks like this:
!FILE! A1.hpl
data
..
!PAGE!
!FILE! C2.hpl
data
..
!PAGE!
!FILE! D3.hpl
data
..
!PAGE!
!FILE! F4.hpl
data
..
!PAGE!
!FILE! DONE.hpl
!PAGE!
This means that if you must change a ticket format you have only one file to change, although you have to print it 4 times with different margins. If you are really clever with your word processor, you may be able to include the same ticket format file in 4 different master documents each with different margins.
> My idea is to combine 4 separate forms in a single page size form at print time.
See above. Your problem is that each form has fields printed at a specific pixel position on the page.
The form does have to have multiple rows. Originally, the application had to fill in each one, even if that was blanks, eg
item12,
cost12,
That is what you see the sample purchase order code doing.
We added a command line flag in later versions which instructed Proform to not write out anything if there was no value found for a field name. This had some benefit for allowing programs to be less careful.
We determined that the problem wasn't Proform, because we did a straight "lp" command using our template and the problem was still there. You suggested to try the "-o raw" option. Unfortunately, it didn't seem to make a difference. So, I'm wondering if this problem is proprietary to SCO. Would you have any other suggestions? :)
Depending on your printer interface script, the -oraw may not have any effect. Examine the script, located in /usr/spool/lp/admins/lp/interfaces and follow the logic. You are looking for a command like:
stty -opost 0<&1 1>/dev/null 2>&1
The -opost is turning off output postprocessing, which is what seems to be hozing your output.
You have the right to use Proform as it is built into XXXXX XXXXX. You only have the right to DEVELOP Proform applications in one location. In other words, don't make 20 copies of the manual, nor tell 20 different developers to call me and cry on my shoulder.
A .hpl file is merely a PCL printstream which has been printed to disk. Select the windows print driver you want to use, and connect its output to a file.
Not presently. That leaves two unpleasant issues regarding the use of Proform on Windoze:
- As a DOS executable it brings up a window.
- Printing involves DOS functionality and hence print redirection.
We have been lazy about the coding necessary to:
- Make Proform run iconified as a native Windows Application.
- Make Proform deal with Windows printer selection and I/O.
This is based on our perception that this task could be more involved than the original creation of Proform itself. This is a sad commentary on Microsoft API calls. So, there is some back-burner work going on to make that happen.
If you pay attention to using printer resident fonts like Univers it should work ok.
The normal behavior is that field references not found are left as is. This is done since the [] can appear in legitimate Postscript which has nothing to do with our fillins and should be left alone. You are expected to provide blank values for fields you want blank, eg:
addr3,
addr4,
Now, for people too lazy to do that AND who won't be affected by the postscript issue there is a -s option to change Proform's default behavior. Specify
proform template.name -s
and it will eat any [] fields for which it has no values.
Something is amiss. Perhaps we are executing a different copy of Proform within your application? A PATH issue? Try this from the command line:
# type proform
proform is /usr/local/bin/proform
# proform dog
Could not open template file dog; errno 2
Above is normal output. Either we are validated properly, or not. Then try the same two commands from within your Progress Application.
Proform expects a validation file to exist in the directory from which it was loaded, and that file has to be readable by it. (meaning the user)
Assuming the validation was run as user "root" did root have some funky umask which left the file unreadable by anyone else?
The other possibility is did you copy Proform somewhere else?
Which is PCL style graphics glop for data.
and /CMBarMag 1.0 def~/CMSpcMag when !BARSET! 0 3 0 is used.
Which is Postscript style glop for graphics data.
My recollections of fighting with postscript barcode generation was that depending on how you formatted the field you might end up with a situation wherein your [field-name] was actually being printed out by being a literal argument in some demented Postscript macro, conceptually like this:
200 1000 printme("[mybarcode]")
so that our attempt to replace that with postscript code was unsuccessful since it resulted in printing the literal value of the postscript code we generated. The resolution involved going into the actual postscript file and tweaking that field reference, which is totally dependent on the driver used.
You could make your life much simpler and quicker using PCL.
I believe I scored that off of HP's WWW page. (I know that doesn't narrow it down much.)
For the most demanding forms, folks are using ECpage if they are cheap and Jetform Design if they are not.
The demo should include .wpf (word perfect) files for all the samples. Look in the subdirectories like hp4.
I suggest that you take a look at the Proform Diagnostic page on our WWW site below, download the hex file viewer, and do some experimentation with your file.
We suspect that the bottom line will be that while other packages create
templates which print fields like this:
glopity-glopety [my-field] glopity-glopety [my-field]
the version AND FONTS you are picking create templates which look like
glopity-glopety [ glopity-glopety m glopity-glopety y
In other words, the word processor is deciding to position each and every character. This might be the font, this might be KERNING options which are different from the printer standard. You might be able to either fiddle with it and get it to fly, or even contact Microsoft and talk to someone that understands printer drivers.
-1: Bar Type is not between 1 and 15 -2: Length of the string is zero, or greater than 30 -3: Length of the text is zero, or greater than 30 -4: Printnum is greater than the number of printer types -5: Offset is greater than 250 -6: Height is greater than 20 (2 inches) or less than 1 -7: Checksum is not 0 thru 2 -8: Number of overstrike passes is not between 1 and 6 -9: Incorrect qty or type of chars for that bar code type
This might be too simple. How about
1st run "proform foo.hpl > /tmp/tempfile"
2nd run "proform -l fum.hpl >> /tmp/tempfile"
then "cat /tmp/tempfile | lp"
You may want to deal with temp file names, may them unique, whatever.
Philosophically, Proform is for problems where the graphical elements of the form are fixed, and the textual elements (the data) varies.
The PO has a "notes" field that can have anywhere between 0 and 18 lines, I don't want for my form to advance 18 lines (for the worse case) if there are only 4 lines or so to print. The form would waste a lot of empty space. The same situation could potentially happen with the PO detail records, because, they too have a notes field similar to the PO header note field.So, It looks like: PO Header Item one Description Description Description Item Two Description Description Item Three Description And you might have 18 lines of description for an Item? Do you know any way that I can suppress the potentially blank lines, maybe something I could pass into the variables that says, in effect, "don't line feed"?
There is no concept of "line feed" in a PCL form. All fields have a vertical and horizontal cursor position. Before every field there is a "move-to" command specifying position.
Without this ability I see no other way of printing the detail of my report other than sending completely formatted entire lines. For example: (All Header stuff) [1-detail] [2-detail] [3-detail] ... [55-detail] (All footer stuff)
You need to state what you need to accomplish. One simple approach is to use the Letterhead option, set the font to 16.6 Letter Gothic, and use your existing PO code. The salient question is how many different fonts you want to use. Proportional fonts look nicer, but then you will get bit on justification of numbers.
Also, the PO can consist of multiple pages. Do I have to layout all potential pages, including a redefinition of my form header based on the maximum size PO my software may encounter? Can I reference the same field arguments within the same document?
Uhhh, You can readily have a Beginning page format, a body format, and a trailer page format, and instruct Proform to switch templates with the "!FILE!" directive. All your Progress app would need to know is how many line item fields are on each template. Again, we expect the graphics, lines, boxes, cursor positions to be constant. Now, if you were really ambitious you could elect to doctor your form template to force the vertical cursor positions to be [] fields and make Proform change them. Of course at that point I debate how much value Proform is providing you. You would have to keep track of pixel positions yourself.
Try: PROFORMPATH=/v/proform export PROFORMPATH before running it. The algorithm is: first try the name as is. if not found, slap $PROFORMPATH on the front and try that.
Try something like this: stty 9600 cs8 -parenb ixon clocal cread -opost 0<&1 Unless you do an stty and turn off opost, it don't matter what escape codes you send to the printer.
Correct, assuming it is embedded in your application and you do not provide documentation on Proform to your clients.
Presently we have a DOS .exe file, which seems to work ok on Win, Win95, and NT. It does require that you have printer networking setup to redirect LPT ports for dos.
Hmm. It would be a non-trivial rewrite to change the pixels per bar and store that on a per field basis.
HOWEVER. What you might consider doing is running separate invokations of Proform just to create the other barcode, and store that in a temporary file. Then use the !INCLUDE! to insert that temporary file containing the other barcode PCL into your output stream. See page 13 of the docs for details on that.
[Later note: this was implemented in 1.39.1.11]
The -S option makes it skip fields for which it has no replacement value. For instance, if there is a field named [price10] in the template, and you have not supplied a value, normally it would spit the field back out verbatim. With the -S it will suppress it.
It you elect to use the -S, beware that some Postscript files may actually use [something], so the -S might wonk that file.
Hmmm. Our laser is a Brother HL-4, which is essentially a LJIII, so your output.bi and your template.bi print elcrapo on my printer.
When I run the output.bi through pcldump, I see that you are defaulting to 600 DPI graphics for your logo.
00053 [1b]E -> Reset^M 00055 [1b]*t600R -> Raster graphics resolution: 600^M 0005c [1b]&u600D -> !BAD ESCAPE SEQUENCE!^M The barcode generation code is going to switch the printer to 150 or 300 DPI depending on your defaults. 0089c [1b]&f0S -> Push/pop cursor position: push^M 008a1 [1b]*t150R -> Raster graphics resolution: 150^M 008a8 [1b]*r1A -> Start raster graphics: current cursor position^M I have seen cases where this causes a logo on screen to be MUCH bigger than intended. The obvious remedy is to place a field after the barcodes, into which you stuff a command to reset the graphics back. Proform supports the following special characters: case 'e': /* Escape */ case 'f': /* Form Feed */ case 'n': /* Line Feed */ case 'r': /* Carriage Return */ case 't': /* Tab */ So the following Proform Input might do it: fixme,\e*t600R
Try running this simple script on your file: strings $* | grep '\[*\]' | pg You should see the fields, after a bunch of glop: dM]Lq$0 dM]Lq$ ++]q+ ]qr%!632 ]q+++ *p1438X[toname] *p2638XDATE: [date] *p3838XTERMS: [terms] *p1438X[toaddr1] *p1438X[toaddr2] *p2638XATTN: [attn] *p3838XPO #: [ponum] *p150X [q1] *p1050X[descr1] *p4050X[expr1] *p150X [q2] *p1050X[descr2] *p4050X[expr2] *p4050X[frt] *p4050X[tot] )s4101t3b1s24v1P[comment] We have noticed that Word tends to try and make some "helpful" suggestions regarding the translation of fonts from WP to Word. In importing our samples, it decides to make all the fonts CONDENSED SPACING. This results in it repositioning each character in a string, so the word INVOICE becomes: 070b9 I^M 070ba [1b]*p-2X -> Horizontal cursor position (dots): -2^M 070c0 N^M 070c1 [1b]*p-2X -> Horizontal cursor position (dots): -2^M 070c7 V^M 070c8 [1b]*p-2X -> Horizontal cursor position (dots): -2^M 070ce O^M 070cf [1b]*p-2X -> Horizontal cursor position (dots): -2^M 070d5 I^M 070d6 [1b]*p-2X -> Horizontal cursor position (dots): -2^M 070dc C^M 070dd [1b]*p-2X -> Horizontal cursor position (dots): -2^M 070e3 E^M 070e4 [1b]*p-2X -> Horizontal cursor position (dots): -2^M The solution is to block over the field markers in question, Click Format->Font->Character Spacing, Select Spacing: Normal, turn off kerning, then Apply it.
Starting with the "cardking.wpg" file as a sample, I loaded it into Paintshop Pro, and set the page setup to make the image .95" big. I printed it to disk using our HL-4 driver. When I dumped the file with pcldump, I saw this: 00000 [1b]E -> Reset 00002 [1b]&l0S -> Simplex/duplex print: simplex 00007 [1b]&l0L -> Perforation skip: disable 0000c [1b]*r0F -> Raster graphics presentation: orientaion 00011 [1b]&l0O -> Logical page orientation: portrait 00016 [1b]&l1H -> Paper source: upper tray 0001b [1b]&l2a -> Page size: Letter 00020 4d -> Line spacing: 4 00022 1e -> Top margin (lines): 1 00024 42F -> Text length (lines): 42 00027 [1b]*t300R -> Raster graphics resolution: 300 0002e [1b]&l1X -> Number of copies: 1 00033 [1b]&l0S -> Simplex/duplex print: simplex 00038 [1b]*b0M -> Set compression mode: unencoded 0003d [0d] 0003e [1b]*p1443Y -> Vertical cursor position (dots): 1443 00046 [1b]*p1056X -> Horizontal cursor position (dots): 1056 0004e [1b]*r1A -> Start raster graphics: current cursor position 00053 [1b]*b2M -> Set compression mode: TIFF 00058 [1b]*b8W -> Transfer raster data (bytes): 8 00065 [1b]*b8W -> Transfer raster data (bytes): 8 . . . 0231b [1b]*b12W -> Transfer raster data (bytes): 12 0232d [1b]*b10W -> Transfer raster data (bytes): 10 0233d [1b]*b10W -> Transfer raster data (bytes): 10 0234d [1b]*rB -> End raster graphics: 02351 [0c] 02352 [1b]E -> Reset I can see that I don't want any of the commands in bytes 0 through 26. I also don't want the cursor positioning in bytes 2e through 4d. And down at the end, I don't want the formfeed or the reset. So, I can use FM or Hexedit.exe on this file and replace those offending commands with the null 0x00 character: File: cardking.prn Byte: 4e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 20 00 00 00 00 00 00 00 1b 2a 74 33 30 30 52 00 00 ........*t300R.. 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 l1X.&l0S.*b0M... 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1b 2a ...............* 50 72 31 41 1b 2a 62 32 4d 1b 2a 62 38 57 ff 00 00 r1A.*b2M.*b8W... 60 7f e2 ff 00 c0 1b 2a 62 38 57 02 00 03 80 e2 00 ......*b8W...... 70 00 38 1b 2a 62 38 57 02 00 03 80 e2 00 00 38 1b .8.*b8W.......8. 80 2a 62 37 57 01 00 0c e1 00 00 06 1b 2a 62 37 57 *b7W........*b7W 90 01 00 30 e1 00 00 01 1b 2a 62 37 57 01 00 30 e1 ..0.....*b7W..0. a0 00 00 01 1b 2a 62 37 57 01 00 40 e0 00 00 c0 1b ....*b7W..@..... b0 2a 62 37 57 01 00 40 e0 00 00 c0 1b 2a 62 37 57 *b7W..@.....*b7W c0 01 00 40 e0 00 00 c0 1b 2a 62 37 57 01 01 80 e0 ..@.....*b7W.... d0 00 00 20 1b 2a 62 37 57 01 01 80 e0 00 00 20 1b .. .*b7W...... . e0 2a 62 37 57 01 01 80 e0 00 00 20 1b 2a 62 37 57 *b7W...... .*b7W f0 01 01 80 e0 00 00 20 1b 2a 62 37 57 01 01 80 e0 ...... .*b7W.... 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef ^f/pgdn=forward ^h/f1=hex ^x/f3=find hex ^u/f5=undo ^g/f7 =goto ^b/pgup=backward ^a/f2=ascii ^t/f4=find ascii ^p/f6=print ^d/f10=done File: cardking.prn Byte: 2354 00 64 93 6d 82 60 00 3f ff ff 1b 2a 62 31 32 57 01 d.m.`.?...*b12W. 10 01 c0 fa 00 05 03 ff f0 01 9f 80 1b 2a 62 31 32 ............*b12 20 57 01 01 c0 fa 00 05 03 ff f0 01 9f 80 1b 2a 62 W.............*b 30 31 30 57 f6 00 02 0f fd e0 f1 00 00 78 1b 2a 62 10W.........x.*b 40 31 30 57 f6 00 02 0f fd e0 f1 00 00 78 1b 2a 72 10W.........x.*r 50 42 00 00 00 B... 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef The resultant file can be used as an insert according to the notes on page 13 of our reference manual.