[jira] [Commented] (FOP-2564) [PATCH] Ignore ICC profiles added by ImageIO loader

2016-01-13 Thread Matthias Reischenbacher (JIRA)

[ 
https://issues.apache.org/jira/browse/FOP-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15097002#comment-15097002
 ] 

Matthias Reischenbacher commented on FOP-2564:
--

Added a new version of the patch, which fixes s problem with Graphics2D output 
(e.g. SVG --> PDF). PDFGraphics2D.addRenderedImage re-creates a 
org.apache.xmlgraphics.image.loader.impl.ImageRendered instance, that can be 
handled by the ImageRenderedAdapter. This is not nice, because the image loader 
originally creates a org.apache.xmlgraphics.image.loader.impl.ImageRendered 
instance, which is then lost because 
ImageConverterBitmap2G2D.Graphics2DImagePainterImpl.paint() can only pass a 
java.awt.image.RenderedImage instance. This problem is also visible when 
PDFGraphics2D.addRenderedImage has to re-create the ImageInfo instance 
(ImageInfo info = new ImageInfo(null, "image/unknown")). In order to fix that, 
I wrap the org.apache.xmlgraphics.image.loader.impl.ImageRendered instance in a 
new class (ImageRenderedG2D) that implements the java.awt.image.RenderedImage 
interface and gives access to the original 
org.apache.xmlgraphics.image.loader.impl.ImageRendered instance.


> [PATCH] Ignore ICC profiles added by ImageIO loader
> ---
>
> Key: FOP-2564
> URL: https://issues.apache.org/jira/browse/FOP-2564
> Project: FOP
>  Issue Type: Bug
>  Components: image/png
>Reporter: Matthias Reischenbacher
> Attachments: fop-2564-commons.patch, fop-2564.patch
>
>
> When rendering PNG files for PDF output, ICC profiles are taken into account 
> which were added by the ImageIO loader. This causes an unexpected color 
> display (light, dull colors) and should be avoided.
> This bug only applies to image files that don't have an embedded ICC profile 
> and are loaded by ImageLoaderImageIO.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (FOP-2564) [PATCH] Ignore ICC profiles added by ImageIO loader

