buildbot failure in ASF Buildbot on fop-trunk

2015-08-07 Thread buildbot
The Buildbot has detected a new failure on builder fop-trunk while building ASF 
Buildbot. Full details are available at:
http://ci.apache.org/builders/fop-trunk/builds/30

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: orcus_ubuntu

Build Reason: The Nightly scheduler named 'fopNightly' triggered this build
Build Source Stamp: [branch xmlgraphics/fop/trunk] HEAD
Blamelist: 

BUILD FAILED: failed

Sincerely,
 -The Buildbot





Re: SingleByteFont Patch

2015-08-07 Thread Matthias Reischenbacher
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 / 100f,
 -(bbox.y + bbox.height) / 100f,
  bbox.width / 100f, bbox.height / 100f);
  }
  }
 
 
  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)