Version: Prince 10 rev 2

In our PDF, we use a font family consist of 6 styles, each with individual font file.

• light
• light italic
• normal
• bold
• italic
• bold italic

Currently, when embedding the fonts, PrinceXML will use the Preferred Family name with style appended.

However, the embedded name does not seems to capture the light family as part of the style, which means, there the light and normal style are using the same name but representing different font style. This is potentially making the font indistinguishable to our print vendor's post-process software, causing printing issue.

Is there a way to change PrinceXML's font embedding behavior to include the PostScript name instead?

Also, the font will be encoded in MacRomanEncoding or built-in or Identity-H. Depending on the usage of non-BMP characters and the --no-subset-fonts option.

It there a way to force a single encoding?

1. Screen Shot 2015-10-08 at 1.40.00 PM.png‎ 54.5 kB ‎
   Font Report
2. test.pdf‎ 158.5 kB

Edited 8 Oct 2015 by yiqiu

We will try using the PostScript name.

Regarding the encoding issue, what exactly is the problem? Which encoding do you prefer?

We would like to force it to a Identity-H encoding even when only BMP characters are used.

The main benefit of this is that the downstream workflow (which we do not have full control over) can assume a single encoding regardless of the content being rendered.

Okay that's slightly trickier, and will require a new option. We will investigate.

Hey mikeday,

We are also investigating alternate solutions. But I believe we are blocked until we hear back from you. Our printer vendors cannot process our files because the files do not have the fonts correctly encoded.

Let me know if there is anything Yiqiu or I can do to help this issue.

Thanks!

Amir -- Opower

Okay we have updated the latest builds (20151013) for CentOS to use the PostScript name for TrueType fonts.

There is also a new option called --force-identity-encoding which will ensure that all the fonts use the identity encoding. You can specify this on the command-line or by setting PDF.forceIdentityEncoding if you are using JavaScript.

Could you try this updated package and see if it helps with your printer issues?

Thank you! We will try it out.

Could you update the OS X build as well? Most of the dev machine are running OS X.

Our production boxes are CentOS based but we all develop on Mac. Would be able to give us a MacOS build really quick too?

Oops. I just saw Yiqiu also asked.

We tried the CentOS version and using PostScript Name seems to be working.

We still have a few questions regarding Identity encoding:

1. When encoding with Identity-H and subsetting the font, the 'glyf' table in the font are compacted and re-encoded. Is there a way to retain the original glyphId in the font when embedding? The downstream workflow are trying combine PDFs and replace the subset-ted font, but running into issues where individual PDFs having the same CID(and GID) mapping to different glyphs.

2. We are also adopting the PrinceControl model and how does --force-identity-encoding work in that case? Is it a per-process setting or a per-document setting to be encoded in getJobJSON?

Edited 13 Oct 2015 by yiqiu

You probably want to pass --no-subset-fonts as well, as there is no point subsetting the fonts if you are going to be combining and editing the PDF files later.

We will have a MacOS X build ready shortly, and will get back to you on the PrinceControl issue.

Edited 14 Oct 2015 by mikeday

We now have an updated build for MacOS X.

It seems that the new build for OS X is throwing following message whenever invoked.

 warning: disabled parallel downloads due to unsupported SSL backend

Is that a new behavior? We do not see that in other versions.

That is unexpected. What output do you get if you run "curl --version" on your system?

Edit: Never mind, it appears that recent versions of MacOS X use SecureTransport instead of OpenSSL. We will need to make adjustments for this.

Edited 15 Oct 2015 by mikeday

There is now an updated package (20151015) for MacOS X that fixes this issue.

Thanks mikeday, the updated package looks fine now.

Do you have further information available about how --force-identity-encoding works with the PrinceControl interface?

Since this is not supported by the JSON interface yet, the simplest way of specifying the option would be to run a snippet of JavaScript:

PDF.forceIdentityEncoding = true;

Unfortunately, injecting javascript might not be an option for us. Do you have plan to add it to the JSON interface? This will block us from taking the advantage of the speed up from the PrinceControl interface.

Is it possible to specify --force-identity-encoding when starting the prince process with --control?

I have updated the latest builds for CentOS so you can specify force-identity-encoding via the JSON interface, using this updated Java wrapper: prince-java-20151017.zip.

This should also fix the missing comma between JSON list items, please let me know if you notice any other issues.

(The MacOS X package has also been updated).