EOM News and Views Pdfwriter Options
Total Page:16
File Type:pdf, Size:1020Kb
newsletter PGCG EOM News and Views Pretty Good Consulting Group Issue 50, Winter 2019 Got a problem? We create solutions. PDFWriter options A recent discussion on pdf file size got us thinking about the properties available on the EOM PDFWriter printer. We have noted a few of these properties in previous newsletters, but now want to take a closer look at how some of these options impact pdf file size. The Advanced Settings section of the Physical printer OutputMgrPDFWriter has numerous properties that most of us ignore. Some of these properties can have a significant impact on the pdf file size. The good news is that the default Settings do a pretty good job of creating the smallest pdf file size. We start with a few reminders: when printing to the Output Manager PDF Printer you have to have the Print Attribute property Printer Driver set to as "Windows driver". This requires that any graphics on an output page (i.e. form, logo) must be sent on each page. Finally, by default the fonts used In the pdf file are not stored in the pdf file - if the pdf is viewed on a device that does not have that specific font then a substitute is used, sometimes with less than optimal viewing results. Most "Windows driver" electronic forms are Windows metafiles (.wmf, .emf) but we are starting to see a shift to using .jpg forms - .jpg (continued on page 2) Serif Affinity Publisher – Not a PagePlus replacement PDF options .............................. 1 The Spring 2017 Newsletter brought the ugly news that Serif PagePlus product, in fact the Serif products .......................... 1 whole suite of Serif products, were frozen. The hope was that the new "Affinity" line of products under development would provide a migration path. Regrettably, the beta version EOM .Net interface ........... 3 of Affinity Publisher does not support Serif PagePlus files. There are many requests for Quick Hits....................................... 5 this capability, but as yet no statement from Serif that it will be in any version of Affinity Publisher. Contact information ........ 5 The affinity Publisher beta is available for testing and it does have very good PDF support, as well as new publishing capabilities. The current recommendation is to use Serif PagePlus for existing forms, then maybe look at Microsoft Publisher or Word for new forms. PDFWriter options (continued from page 1) files are easier to work with, a more common graphical format, and can be created from other formats more readily than Windows metafiles. We have had multiple customers add explanation pages to the end of statement output, either in the form of instructions on how to read the statement, where to get additional information, or to satisfy Federal requirements of information in multiple languages (description in English, Spanish, Portuguese,. .). Please note that we cannot define the .jpg form in the Print Attribute "Command File" properties, but the DDA Position Graphic command makes .jpg (and other graphical formats) very easy to use. So let’®s run a few tests. We start with a text file of 1,000 pages where each page has 1,035 Characters per page followed by a formfeed. The total file size is 1,036,000 Bytes. Below is a table of various tests and the impact on the PDF file size: A few observations: - The default settings for the OutputMgrPDFWriter work pretty well with respect to pdf file size and .jpg forms. - Font embedding matters. If you are using the standard fonts then you do not need to embed. Use the "Partial font embedding" option. - The "Remove duplicated images" option is disappointing. It did not impact file size at all (or it is not working, or it works for other graphic file formats, or it is always "Yes" under the covers) Side note - the 716 KB .jpg form has in 18 different languages, so it was much easier to convert that form to .jpg file so that we did not have to embed the fonts nor rely on the different language fonts being present on the end user’s device. EOM News & Views Page [ 2 ] Issue 50, Winter 2019 [ 2 ] Using the .Net interface to submit files to EOM The EOM .Net interface allows programs and scripts to create custom alerts, create an EOM user log entry, submit a file to EOM for File Masking, submit a file to EOM for a Custom/Email/Print/Transfer job. This interface has more capability than the COM interface, but requires that the program or script support the .Net interface. One use of this interface was recently created in order to match the File Masking parameters available from the ClearPath host. Many EOM customers have File Masks and File Masking strategies based on parameters available from the ClearPath host. For example, File Masking fields Host RunID, Host Queue (a.k.a. DESTINATION from MCP ClearPath), Host BannerID, Host ProjectID, and many more can contain useful values available for File Masking. Files received from non-ClearPath systems do not allow for many of these File Masking fields, so the EOM guru typically segregates File Masks for ClearPath and non-ClearPath systems to mask on different File Masking fields. If you have a complicated and robust File Masking strategy for ClearPath files then it might be easier to simulate files originating on other platforms with the same File Masking values. One solution is to use the .Net interface and set the same File Masking fields as was done on the ClearPath. To make this option a little easier the SubmitFileToEOM program was created. This command line program works very much like UGiveItBack, but uses the .Net framework instead of COM and does not allow for data manipulation. The SubmitFileToEOM program logs into a text file and allows you to submit files from remote Windows systems. So you might have a script or .bat file that executes the SubmitFileToEOM program as follows: C:\MyScripts\SubmitFileToEOM.exe I1=c:\temp\bigfile2.txt RH=LocalHost HS=HOSTSYS HQ=HOSTQUEUE HR=RUNID HQL=QUALIFIER HFL=FILENAME HA=ACCOUNT HB=BANNER HP=PROJECT HU=USERID UT1=UT1 FT=ASCII EP=123 HFD=02/20/19 HFT=12:12 This solution might also be useful if you cannot pass File Mask-able parameters via the $DEPHDR$ syntax within the file. Simply set those desired values on the command line: C:\MyScripts\SubmitFileToEOM.exe I1=c:\temp\bigfile2.txt UT1=textvalue1 UT2=textvalue2 UT3=textvalue3 Three notes: 1) The file submitted to EOM via the SubmitFileToEOM program has to be accessible by the EOM service, meaning that the login used to run the EOM service must have privileges to the system, folder, and file. 2) The File Mask that identifies the SubmitFileToEOM submitted file references a File Group that controls the disposition of the submit- ted file. So, if you do not want the original submitted file removed, you must configure the File Group to NOT delete the file once all jobs have completed. 3) The program can be downloaded from the PGCG downloads page. (continued on next page) EOM News & Views Page [ 3 ] Issue 50, Winter 2019 [ 3 ] Using the .Net interface to submit files to EOM (continued) One EOM user has put the .Net interface into use in order to simulate parameters used from their MCP system from the Windows platform: A batch file, SubmitFile2EOM.bat has been created in the \Program Files\Unisys\Enterprise Output Manager\Tools\SubmitFile2EOM on each EOM server. The batch file contains this line: SubmitFileToEOM.exe /L LD=c:\SF2EOM_Logs I1=%1 RH=%EOMSERVER% HQ=%2 HB=%3 HP=%4 I1 will be equated to the first % parameter passed to the batch file and should contain the full location and filename, from the destination EOM server’s point of view, of the file to be printed. The RH parameter is the name of the destination EOM server. This parameter is set via an environment variable on the submitting PC and is used to ensure that submissions from the test environment always get routed to the “test” EOM server and submission from the production environment always get routed to the “production” EOM server. HQ (Host Queue) will be equated to second % parameter passed to the batch file and should contain the destination name on the EOM server (example: ECH123, ESPLIT, ECHWC23, etc…). HB (Host Banner) will be equated to the third % parameter passed to the batch file and should contain the equivalent of “FORMID” in Unisys WFL print statements. This is mostly used to pass the “Report Name” lookup table specification when using ESPLIT as the destination. Simple documentation is included in the README-SubmitFileToEOM.txt file: ***************************************************************************** * This program submits a file and parameters to EOM via the .Net interface. * * * * Information is passed via the command line, which looks like: * * * * SubmitFileToEOM.exe I1=InFile RH=EOM1 (ops) * * where * * * * I1 is the file name to submit to EOM * * RH is the IP address or resolved name of the EOM server * * HS is the EOM parameter HOSTSYSTEM * * HQ is the EOM parameter HOSTQUEUE * * HR is the EOM parameter RUNID * * HQL is the EOM parameter QUALIFIER * * HFL is the EOM parameter FILENAME * * HFD is the EOM parameter HostFileCreateDate * * HFT is the EOM parameter HostFileCreateTime * * HA is the EOM parameter ACCOUNT * * HB is the EOM parameter BANNER * * HP is the EOM parameter PROJECT * * HU is the EOM parameter USERID * * UTx is a value for the User Tag x (1->10) * * FT is the file type, either ASCII (default) or PassThru * * EP is the number of estimated pages (defaults to 0) * * * * LD is directory to place the logfile, default is exe directory * * * * options are: * * /w to single thread executions of this program * * /L to log the execution results in a text file * ***************************************************************************** EOM News & Views Page [ 4 ] Issue 50, Winter 2019 [ 4 ] Training is available If your team is looking for a brush up on features or want to know about the entire EOM product we can help.