[
https://issues.apache.org/jira/browse/PDFBOX-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13871744#comment-13871744
]
John Hewson commented on PDFBOX-1645:
-------------------------------------
I've recently been working on CFF char string rendering for 2.0.0 (see
PDFBOX-1831) and there are currently substantial changes taking place. The
checks for operands and the like seem reasonable but the bounding box
computation is not necessarily desirable. There are two reasons for this:
1) Computing an accurate bounding box for a glyph is a computationally
*expensive* operation, it's really not something which should be done by
CharStringRenderer as part of normal glyph parsing. If there is a need for this
computation, then it should be implemented as a static utility function which
calculates the bounds of a GeneralPath. Likewise, the glyph bounding box entry
("B") in an AFM file is optional, so AFMFormatter is not obliged to compute
them, which would be expensive, and noticeably so for any font with thousands
of glyphs, which is entirely possible.
2) You probably don't want the glyph bounding box. When performing typesetting
the left side bearing and advance width of the glyph are of importance as is
the overall font height in pt, however the exact bounding box of the glyph is
not usually a relevant metric - where the ink goes on the page is not usually
of concern to the typesetting engine. I must ask, are you sure you need the
bounding box? What are you using it for? Would another metric be more
appropriate?
If it turns out you really need the bounding box, then lets add it as a utility
class based around a GeneralPath, as mentioned in (1). It may well be more
complex than it first seems, FreeType
has hundreds of lines devoted to this calculation, see
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/base/ftbbox.c?h=STABLE
> [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.5#6160)
