You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by Kai Hofmann <po...@web.de> on 2014/07/01 10:52:42 UTC
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)
Greetings
Kai Hofmann
--
Kai Hofmann EMail: powerstat@web.de
Bremen/Germany
Re: SingleByteFont Patch
Posted by Matthias Reischenbacher <ma...@gmx.at>.
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: matthias8283@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 <po...@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" <po...@web.de>
>> >> An: fop-users@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)
>> >
>> >
RE: SingleByteFont Patch
Posted by Robert Meyer <rm...@hotmail.co.uk>.
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: matthias8283@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 <po...@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" <po...@web.de>
> >> An: fop-users@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)
> >
> >
Re: SingleByteFont Patch
Posted by Matthias Reischenbacher <ma...@gmx.at>.
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 <po...@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" <po...@web.de>
>> An: fop-users@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)
>
>
Re: SingleByteFont Patch
Posted by Pascal Sancho <ps...@gmail.com>.
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 <po...@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" <po...@web.de>
> An: fop-users@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)
--
pascal
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Aw: SingleByteFont Patch
Posted by Kai Hofmann <po...@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.
Greetings
Kai Hofmann
--
Kai Hofmann EMail: powerstat@web.de
Bremen/Germany
Gesendet: Dienstag, 01. Juli 2014 um 10:52 Uhr
Von: "Kai Hofmann" <po...@web.de>
An: fop-users@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)
Greetings
Kai Hofmann
--
Kai Hofmann EMail: powerstat@web.de
Bremen/Germany
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org