[jira] [Commented] (PDFBOX-1645) [PATCH] Improved the accuracy of the bounding box for each rendered CFF glyph

["John Hewson (JIRA)" <ji...@apache.org>]

    [ 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)