[
https://issues.apache.org/jira/browse/PDFBOX-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Meyer updated PDFBOX-1645:
---------------------------------
Attachment: patch-20131202.diff
It's been a while getting back to this issue for which I apologize as I got
distracted by other issues. I am now ready to retry getting these changes put
forward as the FOP team is eager to change over to using an official release
rather than a snapshot which we're currently using as its far from ideal. I am
attaching another patch which addresses the AFM issue flagged up by the
previous patch file.
I have also tried to address Maruan's suggestion. I think it's better to keep
the checks in and allow the font to continue to be processed rather than
crashing out as the resulting font in several cases I have seem to display
fine. What I have done instead however is to add a stage at which each operator
and it's arguments are validated. On my test pdf (containing about 20-30 otf
fonts) I was getting quite a few warnings (nearly 100) and so have set it to
INFO so these can be filtered by level if desired. An example of several of the
messages are the following:
02-Dec-2013 15:01:39 org.apache.fontbox.cff.CharStringRenderer checkArguments
INFO: Font has an unexpected number of parameters for operator 'rmoveto'.
Arguments size 0 did not match pattern '2 || 3'
02-Dec-2013 15:01:39 org.apache.fontbox.cff.CharStringRenderer checkArguments
INFO: Font has an unexpected number of parameters for operator 'vhcurveto'.
Arguments size 7 did not match pattern '% 4 || 1 + % 4'
02-Dec-2013 15:01:39 org.apache.fontbox.cff.CharStringRenderer checkArguments
If these prove to be problematic resulting in lots of messages being generated
then this can be removed. The pattern (as can be seen in the above message is
not really mean't for general consumption but is helpful when identifying why
something failed. For example, in the second message above the pattern states
that it should be a multiple of 4, or the same but with with an extra argument.
These patterns can be changed if you disagree with my abbreviation choices but
thought it was an easy way to write them and for them to be understood.
Let me know if you still have concerns, questions and would suggest changes and
I'll look into them ASAP. I'll look at updating the other patch which FOP
depends on shortly for this project.
> [PATCH] Improved the accuracy of the bounding box for each rendered CFF glyph
> -----------------------------------------------------------------------------
>
> Key: PDFBOX-1645
> URL: https://issues.apache.org/jira/browse/PDFBOX-1645
> Project: PDFBox
> Issue Type: Improvement
> Components: FontBox
> Affects Versions: 1.8.2
> Reporter: Robert Meyer
> Assignee: Andreas Lehmkühler
> Fix For: 2.0.0
>
> Attachments: characterl.png, charactert.png, patch-20131202.diff,
> patch.diff
>
>
> In a previous patch to the CharStringRenderer class, I resolved the rendering
> issues and added a method to retrieve the bounding box for a CFF glyph. This
> utilized the GeneralPath.getBounds() method to retrieve it's bounding box.
> Unfortunately it was found that the method uses the control points of the
> bezier curves instead of the actual lines and was not very accurate. I have
> therefore added several new methods to calculate the correct extents of the
> glyph so that now it matches that of the measurements found in tools like
> FontForge.
> As a side note, there are several checks which were originally added in my
> patch which were unfortunately removed relating to the number of arguments
> provided with an operator. I have one Adobe Font (Adobe Heiti Standard -
> CID-Keyed OTF) which has one or more glyphs which trip up on this and cause
> an Array index out of Bounds exception. Each glyph renders correctly even
> though this issue occurs and therefore would be grateful if these could be
> left in. I have re-added these checks back with the patch I am about to add.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
