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: matthias8...@gmx.at
>> To: fop-dev@xmlgraphics.apache.org
>> 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 <powers...@web.de>:
>> >>
>> >> 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" <powers...@web.de>
>> >> An: fop-us...@xmlgraphics.apache.org
>> >> 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)
>> >
>> >

Reply via email to