[
https://issues.apache.org/jira/browse/PDFBOX-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Hewson updated PDFBOX-1666:
--------------------------------
Component/s: (was: PDModel)
Writing
> Missing StemV font descriptor entry when embedding AFM fonts
> ------------------------------------------------------------
>
> Key: PDFBOX-1666
> URL: https://issues.apache.org/jira/browse/PDFBOX-1666
> Project: PDFBox
> Issue Type: Bug
> Components: Writing
> Affects Versions: 2.0.0
> Reporter: Max Gilead
> Labels: easyfix, patch
> Fix For: 2.0.0
>
> Attachments: AFMTest.java, AFM_Test-invalid.pdf, AFM_Test-valid.pdf,
> n022004l.afm, n022004l.pfb, sRGB_IEC61966-2-1_black_scaled.icc
>
>
> When embedding an AFM font the StemV field is missing in the PDF which
> renders it not PDF/A-1b compliant.
> As the StemV value is not included in AFM files it seems to be OK to simply
> set it to 0. A quick test in Firefox, Chrome, OSX Preview and Acrobat Reader
> indicates having StemV set to 0 does not impact font rendering in any obvious
> way. FOP computes StemV from other values stored in PFM files but the fields
> are optional so can't be relied upon [1] (hence results are often 0 anyway)
> and Word [2] and iOS [3] seem to use 0 by default.
> Verified in SVN trunk 1504502 (2013.07.18)
> [1] http://xmlgraphics.apache.org/fop/1.1/fonts.html
> [2] http://tracker.luatex.org/view.php?id=32
> [3]
> http://blog.nomzit.com/2010/08/18/annoying-bug-in-quartz-pdfcontext-font-handling/
> -- just a link to a iOS-originating PDF dissected, nothing to do with the
> bug the article is about
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