2016-01-13 Thread Matthias Reischenbacher (JIRA)

 [ 
https://issues.apache.org/jira/browse/FOP-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthias Reischenbacher updated FOP-2564:
-
Attachment: (was: fop-2564.patch)

> [PATCH] Ignore ICC profiles added by ImageIO loader
> ---
>
> Key: FOP-2564
> URL: https://issues.apache.org/jira/browse/FOP-2564
> Project: FOP
>  Issue Type: Bug
>  Components: image/png
>Reporter: Matthias Reischenbacher
> Attachments: fop-2564-commons.patch, fop-2564.patch
>
>
> When rendering PNG files for PDF output, ICC profiles are taken into account 
> which were added by the ImageIO loader. This causes an unexpected color 
> display (light, dull colors) and should be avoided.
> This bug only applies to image files that don't have an embedded ICC profile 
> and are loaded by ImageLoaderImageIO.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (FOP-2564) [PATCH] Ignore ICC profiles added by ImageIO loader

2016-01-13 Thread Matthias Reischenbacher (JIRA)

 [ 
https://issues.apache.org/jira/browse/FOP-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthias Reischenbacher updated FOP-2564:
-
Attachment: fop-2564.patch
fop-2564-commons.patch

> [PATCH] Ignore ICC profiles added by ImageIO loader
> ---
>
> Key: FOP-2564
> URL: https://issues.apache.org/jira/browse/FOP-2564
> Project: FOP
>  Issue Type: Bug
>  Components: image/png
>Reporter: Matthias Reischenbacher
> Attachments: fop-2564-commons.patch, fop-2564.patch
>
>
> When rendering PNG files for PDF output, ICC profiles are taken into account 
> which were added by the ImageIO loader. This causes an unexpected color 
> display (light, dull colors) and should be avoided.
> This bug only applies to image files that don't have an embedded ICC profile 
> and are loaded by ImageLoaderImageIO.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (FOP-2564) [PATCH] Ignore ICC profiles added by ImageIO loader

2016-01-13 Thread Matthias Reischenbacher (JIRA)

 [ 
https://issues.apache.org/jira/browse/FOP-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthias Reischenbacher updated FOP-2564:
-
Attachment: (was: fop-2564-commons.patch)

> [PATCH] Ignore ICC profiles added by ImageIO loader
> ---
>
> Key: FOP-2564
> URL: https://issues.apache.org/jira/browse/FOP-2564
> Project: FOP
>  Issue Type: Bug
>  Components: image/png
>Reporter: Matthias Reischenbacher
> Attachments: fop-2564-commons.patch, fop-2564.patch
>
>
> When rendering PNG files for PDF output, ICC profiles are taken into account 
> which were added by the ImageIO loader. This causes an unexpected color 
> display (light, dull colors) and should be avoided.
> This bug only applies to image files that don't have an embedded ICC profile 
> and are loaded by ImageLoaderImageIO.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


Re: Change bars status

2016-01-13 Thread Jan Tosovsky
Dear All,

On 2015-07-19 Jan Tosovsky wrote:
> On 2015-07-18 Stephan Thesing wrote:
> > I have a local patch without respecting writing direction that also
> > produces correct results for the example fo sent earlier in this
> > thread
> 
> I like your update as it doesn't touch FOUserAgent (change bars are
> stacked in PageSequence) and it doesn't pollute various area classes
> with that BiDi handling.
> 
> I've incorporated these changes into my clone. For LR writing direction
> it still passes all my tests.
> 
> I'll submit it together with further details to the original JIRA
> issue.

I commited these changes in July: 

https://issues.apache.org/jira/browse/FOP-1760

(together with layout tests and comments)

Would anybody mind reviewing it?

Thanks, Jan




Re: JavaIO Default ICC Profiles

2016-01-13 Thread Matthias Reischenbacher
Hi,

I just added two patches at
https://issues.apache.org/jira/browse/FOP-2564 which attempt to give
more control over ICC profile handling. On commons side I added the ICC
profile as a separate parameter to the ImageBuffered/ImageRendered
constructors. This causes quite some code changes in other classes, but
I think is nicer than just resetting the ICC profile after instantiation
of those objects.
On FOP side the change is much simpler: instead of always using the ICC
profile provided by the encoding helper (which is only necessary if the
color model actually changes), the ICC profile of the image is used
(just as in AbstractImageAdapter.getEffectiveICCProfile()).
With this new version of my fix, both image types (files with and
without ICC profiles) are correctly processed.

BR,
Matthias

On 13.01.2016 09:26, Luis Bernardo wrote:
>
> Yes, that is what I was suspecting. My suggestion then is to do the
> check when loading the image, as you propose. If there is no embedded
> profile in the PNG do not embed one by default. We could make this
> configurable but I don;t see the need for that until we find an
> example where having the default profile embedded helps.
>
>
> On Wed, Jan 13, 2016 at 1:19 PM, Matthias Reischenbacher
> mailto:matthias8...@gmx.at>> wrote:
>
> Hi,
>
> FOP-1575 seems to be similar, but isn't the same. I also can't
> reproduce
> it on my platform (win, jdk 8), so perhaps it has been fixed in the
> meantime by some other change.
>
> Regarding your other questions: getEffectiveICCProfile() is always
> called, regardless of embedded or non-embedded profiles. In fact I
> just
> tried with more sample PNG images (with and without embedded profiles)
> and my fix is definitely wrong, because embedded ICC profiles for Gray
> color space are also of type ICC_ProfileGray, so also embedded
> profiles
> are now being ignored by my change. I think my fix needs to be added
> more deep down, probably in the  image loader
> (ImageLoaderImageIO.loadImage). Perhaps it would be a good thing
> to mark
> the Image there as having or not an embedded profile, so that the
> ImageRendererAdapter can better decide, if the profiles should be
> used.
> I will create a jira issue and check in more detail.
>
> BR,
> Matthias
>
> On 12.01.2016 19:27, Luis Bernardo wrote:
> >
> > Can you check whether FOP-1575 is the same problem?
> >
> > Is getEffectiveICCProfile() only called if there is no embedded
> > profile? Could there be cases where that profile is in fact correct?
> >
> > On 1/12/16 9:25 PM, Matthias Reischenbacher wrote:
> >> Hi,
> >>
> >> I've been struggling today with the PDF display of a PNG with
> "gray"
> >> color space. When using the default PNG loader (with the raw
> PNG loader
> >> all works fine), the colors are displayed very "light" and "dull".
> >> During a debug session I found out that the ImageIO loader
> assigns a
> >> default Gray ICC profile (of type
> java.awt.color.ICC_ProfileGray), if
> >> the PNG file doesn't have an embedded ICC profile. So the
> >> ImageRenderedAdapter.getEffectiveICCProfile method returns this
> Java
> >> "ICC_ProfileGray" profile, which is then embedded in the output
> PDF.
> >> Displaying the PNG with this profile, causes the "incorrect" color
> >> display.
> >> I'm aware that an ICC profile should be embedded in the PNG
> file, in
> >> order to have full control over color reproduction, but I'm
> wondering if
> >> it doesn't go a bit too far to output a profile, which is
> internally
> >> assigned by the JRE. As a quick fix I locally changed the
> >> ImageRenderedAdapter.getEffectiveICCProfile method the
> following way:
> >>
> >> protected ICC_Profile getEffectiveICCProfile() {
> >>  ColorSpace cs = getImageColorSpace();
> >>  if (cs instanceof ICC_ColorSpace) {
> >>  ICC_ColorSpace iccSpace = (ICC_ColorSpace)cs;
> >>  return !(iccSpace.getProfile() instanceof
> ICC_ProfileGray) ?
> >> iccSpace.getProfile() : null;
> >>  } else {
> >>  return null;
> >>  }
> >> }
> >>
> >> Please let me know, if anybody disagrees with this approach or
> if it
> >> should be handled somewhere else.
> >>
> >> Thanks,
> >> Matthias
> >>
> >
>
>
>



[jira] [Updated] (FOP-2564) [PATCH] Ignore ICC profiles added by ImageIO loader

2016-01-13 Thread Matthias Reischenbacher (JIRA)

 [ 
https://issues.apache.org/jira/browse/FOP-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthias Reischenbacher updated FOP-2564:
-
Summary: [PATCH] Ignore ICC profiles added by ImageIO loader  (was: Ignore 
ICC profiles added by ImageIO loader)

> [PATCH] Ignore ICC profiles added by ImageIO loader
> ---
>
> Key: FOP-2564
> URL: https://issues.apache.org/jira/browse/FOP-2564
> Project: FOP
>  Issue Type: Bug
>  Components: image/png
>Reporter: Matthias Reischenbacher
> Attachments: fop-2564-commons.patch, fop-2564.patch
>
>
> When rendering PNG files for PDF output, ICC profiles are taken into account 
> which were added by the ImageIO loader. This causes an unexpected color 
> display (light, dull colors) and should be avoided.
> This bug only applies to image files that don't have an embedded ICC profile 
> and are loaded by ImageLoaderImageIO.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (FOP-2564) Ignore ICC profiles added by ImageIO loader

2016-01-13 Thread Matthias Reischenbacher (JIRA)

 [ 
https://issues.apache.org/jira/browse/FOP-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthias Reischenbacher updated FOP-2564:
-
Attachment: fop-2564-commons.patch

> Ignore ICC profiles added by ImageIO loader
> ---
>
> Key: FOP-2564
> URL: https://issues.apache.org/jira/browse/FOP-2564
> Project: FOP
>  Issue Type: Bug
>  Components: image/png
>Reporter: Matthias Reischenbacher
> Attachments: fop-2564-commons.patch, fop-2564.patch
>
>
> When rendering PNG files for PDF output, ICC profiles are taken into account 
> which were added by the ImageIO loader. This causes an unexpected color 
> display (light, dull colors) and should be avoided.
> This bug only applies to image files that don't have an embedded ICC profile 
> and are loaded by ImageLoaderImageIO.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (FOP-2564) Ignore ICC profiles added by ImageIO loader

2016-01-13 Thread Matthias Reischenbacher (JIRA)

 [ 
https://issues.apache.org/jira/browse/FOP-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthias Reischenbacher updated FOP-2564:
-
Attachment: fop-2564.patch

> Ignore ICC profiles added by ImageIO loader
> ---
>
> Key: FOP-2564
> URL: https://issues.apache.org/jira/browse/FOP-2564
> Project: FOP
>  Issue Type: Bug
>  Components: image/png
>Reporter: Matthias Reischenbacher
> Attachments: fop-2564-commons.patch, fop-2564.patch
>
>
> When rendering PNG files for PDF output, ICC profiles are taken into account 
> which were added by the ImageIO loader. This causes an unexpected color 
> display (light, dull colors) and should be avoided.
> This bug only applies to image files that don't have an embedded ICC profile 
> and are loaded by ImageLoaderImageIO.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (FOP-2564) Ignore ICC profiles added by ImageIO loader

2016-01-13 Thread Matthias Reischenbacher (JIRA)
Matthias Reischenbacher created FOP-2564:


 Summary: Ignore ICC profiles added by ImageIO loader
 Key: FOP-2564
 URL: https://issues.apache.org/jira/browse/FOP-2564
 Project: FOP
  Issue Type: Bug
  Components: image/png
Reporter: Matthias Reischenbacher


When rendering PNG files for PDF output, ICC profiles are taken into account 
which were added by the ImageIO loader. This causes an unexpected color display 
(light, dull colors) and should be avoided.
This bug only applies to image files that don't have an embedded ICC profile 
and are loaded by ImageLoaderImageIO.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


Re: JavaIO Default ICC Profiles

2016-01-13 Thread Luis Bernardo
Yes, that is what I was suspecting. My suggestion then is to do the check
when loading the image, as you propose. If there is no embedded profile in
the PNG do not embed one by default. We could make this configurable but I
don;t see the need for that until we find an example where having the
default profile embedded helps.


On Wed, Jan 13, 2016 at 1:19 PM, Matthias Reischenbacher <
matthias8...@gmx.at> wrote:

> Hi,
>
> FOP-1575 seems to be similar, but isn't the same. I also can't reproduce
> it on my platform (win, jdk 8), so perhaps it has been fixed in the
> meantime by some other change.
>
> Regarding your other questions: getEffectiveICCProfile() is always
> called, regardless of embedded or non-embedded profiles. In fact I just
> tried with more sample PNG images (with and without embedded profiles)
> and my fix is definitely wrong, because embedded ICC profiles for Gray
> color space are also of type ICC_ProfileGray, so also embedded profiles
> are now being ignored by my change. I think my fix needs to be added
> more deep down, probably in the  image loader
> (ImageLoaderImageIO.loadImage). Perhaps it would be a good thing to mark
> the Image there as having or not an embedded profile, so that the
> ImageRendererAdapter can better decide, if the profiles should be used.
> I will create a jira issue and check in more detail.
>
> BR,
> Matthias
>
> On 12.01.2016 19:27, Luis Bernardo wrote:
> >
> > Can you check whether FOP-1575 is the same problem?
> >
> > Is getEffectiveICCProfile() only called if there is no embedded
> > profile? Could there be cases where that profile is in fact correct?
> >
> > On 1/12/16 9:25 PM, Matthias Reischenbacher wrote:
> >> Hi,
> >>
> >> I've been struggling today with the PDF display of a PNG with "gray"
> >> color space. When using the default PNG loader (with the raw PNG loader
> >> all works fine), the colors are displayed very "light" and "dull".
> >> During a debug session I found out that the ImageIO loader assigns a
> >> default Gray ICC profile (of type java.awt.color.ICC_ProfileGray), if
> >> the PNG file doesn't have an embedded ICC profile. So the
> >> ImageRenderedAdapter.getEffectiveICCProfile method returns this Java
> >> "ICC_ProfileGray" profile, which is then embedded in the output PDF.
> >> Displaying the PNG with this profile, causes the "incorrect" color
> >> display.
> >> I'm aware that an ICC profile should be embedded in the PNG file, in
> >> order to have full control over color reproduction, but I'm wondering if
> >> it doesn't go a bit too far to output a profile, which is internally
> >> assigned by the JRE. As a quick fix I locally changed the
> >> ImageRenderedAdapter.getEffectiveICCProfile method the following way:
> >>
> >> protected ICC_Profile getEffectiveICCProfile() {
> >>  ColorSpace cs = getImageColorSpace();
> >>  if (cs instanceof ICC_ColorSpace) {
> >>  ICC_ColorSpace iccSpace = (ICC_ColorSpace)cs;
> >>  return !(iccSpace.getProfile() instanceof ICC_ProfileGray) ?
> >> iccSpace.getProfile() : null;
> >>  } else {
> >>  return null;
> >>  }
> >> }
> >>
> >> Please let me know, if anybody disagrees with this approach or if it
> >> should be handled somewhere else.
> >>
> >> Thanks,
> >> Matthias
> >>
> >
>
>
>


Re: JavaIO Default ICC Profiles

2016-01-13 Thread Matthias Reischenbacher
Hi,

FOP-1575 seems to be similar, but isn't the same. I also can't reproduce
it on my platform (win, jdk 8), so perhaps it has been fixed in the
meantime by some other change.

Regarding your other questions: getEffectiveICCProfile() is always
called, regardless of embedded or non-embedded profiles. In fact I just
tried with more sample PNG images (with and without embedded profiles)
and my fix is definitely wrong, because embedded ICC profiles for Gray
color space are also of type ICC_ProfileGray, so also embedded profiles
are now being ignored by my change. I think my fix needs to be added
more deep down, probably in the  image loader
(ImageLoaderImageIO.loadImage). Perhaps it would be a good thing to mark
the Image there as having or not an embedded profile, so that the
ImageRendererAdapter can better decide, if the profiles should be used.
I will create a jira issue and check in more detail.

BR,
Matthias

On 12.01.2016 19:27, Luis Bernardo wrote:
>
> Can you check whether FOP-1575 is the same problem?
>
> Is getEffectiveICCProfile() only called if there is no embedded
> profile? Could there be cases where that profile is in fact correct?
>
> On 1/12/16 9:25 PM, Matthias Reischenbacher wrote:
>> Hi,
>>
>> I've been struggling today with the PDF display of a PNG with "gray"
>> color space. When using the default PNG loader (with the raw PNG loader
>> all works fine), the colors are displayed very "light" and "dull".
>> During a debug session I found out that the ImageIO loader assigns a
>> default Gray ICC profile (of type java.awt.color.ICC_ProfileGray), if
>> the PNG file doesn't have an embedded ICC profile. So the
>> ImageRenderedAdapter.getEffectiveICCProfile method returns this Java
>> "ICC_ProfileGray" profile, which is then embedded in the output PDF.
>> Displaying the PNG with this profile, causes the "incorrect" color
>> display.
>> I'm aware that an ICC profile should be embedded in the PNG file, in
>> order to have full control over color reproduction, but I'm wondering if
>> it doesn't go a bit too far to output a profile, which is internally
>> assigned by the JRE. As a quick fix I locally changed the
>> ImageRenderedAdapter.getEffectiveICCProfile method the following way:
>>
>> protected ICC_Profile getEffectiveICCProfile() {
>>  ColorSpace cs = getImageColorSpace();
>>  if (cs instanceof ICC_ColorSpace) {
>>  ICC_ColorSpace iccSpace = (ICC_ColorSpace)cs;
>>  return !(iccSpace.getProfile() instanceof ICC_ProfileGray) ?
>> iccSpace.getProfile() : null;
>>  } else {
>>  return null;
>>  }
>> }
>>
>> Please let me know, if anybody disagrees with this approach or if it
>> should be handled somewhere else.
>>
>> Thanks,
>> Matthias
>>
>




[jira] [Comment Edited] (FOP-2563) FOP nightly builds do not seem to be available

2016-01-13 Thread simon steiner (JIRA)

[ 
https://issues.apache.org/jira/browse/FOP-2563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15095850#comment-15095850
 ] 

simon steiner edited comment on FOP-2563 at 1/13/16 9:09 AM:
-

https://ci.apache.org/projects/xmlgraphics/fop/snapshots/fop-20160112.jar
https://ci.apache.org/projects/xmlgraphics/fop/snapshots/fop-20160112-bin.zip
https://ci.apache.org/projects/xmlgraphics/fop/snapshots/fop-20160112-bin.tar.gz


was (Author: ssteiner1):
https://ci.apache.org/projects/xmlgraphics/fop/snapshots/fop-20160112.jar
https://ci.apache.org/projects/xmlgraphics/fop/snapshots/fop-20160112-bin.zip

> FOP nightly builds do not seem to be available
> --
>
> Key: FOP-2563
> URL: https://issues.apache.org/jira/browse/FOP-2563
> Project: FOP
>  Issue Type: Bug
>  Components: documentation
>Reporter: Ian Wienand
>Priority: Minor
>
> The page
> https://ci.apache.org/projects/xmlgraphics/fop/snapshots/
> suggests there should be nightly snapshots to download, but it seems there 
> aren't any.
> I can see builds being done at 
> https://ci.apache.org/builders/fop-trunk/
> but it's not clear how to download.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (FOP-2563) FOP nightly builds do not seem to be available

2016-01-13 Thread simon steiner (JIRA)

[ 
https://issues.apache.org/jira/browse/FOP-2563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15095850#comment-15095850
 ] 

simon steiner edited comment on FOP-2563 at 1/13/16 9:08 AM:
-

https://ci.apache.org/projects/xmlgraphics/fop/snapshots/fop-20160112.jar
https://ci.apache.org/projects/xmlgraphics/fop/snapshots/fop-20160112-bin.zip


was (Author: ssteiner1):
https://ci.apache.org/projects/xmlgraphics/fop/snapshots/fop-20160112.jar

> FOP nightly builds do not seem to be available
> --
>
> Key: FOP-2563
> URL: https://issues.apache.org/jira/browse/FOP-2563
> Project: FOP
>  Issue Type: Bug
>  Components: documentation
>Reporter: Ian Wienand
>Priority: Minor
>
> The page
> https://ci.apache.org/projects/xmlgraphics/fop/snapshots/
> suggests there should be nightly snapshots to download, but it seems there 
> aren't any.
> I can see builds being done at 
> https://ci.apache.org/builders/fop-trunk/
> but it's not clear how to download.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (FOP-2563) FOP nightly builds do not seem to be available

2016-01-13 Thread simon steiner (JIRA)

[ 
https://issues.apache.org/jira/browse/FOP-2563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15095850#comment-15095850
 ] 

simon steiner commented on FOP-2563:


https://ci.apache.org/projects/xmlgraphics/fop/snapshots/fop-20160112.jar

> FOP nightly builds do not seem to be available
> --
>
> Key: FOP-2563
> URL: https://issues.apache.org/jira/browse/FOP-2563
> Project: FOP
>  Issue Type: Bug
>  Components: documentation
>Reporter: Ian Wienand
>Priority: Minor
>
> The page
> https://ci.apache.org/projects/xmlgraphics/fop/snapshots/
> suggests there should be nightly snapshots to download, but it seems there 
> aren't any.
> I can see builds being done at 
> https://ci.apache.org/builders/fop-trunk/
> but it's not clear how to download.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


Re: Issue with margin-bottom="10px" for of:block inside a list item.

2016-01-13 Thread Chris Bowditch

Hi,

I suggest logging a JIRA ticket and attaching the XSL-FO File (not XSLT)

Thanks,

Chris

On 08/01/2016 21:10, bharat.attal...@hotmail.com wrote:

Below is the error message getting back.

Jan 08, 2016 2:54:09 PM org.apache.fop.fo.FOTreeBuilder fatalError
SEVERE: org.xml.sax.SAXParseException; systemId:
file:/Users/Attaluri/Documents/Projects/R&D/abc/fop-2.0/BOTTOM_TEST.xsl;
lineNumber: 25; columnNumber: 51; java.lang.NullPointerException
Jan 08, 2016 2:54:09 PM org.apache.fop.cli.Main startFOP
SEVERE: Exception
org.apache.fop.apps.FOPException: java.lang.NullPointerException
javax.xml.transform.TransformerException: java.lang.NullPointerException
at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:288)
at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:115)
at org.apache.fop.cli.Main.startFOP(Main.java:186)
at org.apache.fop.cli.Main.main(Main.java:217)
Caused by: javax.xml.transform.TransformerException:
java.lang.NullPointerException
at
org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2416)
at
org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.java:1374)
at
org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411)
at
org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(TransformerImpl.java:2281)
at
org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.java:1367)
at
org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:709)
at
org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:1284)
at
org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:1262)
at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:285)
... 3 more
Caused by: java.lang.NullPointerException
at
org.apache.fop.layoutmgr.list.ListItemLayoutManager.getCombinedKnuthElementsForListItem(ListItemLayoutManager.java:396)
at
org.apache.fop.layoutmgr.list.ListItemLayoutManager.getNextKnuthElements(ListItemLayoutManager.java:326)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:239)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextChildElements(BlockStackingLayoutManager.java:498)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:289)
at
org.apache.fop.layoutmgr.list.ListBlockLayoutManager.getNextKnuthElements(ListBlockLayoutManager.java:103)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:239)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextChildElements(BlockLayoutManager.java:141)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:289)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:113)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:105)
at
org.apache.fop.layoutmgr.FlowLayoutManager.getNextChildElements(FlowLayoutManager.java:223)
at
org.apache.fop.layoutmgr.FlowLayoutManager.addChildElements(FlowLayoutManager.java:147)
at
org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:116)
at
org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:69)
at
org.apache.fop.layoutmgr.PageBreaker.getNextKnuthElements(PageBreaker.java:252)
at
org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker.java:643)
at
org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:178)
at
org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:158)
at
org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:384)
at org.apache.fop.layoutmgr.PageBreaker.doLayout(PageBreaker.java:112)
at
org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:138)
at
org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:267)
at
org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:130)
at
org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:360)
at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:190)
at
org.apache.xml.serializer.ToXMLSAXHandler.endElement(ToXMLSAXHandler.java:261)
at
org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.java:1399)
at
org.apache.xalan.templates.ElemForEach.transformSelectedNodes(ElemForEach.java:423)
at org.apache.xalan.templates.ElemForEach.execute(ElemForEach.java:263)
at
org.apache.xalan.tran