By Ed Boedecker
Subject: New PDF support
#20508 - 04/04/13 11:33 AM

1. After the PRTCLOSE is done, the '.pdf' file is completed\closed and ready for use.

2. A PLB runtime creates the '.pdf' file in EXCLUSIVE mode.

3. You should be able to use a technique where a second PLB program tries to OPEN the '.pdf' file in EXCLUSIVE mode. When the second PLB program can OPEN the '.pdf' file in EXCLUSIVE mode, then the PRTCLOSE in the first program is completed and the '.pdf' file has been closed.

4. There are several scenarios to consider as to when the PRTOPEN\PRTCLOSE operations create the '.pdf' file.

4a. PRTOPEN S$P,"pdf:","testa.pdf"

In this case, the 'testa.pdf' file is created when the PRTOPEN instruction is executed. The 'testa.pdf' file is written directly as PRTPAGE instructions are executed. The PRTCLOSE finalizes the PDF file requirements and closes the 'testa.pdf' when it is completed.

4b. PRTOPEN S$P,"pdf:","testb.pdf",SPOOLFILE="testb.spl"

In this case, the 'testb.SPL' is created when the PRTOPEN is executed. The PRTOPEN DOES NOT create the 'testb.PDF' file. As the PRTPAGE instructions are executed, the 'testb.spl' file has spool print control data written to create a print stream. When the PRTCLOSE is executed, the 'testb.pdf' file is created and written using the print stream as found in the 'testb.spl' spoolfile. Again, when the PRTCLOSE is finished, the 'testb.pdf' is closed and available.

4c. PRTOPEN S$P,"@pdf:","testc.pdf"

In this case, the 'testc.pdf' file is NOT created by the PRTOPEN because there is a Print Preview specified. As the PRTPAGE instructions are executed, there is a temporary\internal spoolfile that is created and written with the data for the print stream. When the PRTCLOSE is execute, the 'Print View' is presented as determined from the temporary print stream. Now, on the 'Print View' window you will find a new 'ToPDF' button. If the end-user clicks the 'ToPDF' button, the 'testc.pdf' file is created from the print stream. After the PRTCLOSE is finished, the 'testc.pdf' file is closed and available ONLY if the end-user clicked the 'ToPDF' button.

4d. PRTOPEN S$P,"@MyPrinter","MyPrintJob",PDFNAME="testd.pdf"

In this case, a 'Print Preview' window is presented with a 'Print' button and a 'ToPDF' button. Again, the 'testd.pdf' file is ONLY created and written when the 'ToPDF' button in the 'Print Preview' window is clicked. After the PRTCLOSE is finished, the 'testd.pdf' is close and available ONLY if the end-user clicked the 'ToPDF' button.

4e. PRTOPEN S$P,"MyPrinter","MyPrintJob", PDFNAME="teste.pdf"

In this case, the 'teste.pdf' file is NEVER created because it is NOT possible to generate both Printed output and PDF file output at the same time. In this case, the PRTOPEN opens a Windows Printer device and the generated output is printed. The PDFNAME is ignored.

By Ed Boedecker
Subject: New PDF support
#20612 - 04/04/13 01:21 AM

Can two or more PL/B programs be PDFing at the same time on the same system?
They will be PDFing to different files. i.e.
Prog1.PLS PRTOPEN S$P,"pdf:","test1.pdf"
Prog2.PLS PRTOPEN S$P,"pdf:","test2.pdf"
Prog3.PLS PRTOPEN S$P,"pdf:","test3.pdf"
etc.

1. The short answer to your question is Yes.

2. The long answer to your question is:

2a. The PDF support added to the Sunbelt runtimes DO NOT have any of the restricts imposed by PDFCreator or any other OS device based drivers. The Sunbelt PDF support DOES NOT rely on any external PDF drivers or programs to create the Sunbelt PDF files.

2b. The Sunbelt runtimes are creating a simple PDF file directly like another PLB file. Therefore, all file IO operations are simple OS Write operations directly to the PDF file.

2c. Now, if you were so inclined, you could even perform multiple PRTOPEN instructions for 2 or more different PFILE variables each using the 'pdf:' device at the same time in the same program. You could actually perform PRTPAGE operations for each PFILE while each of them are currently opened at the same time.

PF1    PFILE
PF2    PFILE
PF3    PFILE
.
    PRTOPEN  PF1, "pdf:", "test1.pdf"
    PRTOPEN  PF2, "pdf:", "test2.pdf"
    PRTOPEN  PF3, "pdf:", "test3.pdf"
.
    PRTPAGE  PF1;"Test1 first line"
    PRTPAGE  PF2;"Test2 first line"
    PRTPAGE  PF3;"Test3 first line"
.
    PRTCLOSE PF1
    PRTCLOSE PF2
    PRTCLOSE PF3

3. Also, since the PDF support is solely implemented by the Sunbelt runtimes IO subsystem, it is even possible to direct the output of a PDF directly to a Sunbelt Data Manager.

PF1    PFILE
.
    PRTOPEN  PF1, "pdf:", "test1.pdf|127.0.0.1"
.
    PRTPAGE  PF1;"Test1 first line for a PDF on a Data Manager server"
.
    PRTCLOSE PF1.

