Adobe pdf file size much larger in EO89

We're upgrading to EO89 from XE, and have noticed that the Adobe pdf files generated from EO89 are about twice the size that they were under XE. The result is that printing takes a lot longer, which I suspect will cause our users to be very unhappy.

Has anyone else run across this change, and if so, have you found any way around it?

Here's the .pdf research I've done thus far, using R014021 as a sample:
From XE .pdf file properties:
- PDF Producer: J.D. Edwards OneWorld (B7333)
- PDF Version: 1.3 (Acrobat 4.x)
- Fonts used:
- ArialMT
- Type: Type 1
- Encoding: Ansi
- Actual Font: ArialMT
- Actual Font Type: TrueType

From EO89 .pdf file properties:
- PDF Producer: Adobe PDF Library 5.0.2
- PDF Version: 1.4 (Acrobat 5.x)
- Fonts used:
- TimesNewRoman (Embedded Subset)
- Type: TrueType (CID)
- Encoding: Identity-H

The XE report I ran was 13 pages, with a file size of 158KB.
The EO89 report I ran was 11 pages, with a file size of 261KB.

I'm also wondering if the Unicode change for EO89 has something to do with this pdf "bloat".

Any thoughts or findings would be appreciated.

We had some problems with this. Unicode is definitely the root cause. GASS told me their developers wanted a font with a richer character set than the stock Arial font. It also would have been much too expensive to license the Microsoft fonts and distribute for all platforms. This is why they now tell you to download the Arial Unicode font package from sourceforge.net. You can maintain compatibility between your Windows, UNIX and AS/400 servers by doing so.

Our biggest issue was with Optio. The developers designed their forms to look for the old font (non-embedded TrueType). It took a few days to convince management that I couldn't help them and they needed to pressure Optio rather than PeopleSoft. In the end, all they needed was a patch from Optio in order to support the new Unicode fonts.

The developers actually fessed up and admitted to dropping the ball. They did not request to have their partners and customers informed of the changes ahead of time. So, you are pretty much stuck with the new (bigger) fonts. I can tell you that on a Citrix server limited to 256 colors, I notice a sharp decrease in on-screen legibility compared to the old Arial TTF's. Increasing to 64K colors on the TSE seems to resolve the issue, but you will get hit with much higher memory utilization on the TSE's if you do this.

Charles

EnterpriseOne 8.9 SP2_H1 - HP-UX 11i, Oracle 9.2.0.4, Windows Batch, App, TSE, JAS

OneWorld Xe Base SP20_B1 - HP-UX 11i, Oracle 8.1.7.3, Windwos Batch, App, TSE, JAS

Thanks for the heads up on Optio. What version are you using??

Charles,

Thank you very much for the great information!

We are using Optio eComIntegrate 7.7.4 on the HP-UX platform.

This question and problem explains the problem we are having as well. We are a software company that provides similiar functionality as Formscape and Optio. We have a java connector that parses JDE Tagged JDE PDF output, transforms it to our proprietary XML and then sends it into our server for formatting, distribution, etc. We bumped into this problem when a customer upgraded to EO8.10, the PDF version output by JDE is 1.4 with the same characteristics as outlined by the person who posted the original message. Previous to the upgrade, the PDF version was 1.3 and in the PDF (again, the same characteristics as outlined above), the value of the field looked something like this:

TD(RICARD LITRE)Tj

In PDF v1.4, the value of a field looks something like this (these are not the same fields):

TD <00330044004A004800030010>Tj

The value of the field is double byte in hexadecimal representation in ascii (no encoding applied), the problem is that this hex does not translate to UTF-8 characters. As it is an True Type (CID) font it has its own proprietary double byte encoding, in doing this you are able to have multiple representations of a single font, in other words, the double byte encoding (Identity-H in this case) does not correspond to UTF-8. In theory, there should be a “CMap” table, either embedded in the document or external that maps the field to its true Unicode hex values, however, we are not able to locate it in the PDF file and the external CMap seems to be missing the column that contains the Unicode hex value.

What we are looking to do is force JDE to ouput PDF 1.3 with the same font and properties as when it output PDF v1.3 or force JDE to use the Arial Unicode font with UTF-8 encoding (not Identity-H). Granted, the various glyphs will be lost in the data passed to our application, however we can simply reapply them in our tool.

Any ideas would be greatly appreciated.