[
https://issues.apache.org/jira/browse/PDFBOX-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Meyer updated PDFBOX-1645:
---------------------------------
Attachment: charactert.png
characterl.png
Hi,
Apologies for not responding to your points sooner as unfortunately I've been a
bit busy.
Andreas, to try and show you an example of how the calculation of the bounding
boxes has been improved, I have attached two images of glyphs from FontForge.
The first character is a lowercase L using a rather flamboyant font with lots
of curves. The GeneralPath.getBounds() with glyphs utilizing bezier curves
simply returns the location of the control points rather than the bounds of the
line itself. This results in incorrect minimum / maximum values being returned.
If you look at the characterl.png, the GeneralPath method gives the maximum X
as 938, whereas in actual fact it is closer to 760-70. The same can be said for
the maximum Y value.
GeneralPath.getBounds() = [-544, -29, 938, 1141]
New Method = [-544, -7, 767, 1040]
The second character is an uppercase T where this issue can be seen again.
Looking at the charactert.png image, you can see the minimum X should be close
to 0, whereas what's being returned is close to -200 (cause by control points
again). The improved method again provides a much more accurate measurement of
-13.
GeneralPath.getBounds() = [-196, -247, 1493, 1167]
New Method = [-13, -232, 1493, 1110]
It does make me wonder why they bothered to provide this
GeneralPath.getBounds() method if they weren't going to provide the actual
drawn bounds rather than just the curve guide boundaries. I don't have a PDF
example unfortunately as the accuracy of the bounding box information is
requested directly as part of adding OTF CFF support to FOP. I've kept the
existing getBounds() method, but renamed it now to getBounds2D() which the
AFMFormatter now uses (and now compiles!).
As a side note, is checkstyle being used? I've pulled the latest code but I am
getting hundreds of checkstyle issues. No problem if it's not, but thought I'd
ask.
I'll post a second patch once I have investigated Mauran's suggestions.
> [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
> Fix For: 2.0.0
>
> Attachments: characterl.png, charactert.png, 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
