Hi Robert, interesting, thanks for the insight! I'll do a bit more local testing and commit a fix. If I interpret the code correctly, the bounding boxes are only set when the FontCache is filled, so the performance impact wouldn't matter too much I suppose. I'll leave a TODO mark in the code, in case anybody wants to continue to improve this.
Best regards, Matthias On 06.08.2015 11:54, Robert Meyer wrote: > Hi, > > I have had dealings with this when I was implementing open-type font > support as that and Type-1 fonts share similar CharString data. > Initially I thought the bounding box was a necessary part of getting the > font to work and as such put forward two patches to FontBox. The first > fixed their CharStringRenderer which renders each character and returns > the width: > > https://issues.apache.org/jira/browse/PDFBOX-1505 > > Once that was approved, I put forward a second patch which calculated an > accurate bounding box for the given character using the same renderer: > > https://issues.apache.org/jira/browse/PDFBOX-1645 > > Unfortunately doing this takes a fair amount of processing power and > after reading some of their concerns, while also realising that in the > end I didn't need the bounding box, I gave up on my attempt and the > issue was closed. From my testing it was certainly possible to get very > accurate bounding boxes for Type 1 font missing metrics. Whether it > would be worth the effort implementing this is doubtful though > considering firstly the fact that we lack much of the infrastructure to > implement this, but more importantly having a detrimental impact upon > performance for these limited cases. > > If Jeremias's approximation is anywhere near accurate I'd certainly > suggest giving that a go. > > Robert > >> Date: Thu, 6 Aug 2015 09:42:12 -0300 >> From: [email protected] >> To: [email protected] >> Subject: Re: SingleByteFont Patch >> >> Hi Team, >> >> the same issue described below, came up today on my side. I did a debug >> session and what I have found out so far is, that this only happens for >> Type1 fonts, that don't have a AFM file. The PFM file doesn't contain >> the char metrics so the bounding boxes can't be initialized. >> When transcoding SVGs to PDF, the code seems to rely on those bounding >> boxes (see FOPGVTGlyphVector), so I'm wondering what a correct fix would >> be. The PFMFile class contains a getFontBBox method, which, as its >> JavaDoc says, returns an approximation of the bounding box. I guess >> returning the approximation is better than nothing, so what I've come up >> so far code-wise is: >> >> returnFont.setLastChar(pfm.getLastChar()); >> for (short i = pfm.getFirstChar(); i <= pfm.getLastChar(); i++) { >> int cw = pfm.getCharWidth(i); >> singleFont.setWidth(i, cw); >> // start of my code change >> int[] bbox = pfm.getFontBBox(); >> singleFont.setBoundingBox(i, new Rectangle(bbox[0], bbox[1], cw, >> bbox[3])); >> // end of my code change >> } >> >> Basically I'm using the approximation plus the current char width to >> build a rectangle. >> >> Any thoughts? Or ideas for a better fix? >> >> Thanks & Best regards, >> Matthias >> >> On 01.07.2014 08:43, Pascal Sancho wrote: >> > Hi, >> > can you file in entries in Jira, please? >> > see our HowTo [1] submitting patches. >> > >> > [1] http://xmlgraphics.apache.org/fop/dev/#patches >> > >> > 2014-07-01 12:36 GMT+02:00 Kai Hofmann <[email protected]>: >> >> >> >> Dear all, >> >> >> >> looks like there is another bug based on the before mentioned problem: >> >> >> >> FOPGVTGlyphVector: >> >> >> >> private void buildBoundingBoxes() { >> >> boundingBoxes = new Rectangle2D[glyphs.length]; >> >> for (int i = 0; i < glyphs.length; i++) { >> >> Rectangle bbox = fontMetrics.getBoundingBox(glyphs[i], fontSize); >> >> boundingBoxes[i] = new Rectangle2D.Float(bbox.x / 1000000f, > -(bbox.y + bbox.height) / 1000000f, >> >> bbox.width / 1000000f, bbox.height / 1000000f); >> >> } >> >> } >> >> >> >> >> >> Here the result of the patched getBoundingBox seems to be used > without a null pointer check. Please keep attention on getBoundingBox > which explizitly returns null !!!! >> >> Looks like it would help to have complete javadocs which describe > the possible return values to avoid such mistakes. >> >> >> >> >> >> Gesendet: Dienstag, 01. Juli 2014 um 10:52 Uhr >> >> Von: "Kai Hofmann" <[email protected]> >> >> An: [email protected] >> >> Betreff: SingleByteFont Patch >> >> Dear all, >> >> >> >> I found a small bug in SingleByteFont - please see attached patch - > in getBoundingBox: >> >> >> >> if (idx >= 0 && idx < boundingBoxes.length) >> >> >> >> might result in a null pointer exception, when getBoundingBox is > called before setBoudning box. >> >> So repleace with: >> >> >> >> if (boundingBoxes != null && idx >= 0 && idx < boundingBoxes.length) >> > >> >
