don't think there is a device table.

The solution I know is based on P_POSTSCRIPT and uses ghostscript to generate the PDF file (it's avery old one).

But you can use a product like FreePDF, PDFCreator or so which works like a Standard Windows Printer together with P_MSWINX

I found on my download archives a "batchPdfPrinting.pdf" from CPWR titled:

Batch Printing to PDF Using GhostScript
Release Uniface 9.4.01 R112

perhaps from the frontline tips and tricks http://frontline.compuware.com/Resources/Prod_content/batchPdfPrinting.pdf

or someone from CPWR may tell us where we can get this doc from

Uli

Hello ,

I have tried in the past to implement some pdf print and i must to say that the only way is to find a pdf ocx and write a service

i use free bullzip ocx pdf and i have a service to control the print job...

if you want i can send you the service

regards

Hello Here is an update and a strange behavior of Uniface when using “Batch Printing to PDF Using GhostScript” document. First a big thanks to Ulrich-Merkel, the document helped a lot and is a perfect solution for what I tried to accomplish. My application has a lot of Batch Printing and in 90% of the cases there is no different between the PDF and the paper we printed before PDF. The last 10% have some strange issues which I think is related to the windows user but I have no idea what can make it behave like this. I’m hoping someone can help to solve this mystery. The setup: One machine. Two domain users. One folder containing program files ,asn files and ini files. The two domain users are also different Uniface users, but they have the same group membership so they have exactly the same permissions in Uniface. The mystery: The two users logs on to the same machine (one by one) using the same folder to start the application. They both have the same Uniface settings (shortcut) and using the same part of the program to print the same batch to PDF. User 1 is getting (file1, didn’t find a way of uploading it) and User 2 is getting (file2, didn’t find a way of uploading it). File 1 is what we like it to be. Also User 3 logged on to the machine and did the same thing user 1 and 2 did. User 3 got the same result as User 1 (the correct one). It’s no fluke or random thing. It is consistently doing the wrong thing for user 2 all the time. The only way I can make it appear as user 1 and 3 is to set the $ioprint to 255 or higher in the asn file. User 1 and 2 and 3 are all in different AD(windows) user groups, but they do have the same permissions on the machine where the test is performed.

Hi Knut, the ghostscript way is that uniface creates at first a postscript file which is later on transferred to a PDF using the gjostscript toolkit. Sometimes, the default settings for one link in this chain, is set differently for a user, causing at the end some strange output. I can remember in the very old days (of ASSCII nad ANSI and 7bit national character sets) one customer has changed the default characterset for his standard printer. So the uniface printout was fine for anybody in his company but him; the german Umlauts ended in Underscores, backslashes etc. Found similar things when the default pagesize differs: what fits on one page w/o problems caused strange loss of data for the other user. It's hard to investigate as I know from my times on the german uniface helpdesk: Perhaps checking the registy for these users if you find differences outside the uniface area? P.S. To upload files, enter the "downloads" area of uniface.info and use the "add new download" link. Thanks to Tim Blankers for addint this option

Hi Thanks for replying to my update. This is a second uppdate after several hours of testing. This time around I tested using only one user at the time. We have 3 machines available to us to test and 3 users. The users all use Norwegian language for all “Region and language settings” including the ”non-Unicode” . The test is performed by picking randomly one of the 3 users and logon randomly to one ofe the 3 machines. All machines have the same program installed. The program is started an 1 page is printed and the pdf is opened for display. What I found: In 2 out of 3 the PDF displayed everything as expected the first time the page was printed. If it didn’t you have 1 of 4 chance to get it ok by just hitting print a second time. Ther is no changing done bethwen the two prints, not moving away from the frame or loading different data. Just hitting print a second time can make the pdf look different. In most cases a second time didn’t make any deferens at all. in this cases if it apers wrong it dos not mather how many times you hit print it will not aper corect. In some rare cases a second print on a correct print, makes a incorrect print. Same thing her, not doing anything whit data or program just hitting print a second time and the pdf looks different. The error is always appearing in words whit the Norwegian specific letters æ,ø and å. It is not the gost script messing it up as the post script code for the sample word “Målerkode:” is appearing as: 327.401550 568.459903 moveto (M\\345lerkode:) show In the postscript file which is display it correct and as: 327.401550 518.853580 moveto (M) show 327.401550 511.908698 moveto (\\345) show 327.401550 504.963817 moveto (lerkode:) show When it is wrong. Is it the Device table P_X11 that is unstable? A trace using $ioprint=4095 dos not show any deferens when I compared a trace file from an incorrect display against a correct display. This is very sad that this is not working better fro us, as our customer really wants to use PDF and not having to print to paper.

Our test with P_POSTSCRIPT is best of P_X11. It's strange in the documentation provided by Compuware to use the driver P_X11. But the result is not good.. The width was truncated.