AnsweredAssumed Answered

'Save Records as PDF' results in mis-tagged font weights

Question asked by justinc on Sep 29, 2016
Latest reply on Dec 6, 2016 by TSGal

Hey all; I ran across this issue recently where the PDF that is exported, via the script step "Save Records as PDF" or via the File-> Save records as PDF, generates a PDF file that internally has mis-tagged the fonts with the incorrect line weighting.  This line weighting is the "StemV" attribute.  It is possible to see these value by opening the PDF in the text viewer (I used Text Wrangler), and then search for "StemV".

 

In this particular document "StemV" only occurs twice.  In the incorrect PDF this is defined to be 222 or 277.

 

This same layout/records can be save to a PDF via the Print -> Save as PDF option in OS X.  That document shows these "StemV" values to be 0 and 0.

 

 

Product and version 14.06 and 15.02

OS and version  10.11.6

How to replicate  I was able to recreate this issue by creating a new DB file in 15.02; putting one text field on a layout (in whatever the default theme was); typing some text into the field including some in bold and plain weights; put layout-object text on the layout as well, in bold and plain font-weights; choose File -> Save/Send Records as -> PDF; open that PDF in Text Wrangler and search for "StemV"; it has a value of 222 for the field text.  All fonts were Arial.

 

When exporting this same layout/record via Print-> Save as PDF, the document has StemV = 0.

 

Workaround  none so far

 

Now, I have to say that the PDF itself renders correctly - everything looks fine using Preview on OS X at least.  The fonts are correctly plain or bold.  The problem comes up when we try to convert this PDF to another format (e.g. DocX) via a service (easyPDFCloud).  The resulting DOCX output has all of the text in bold face because of this StemV value.  The version of the document with StemV=0 in it converts correctly, and the fonts correctly convert as either bold or plain.

Outcomes