By Ed Boedecker
Subject: New PDF support
#20612 - 04/04/13 01:21 AM

a small issue drawing lines, changed the following code to more closely match previous output:

. *p=column1a:7025,*PENSIZE=10,*line=column1b:7025:
. *p=column1a:7575,*PENSIZE=10,*line=column1b:7575
*p=column1a:6950,*PENSIZE=10,*line=column1b:6950:
*p=column1a:7525,*PENSIZE=10,*line=column1b:7525

1. The Sunbelt PDF support has been implemented to generate a PDF file that gives the same printed output as a Windows Printer.

2. If you write a simple test for your line issue and actually print it. Then take the same simple test and generate a Sunbelt PDF output. Then print the Sunbelt PDF file to the same printer. Look at the two pages that have been generated and they should be the same. If you find a difference, then we will consider making a change to the Sunbelt PDF algorithms.

3. The Sunbelt PDF output algorithms are based on a 600dpi printer to get the best resolution when generating the PDF values for a printed output. Since there are many PDF device based applications, there is no way that we can try and generate the same PDF output for all of PDF writing software. Therefore, we are using the final destination (ie Windows Printer) output as our gauge for accuracy in our PDF algorithms.

Question - Compression is on by default? I ask because my test case produces a monthly PDF report that consistently 179 to 172kb in size testing using pdf: 5meg

1. Yes, the compression is turned on by default for the Sunbelt PDF output.

2. Are you including the same image in your PDF report multiple times?

If the answer is Yes, then consider this regarding images:

The Sunbelt PDF output is written to optimize the output of PICT images. However, if your are including the same PICT in the PDF output over and over, then ONLY CREATE the PICT one time. If the SAME PICT is used in the PDF output, then it is ONLY put into the PDF ONCE. However, if you are re-CREATEing the same picture before using it for the PDF output, then a newly created PICT object is always stored in the PDF output when used.

Conclusion:

1. We need to look at your monthly PDF report to determine why it is larger than you expect.

2. Can you send (email) your Sunbelt PDF file and your PDF995 file to Sunbelt Support? We will evaluate the issue and determine the cause and best approach toward a resolution.

3. The nice thing about having Sunbelt developed PDF writing algorithms, we can change them when and how we want to. This is good for you and it is good for us!

By Ed Boedecker
Subject: New PDF support
#206xx - 04/04/13 01:21 AM In response to an example that was e-mailed, Ed replied....

We need some more input from you to help figure out what is happening for your issue:

1. We do not have the FONT that your sample test is using. Therefore, we get an error when the PDF reader is loading your PDF file. Change your program as follows to allow your font to be embedded in the PDF file. Change your program as follows to embed fonts:

PRTOPEN PFile,"pdf:","pdfname.pdf", FLAGS=2

The FLAGS bit value 2 causes any fonts to be embedded in the PDF file.

2. At the same time, can you generate a Sunbelt Spool file for your sample program. This can allow us to see the actual PRTPAGE controls being applied\used as well as the order of the controls. You can do this by using the 'SPOOLFILE={splname}' option on the PRTOPEN. The following should generate everything that we need:

PRTOPEN PFile,"pdf:","pdfname.pdf", FLAGS=2, SPOOLFILE="filename.spl"

3. Please send the newly created PDF and SPL files to Sunbelt Support.

---

1. I am using a simple Adobe reader.

2. The problem is that the font named 'Lucida Sans Typewriter' is not installed on my system and the Adobe reader is giving a qualification error to tell me that things may not appear as expected because it can not find the font in the PDF.

3. By having you embed the font in the PDF, this saves me from having to find and install a 'Lucida Sans Typewriter' font on my system.

4. Bill and I have another PDF font naming issue and I want to make sure that your issue has nothing to do with the other issue. This is where the Sunbelt Spool file can come into play.

By Ed Boedecker
Subject: New PDF support
#20638 - 04/04/13 01:21 AM

1. After reviewing several programs provided to the Sunbelt Support during this week's marathon, we have seen where some users are specifying a PRTPAGE *FONT as follows:

. Not Recommended      PRTPAGE PFILE;*FONT="'>Courier New Bold'(14)"

Even though this font name string syntax works and seems to give desired results, this syntax format can cause issues in the runtimes where the PRTPAGE *BOLDON and *BOLDOFF controls do not work as expected for this font name syntax. The Sunbelt runtimes DO NOT evaluate the font names (ie 'Courier New Bold' ) as shown in this example. This name is passed directly to the OS to be used\processed. Therefore, the runtime DOES NOT know that this font is bold.

Now, to insure property operation for the PRTPAGE *FONT, *BOLDON, and *BOLDOFF controls, the following font name string syntax for *FONT should be used when creating a Bold font.

. Recommended      PRTPAGE PFILE;*FONT="'>Courier New'(14,Bold)"

In this last recommended font name syntax, the runtime is able to evaluate the font attributes specified as 14 and Bold and properly provide these attributes to the OS along with the font name identified as "Courier New" to be used\processed as expected. In this case, since the runtime KNOWS that the font has a Bold attribute, the *BOLDOFF and *BOLDON PRTPAGE controls can work as expected.

The font name syntax that I am referencing in this recommended case is described in the PL/B Language Reference Manual under the 'FONT properties' section.