Re: Another footnote rendering issue

[Pascal Sancho]

Hi,

can you attach test case in a Jira issue. I didn't try to look if
existing issues are concerned or not by your test case. If not, can
you file in a new issue, please?

2014-08-05 22:14 GMT+02:00 Alexey Neyman :
> Hi FOP developers,
>
>
>
> We've noticed yet another issue with the rendering of the footnotes where
> the footnote is rendered over the regular content. Verified with
> top-of-trunk FOP, r1615966. Please refer to the attached FO/PDF files.
>
>
>
> Curiously, if the last fo:list-item is commented out, the preceding
> fo:list-items are placed more tightly and as a result, the footnotes do not
> overlap with the regular content. This suggests that there's a bug in how
> the space between blocks is calculated, but I haven't debugged it further
> yet.
>
>
>
> Any off-hand ideas what may be causing this?
>
>
>
> Regards,
>
> Alexey.



-- 
pascal

Re: Table Border Anti Aliasing Issue

[Matthias Reischenbacher]

Hi,

On 05.08.2014 17:56, Luis Bernardo wrote:

On 8/5/14, 8:44 AM, Vincent Hennebert wrote:

On 04/08/14 23:30, Luis Bernardo wrote:


I looked at this in the past. I think I understand what you mean by
shapes and
solid lines but I don't think the issue is that. The problem, as I
understood
it, is caused by the fact we draw many segments now where before
there was
only one. So if you have a row with 5 cells the top and bottom sides
of the
row are drawn as 5 segments (one for each cell) where before (with
0.20.5)
there was just one segment spanning the 5 cells. The issue is really
with the
viewer, not with FOP, but it does make sense to come up with a
workaround.

So, if I were to tackle this, I think my first approach would be
something
similar to your suggestion 2. I would do it on the PDF renderer,
since this
only affects PDF (or we only care about that), and it would go like
this: when


The challenge will be to pass the information to the PDF renderer that
we are dealing with a table. Renderers don’t have that information, all
they know is that they are drawing a block with borders all around.

Re-constructing that information is likely to be hard, messy and
error-prone. Best would probably be to handle that in TableLM where all
the information still is available.


Yes, I am aware that the renderer does not know about tables. But in
fact that knowledge is not even necessary. Just knowing the segments
would be enough and this would be done at page level, not table level
(which can in any case span more than one page). And the algorithm would
be a lot simpler than one might image, specially because the segments
are drawn in some "natural" order which would make the algorithm fast
too (something like this: is the next segment horizontal? yes; do we
have a segment with the same Y? yes; do the ends touch? yes; is the
thickness and color the same? yes; them merge them to make just one
segment; next segment...).

But if we want to do the same in PostScript then I agree that doing this
before we get to the renderer is better.


Thanks for all your suggestions, this is very helpful. I like the 
simplicity of your approach Luis, but I'll try to handle it in the LMs 
so that PostScripts benefits too and we have a greater control over 
which shapes get merged.

I'll report in the next view days as soon as I can start with this job.

One more thing: Is there a recommended way to evaluate the performance 
impact of my changes? I searched in the mailing lists and found only 
Jeremia's "FOP Benchmarks" ( 
http://www.jeremias-maerki.ch/download/fop/FOP%20Benchmarks.zip ). I'll 
give it a try, please let me know, if there is some other way.


Thanks,
Matthias


There you could have an object that holds a grid, with cells
contributing to it as they are processed. Then you would decide what is
the most common pattern (say, 1pt solid black), reset it on cells (so
that they only keep border information for non-standard borders), and
pass this object to renderers.

BTW, the PostScript renderer might well benefit from that too, as
I remember complaints in the past that the file size was growing too big
due to all the drawing commands generated solely for borders.



you get the commands to draw the sides of the cells do not draw them and
instead collect them. Once you you are done with the table, use an
algorithm
that analyzes the segments and outputs a set of lines (and their
positions)
that correspond to the sides of the rows and columns. Then draw those
lines,
that form a grid, in one go. The fact that you use shapes or lines
for that
should not make a difference.

On 8/4/14, 4:38 PM, Matthias Reischenbacher wrote:

Hi,

I've gotten the request from multiple of my clients to look into the
border
display issues caused by anti aliasing in PDF viewers. I'm aware that
printing the PDF documents generated by FOP is never the issue, but
when
viewing, there definitely is (I know that anti aliasing can be
disabled in
Adobe Acrobat, but I can't control my users environment). Since
viewing PDF
files on electric devices is getting more and more important, I
think it's
worth to have a new look on this issue. Digging around in the FOP
mailing
lists, I've discovered that PDF viewers don't like that table
borders are
rendered with shapes instead of lines. I'm aware that shapes are
used for
supporting all border styles of the xsl-fo spec. The thing is that
99% of my
clients use only solid lines, so it is important to improve the display
quality here. AFAIK there are two possible ways to achieve this:

1. Fallback to the old (0.20.5) table border rendering code, if only
solid
lines are used inside a table.

2. Algorithm for merging shapes if width, color and style match.

Are you aware of any other ways to improve this? I'll start to
investigate
both approaches in the next view days, so I can't say much about the
viability and expected dev time yet. Perhaps some of you has already
started
to do some work or research on this issue and wa

[jira] [Created] (FOP-2402) footnotes overlap regular content

[Alexey Neyman (JIRA)]

Alexey Neyman created FOP-2402:
--

 Summary: footnotes overlap regular content
 Key: FOP-2402
 URL: https://issues.apache.org/jira/browse/FOP-2402
 Project: Fop
  Issue Type: Bug
  Components: layout/block
Affects Versions: trunk
 Environment: Ubuntu 14.04, Java 1.7.0_55
Reporter: Alexey Neyman
 Attachments: bad.fo, bad.pdf

We've noticed yet another issue with the rendering of the footnotes where the 
footnote is rendered over the regular content. Verified with top-of-trunk FOP, 
r1615966. Please refer to the attached FO/PDF files.
 
Curiously, if the last fo:list-item is commented out, the preceding 
fo:list-items are placed more tightly and as a result, the footnotes do not 
overlap with the regular content. This suggests that there's a bug in how the 
space between blocks is calculated, but I haven't debugged it further yet.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (FOP-2402) footnotes overlap regular content

[Alexey Neyman (JIRA)]

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

Alexey Neyman updated FOP-2402:
---

Attachment: bad.pdf
bad.fo

Example FO/PDF files.

> footnotes overlap regular content
> -
>
> Key: FOP-2402
> URL: https://issues.apache.org/jira/browse/FOP-2402
> Project: Fop
>  Issue Type: Bug
>  Components: layout/block
>Affects Versions: trunk
> Environment: Ubuntu 14.04, Java 1.7.0_55
>Reporter: Alexey Neyman
> Attachments: bad.fo, bad.pdf
>
>
> We've noticed yet another issue with the rendering of the footnotes where the 
> footnote is rendered over the regular content. Verified with top-of-trunk 
> FOP, r1615966. Please refer to the attached FO/PDF files.
>  
> Curiously, if the last fo:list-item is commented out, the preceding 
> fo:list-items are placed more tightly and as a result, the footnotes do not 
> overlap with the regular content. This suggests that there's a bug in how the 
> space between blocks is calculated, but I haven't debugged it further yet.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: Another footnote rendering issue

[Alexey Neyman]

It looked similar to FOP-143 in the description (the test case also involves 
fo:footnote 
inside a fo:list-block) but that one is described as fixed in 2007. Don't know 
if it is a 
regression of the same issue.

Submitted a new issue: FOP-2402

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

Regards,
Alexey.

On Wednesday, August 06, 2014 11:01:20 AM Pascal Sancho wrote:
> Hi,
> 
> can you attach test case in a Jira issue. I didn't try to look if
> existing issues are concerned or not by your test case. If not, can
> you file in a new issue, please?
> 
> 2014-08-05 22:14 GMT+02:00 Alexey Neyman :
> > Hi FOP developers,
> > 
> > 
> > 
> > We've noticed yet another issue with the rendering of the footnotes where
> > the footnote is rendered over the regular content. Verified with
> > top-of-trunk FOP, r1615966. Please refer to the attached FO/PDF files.
> > 
> > 
> > 
> > Curiously, if the last fo:list-item is commented out, the preceding
> > fo:list-items are placed more tightly and as a result, the footnotes do
> > not
> > overlap with the regular content. This suggests that there's a bug in how
> > the space between blocks is calculated, but I haven't debugged it further
> > yet.
> > 
> > 
> > 
> > Any off-hand ideas what may be causing this?
> > 
> > 
> > 
> > Regards,
> > 
> > Alexey.

Re: Summary of findbugs exclusions

[Chris Bowditch]

Hi All,

Yes it is sensible to add FindBugs into the default target, but it 
should be done after the committers vote to accept the new FindBugs 
configuration. At the moment Findbugs is not yet accepted by everyone 
due to the sub-optimal configuration.


Glenn; thanks for doing the initial analysis of the exclusions. I'm 
happy with the approach you propose to improve the Findbugs 
configuration. it would be good if the other committers could review and 
give feedback also.


Thanks,

Chris

On 04/08/2014 23:00, Glenn Adams wrote:



On Mon, Aug 4, 2014 at 3:47 PM, Luis Bernardo > wrote:



I suggest also to make running findbugs part of the default ant
task so that we don't forget to do it!


Good suggestion.



On 8/4/14, 5:43 PM, Glenn Adams wrote:

I have performed a brief study of the current findbugs exclusions
file. At present there are 1094 exclusions covering 101 distinct
exclusions types. Of these types, half (~50) have 3 or fewer
exclusions.

I plan to start cleaning up these exclusions by first fixing all
types having 10 or fewer exclusions. This will leave
approximately 25 types of exclusions to handle in a second fix pass.

Eventually, I will identify in the exclusions file all exclusion
types that should not be permitted to be added, i.e., that must
be fixed. I expect that some exclusion types will remain, such as:

  * BC_UNCONFIRMED_CAST
  * EI_EXPOSE_REP
  * EI_EXPOSE_REP2
  * PZLA_PREFER_ZERO_LENGTH_ARRAYS
  * UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR

Those that remain (and added in the future) should be subject to
an explicit design choice, and not merely to silence a warning.

Once I sort this out, I will ask for a vote on enabling findbugs
in nightly builds.

Re: Summary of findbugs exclusions

[Glenn Adams]

Thanks for input. It might be best to wait a bit to review this, as I'm
making good progress and where we end up will look a bit different. Also
I'm evaluating use of the newest version findbugs-3.0.0, just released.

I'll post a follow on message when things settle into place.


On Wed, Aug 6, 2014 at 10:19 AM, Chris Bowditch 
wrote:

> Hi All,
>
> Yes it is sensible to add FindBugs into the default target, but it should
> be done after the committers vote to accept the new FindBugs configuration.
> At the moment Findbugs is not yet accepted by everyone due to the
> sub-optimal configuration.
>
> Glenn; thanks for doing the initial analysis of the exclusions. I'm happy
> with the approach you propose to improve the Findbugs configuration. it
> would be good if the other committers could review and give feedback also.
>
> Thanks,
>
> Chris
>
> On 04/08/2014 23:00, Glenn Adams wrote:
>
>>
>>
>> On Mon, Aug 4, 2014 at 3:47 PM, Luis Bernardo > > wrote:
>>
>>
>> I suggest also to make running findbugs part of the default ant
>> task so that we don't forget to do it!
>>
>>
>> Good suggestion.
>>
>>
>>
>> On 8/4/14, 5:43 PM, Glenn Adams wrote:
>>
>>> I have performed a brief study of the current findbugs exclusions
>>> file. At present there are 1094 exclusions covering 101 distinct
>>> exclusions types. Of these types, half (~50) have 3 or fewer
>>> exclusions.
>>>
>>> I plan to start cleaning up these exclusions by first fixing all
>>> types having 10 or fewer exclusions. This will leave
>>> approximately 25 types of exclusions to handle in a second fix pass.
>>>
>>> Eventually, I will identify in the exclusions file all exclusion
>>> types that should not be permitted to be added, i.e., that must
>>> be fixed. I expect that some exclusion types will remain, such as:
>>>
>>>   * BC_UNCONFIRMED_CAST
>>>   * EI_EXPOSE_REP
>>>   * EI_EXPOSE_REP2
>>>   * PZLA_PREFER_ZERO_LENGTH_ARRAYS
>>>   * UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR
>>>
>>>
>>> Those that remain (and added in the future) should be subject to
>>> an explicit design choice, and not merely to silence a warning.
>>>
>>> Once I sort this out, I will ask for a vote on enabling findbugs
>>> in nightly builds.
>>>
>>
>>
>>
>

[jira] [Created] (FOP-2403) FOP 1.1 throws a Null pointer exception when FOP 1.0 does not

[Mike G (JIRA)]

Mike G created FOP-2403:
---

 Summary: FOP 1.1 throws a Null pointer exception when FOP 1.0 does 
not
 Key: FOP-2403
 URL: https://issues.apache.org/jira/browse/FOP-2403
 Project: Fop
  Issue Type: Bug
  Components: renderer/pdf
Affects Versions: 1.1
 Environment: Ubuntu 12.04
Reporter: Mike G
 Attachments: fo.xml

When trying to render a FO file to a PDF, FOP 1.1 will crash with a null 
pointer exception, while FOP 1.0 does not.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (FOP-2403) FOP 1.1 throws a Null pointer exception when FOP 1.0 does not

[Mike G (JIRA)]

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

Mike G updated FOP-2403:


Attachment: fo.xml

The file that works generating a PDF in FOP 1.0 but not FOP 1.1

> FOP 1.1 throws a Null pointer exception when FOP 1.0 does not
> -
>
> Key: FOP-2403
> URL: https://issues.apache.org/jira/browse/FOP-2403
> Project: Fop
>  Issue Type: Bug
>  Components: renderer/pdf
>Affects Versions: 1.1
> Environment: Ubuntu 12.04
>Reporter: Mike G
> Attachments: fo.xml
>
>
> When trying to render a FO file to a PDF, FOP 1.1 will crash with a null 
> pointer exception, while FOP 1.0 does not.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (FOP-2403) FOP 1.1 throws a Null pointer exception when FOP 1.0 does not

[Mike G (JIRA)]

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

Mike G commented on FOP-2403:
-

Note the command used for FOP 1.0 is the same as what I used with FOP 1.1:
$ fop -r -d -r -fo /tmp/fo.xml  -pdf test.pdf

> FOP 1.1 throws a Null pointer exception when FOP 1.0 does not
> -
>
> Key: FOP-2403
> URL: https://issues.apache.org/jira/browse/FOP-2403
> Project: Fop
>  Issue Type: Bug
>  Components: renderer/pdf
>Affects Versions: 1.1
> Environment: Ubuntu 12.04
>Reporter: Mike G
> Attachments: fo.xml
>
>
> When trying to render a FO file to a PDF, FOP 1.1 will crash with a null 
> pointer exception, while FOP 1.0 does not.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[GUMP@vmgump]: Project xml-fop-test (in module xml-fop) failed

[FOP Gump Nightly Build]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project xml-fop-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 8 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- xml-fop-test :  XSL-FO (Formatting Objects) processor


Full details are available at:
http://vmgump.apache.org/gump/public/xml-fop/xml-fop-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on checkstyle exists, no need to add for property 
checkstyle.location.
 -INFO- Failed with reason build failed
 -INFO- Project Reports in: 
/srv/gump/public/workspace/xml-fop/build/test-reports



The following work was performed:
http://vmgump.apache.org/gump/public/xml-fop/xml-fop-test/gump_work/build_xml-fop_xml-fop-test.html
Work Name: build_xml-fop_xml-fop-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 3 mins 47 secs
Command Line: /usr/lib/jvm/java-7-oracle/bin/java -Djava.awt.headless=true 
-Dbuild.sysclasspath=only -Dant.build.clonevm=true 
-Xbootclasspath/p:/srv/gump/public/workspace/xml-xalan/build/xalan-unbundled.jar:/srv/gump/public/workspace/xml-xalan/build/serializer.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar
 org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml 
-Dcheckstyle.location=/srv/gump/public/workspace/checkstyle/target/checkstyle-5.8-SNAPSHOT.jar
 gump-test 
[Working Directory: /srv/gump/public/workspace/xml-fop]
CLASSPATH: 
/usr/lib/jvm/java-7-oracle/lib/tools.jar:/srv/gump/public/workspace/xml-fop/build/classes:/srv/gump/public/workspace/xml-fop/build/codegen-classes:/srv/gump/public/workspace/xml-fop/build/test-classes:/srv/gump/public/workspace/xml-fop/lib/build/asm-3.1.jar:/srv/gump/public/workspace/xml-fop/lib/build/mockito-core-1.8.5.jar:/srv/gump/public/workspace/xml-fop/lib/build/hamcrest.core-1.1.0.jar:/srv/gump/public/workspace/xml-fop/lib/build/objenesis-1.0.0.jar:/srv/gump/public/workspace/xml-fop/lib/build/qdox-1.12.jar:/srv/gump/public/workspace/xml-fop/lib/fontbox-1.8.5.jar:/srv/gump/public/workspace/checkstyle/target/checkstyle-5.8-SNAPSHOT.jar:/srv/gump/packages/antlr/antlr-3.1.3.jar:/srv/gump/public/workspace/apache-commons/beanutils/dist/commons-beanutils-20140807.jar:/srv/gump/public/workspace/apache-commons/cli/target/commons-cli-1.3-SNAPSHOT.jar:/srv/gump/public/workspace/commons-collections-3.x/target/commons-collections-3.3-SNAPSHOT.jar:/srv/gump/public/workspace/apach
 
e-commons/exec/target/commons-exec-1.3-SNAPSHOT.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-20140807.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-20140807.jar:/srv/gump/public/workspace/apache-commons/validator/dist/commons-validator-20140807.jar:/srv/gump/public/workspace/google-guava/guava/target/guava-19.0-SNAPSHOT.jar:/srv/gump/public/workspace/xml-fop/build/fop.jar:/srv/gump/public/workspace/xml-fop/build/fop-sandbox.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit4.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/re
 
solver.jar:/srv/gump/packages/apache-attic/avalon-framework-api-4.3.jar:/srv/gump/packages/apache-attic/avalon-framework-impl-4.3.jar:/srv/gump/public/workspace/apache-commons/io/target/commons-io-2.5-SNAPSHOT.jar:/srv/gump/public/workspace/jakarta-servletapi-5/jsr154/dist/lib/servlet-api.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/public/workspace/xml-batik/batik-20140807/batik-slideshow.jar:/srv/gump/public/workspace/xml-batik/batik-20140807/batik-svgpp.jar:/srv/gump/public/workspace/xml-batik/batik-20140807/lib/batik-anim.jar:/srv/gump/public/workspace/xml-batik/batik-20140807/lib/batik-awt-util.jar:/srv/gump/public/workspace/xml-batik/batik-20140807/lib/batik-bridge.jar:/srv/gump/public/workspace/xml-batik/batik-20140807/lib/batik-codec.jar:/srv/gump/public/workspace/xml-batik/batik-20140807/lib/batik-css.jar:/srv/gump/public/workspace/xml-batik/batik-20140807/lib/batik-dom.jar:/srv/gump/public/workspace/xml-batik/batik-20140807/lib/
 
batik-ext.jar:/srv/gump/public/workspace/xml-batik/batik-20140807/lib/batik-extension.j

[jira] [Commented] (FOP-2403) FOP 1.1 throws a Null pointer exception when FOP 1.0 does not

[Glenn Adams (JIRA)]

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

Glenn Adams commented on FOP-2403:
--

It never ceases to amaze me how bug reporters somehow believe that developers 
can read their minds or are looking over their shoulders. How about a console 
log of the exception stack? Duh.

> FOP 1.1 throws a Null pointer exception when FOP 1.0 does not
> -
>
> Key: FOP-2403
> URL: https://issues.apache.org/jira/browse/FOP-2403
> Project: Fop
>  Issue Type: Bug
>  Components: renderer/pdf
>Affects Versions: 1.1
> Environment: Ubuntu 12.04
>Reporter: Mike G
> Attachments: fo.xml
>
>
> When trying to render a FO file to a PDF, FOP 1.1 will crash with a null 
> pointer exception, while FOP 1.0 does not.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: [GUMP@vmgump]: Project xml-fop-test (in module xml-fop) failed

[Glenn Adams]

I'll fix this momentarily.


On Wed, Aug 6, 2014 at 6:57 PM, FOP Gump Nightly Build <
fop-dev@xmlgraphics.apache.org> wrote:

> To whom it may engage...
>
> This is an automated request, but not an unsolicited one. For
> more information please visit http://gump.apache.org/nagged.html,
> and/or contact the folk at gene...@gump.apache.org.
>
> Project xml-fop-test has an issue affecting its community integration.
> This issue affects 1 projects,
>  and has been outstanding for 8 runs.
> The current state of this project is 'Failed', with reason 'Build Failed'.
> For reference only, the following projects are affected by this:
> - xml-fop-test :  XSL-FO (Formatting Objects) processor
>
>
> Full details are available at:
> http://vmgump.apache.org/gump/public/xml-fop/xml-fop-test/index.html
>
> That said, some information snippets are provided here.
>
> The following annotations (debug/informational/warning/error messages)
> were provided:
>  -DEBUG- Dependency on checkstyle exists, no need to add for property
> checkstyle.location.
>  -INFO- Failed with reason build failed
>  -INFO- Project Reports in:
> /srv/gump/public/workspace/xml-fop/build/test-reports
>
>
>
> The following work was performed:
>
> http://vmgump.apache.org/gump/public/xml-fop/xml-fop-test/gump_work/build_xml-fop_xml-fop-test.html
> Work Name: build_xml-fop_xml-fop-test (Type: Build)
> Work ended in a state of : Failed
> Elapsed: 3 mins 47 secs
> Command Line: /usr/lib/jvm/java-7-oracle/bin/java -Djava.awt.headless=true
> -Dbuild.sysclasspath=only -Dant.build.clonevm=true
> -Xbootclasspath/p:/srv/gump/public/workspace/xml-xalan/build/xalan-unbundled.jar:/srv/gump/public/workspace/xml-xalan/build/serializer.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar
> org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml
> -Dcheckstyle.location=/srv/gump/public/workspace/checkstyle/target/checkstyle-5.8-SNAPSHOT.jar
> gump-test
> [Working Directory: /srv/gump/public/workspace/xml-fop]
> CLASSPATH:
> /usr/lib/jvm/java-7-oracle/lib/tools.jar:/srv/gump/public/workspace/xml-fop/build/classes:/srv/gump/public/workspace/xml-fop/build/codegen-classes:/srv/gump/public/workspace/xml-fop/build/test-classes:/srv/gump/public/workspace/xml-fop/lib/build/asm-3.1.jar:/srv/gump/public/workspace/xml-fop/lib/build/mockito-core-1.8.5.jar:/srv/gump/public/workspace/xml-fop/lib/build/hamcrest.core-1.1.0.jar:/srv/gump/public/workspace/xml-fop/lib/build/objenesis-1.0.0.jar:/srv/gump/public/workspace/xml-fop/lib/build/qdox-1.12.jar:/srv/gump/public/workspace/xml-fop/lib/fontbox-1.8.5.jar:/srv/gump/public/workspace/checkstyle/target/checkstyle-5.8-SNAPSHOT.jar:/srv/gump/packages/antlr/antlr-3.1.3.jar:/srv/gump/public/workspace/apache-commons/beanutils/dist/commons-beanutils-20140807.jar:/srv/gump/public/workspace/apache-commons/cli/target/commons-cli-1.3-SNAPSHOT.jar:/srv/gump/public/workspace/commons-collections-3.x/target/commons-collections-3.3-SNAPSHOT.jar:/srv/gump/public/workspace/apach
>
>  
> e-commons/exec/target/commons-exec-1.3-SNAPSHOT.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-20140807.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-20140807.jar:/srv/gump/public/workspace/apache-commons/validator/dist/commons-validator-20140807.jar:/srv/gump/public/workspace/google-guava/guava/target/guava-19.0-SNAPSHOT.jar:/srv/gump/public/workspace/xml-fop/build/fop.jar:/srv/gump/public/workspace/xml-fop/build/fop-sandbox.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit4.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/re
>
>  
> solver.jar:/srv/gump/packages/apache-attic/avalon-framework-api-4.3.jar:/srv/gump/packages/apache-attic/avalon-framework-impl-4.3.jar:/srv/gump/public/workspace/apache-commons/io/target/commons-io-2.5-SNAPSHOT.jar:/srv/gump/public/workspace/jakarta-servletapi-5/jsr154/dist/lib/servlet-api.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/public/workspace/xml-batik/batik-20140807/batik-slideshow.jar:/srv/gump/public/workspace/xml-batik/batik-20140807/batik-svgpp.jar:/srv/gump/public/workspace/xml-batik/batik-20140807/lib/batik-anim.jar:/srv/gump/public/workspace/xml-batik/batik-20140807/lib/batik-awt-util.jar:/srv/gump/public/workspace/xml-batik/batik-20140807/lib/batik-bridge.jar:/srv/gump/public/workspace/xml-batik/batik-20140807/lib/batik-codec.jar:/srv/gump/public/workspace/xml-batik/batik-20140807/lib/batik-css.jar:/srv/gump/public/wo

[jira] [Created] (FOP-2404) incomplete svg example in extensive.fo

[Christian Danzmann (JIRA)]

Christian Danzmann created FOP-2404:
---

 Summary: incomplete svg example in extensive.fo
 Key: FOP-2404
 URL: https://issues.apache.org/jira/browse/FOP-2404
 Project: Fop
  Issue Type: Bug
Affects Versions: trunk
Reporter: Christian Danzmann
Priority: Minor


I found that in the example file 
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/fo/basic/extensive.fo
 the svg example won't work properly, because some elements are missing style 
information and thus won't show, 'cause they are drawn with white ink on white 
paper.

See:


  
  
  
  Hello SVG!



The lines and text wouldn't show after i copied this to my example file. Please 
add style information in the example file, so that this will work when copy and 
pasted to another document.



--
This message was sent by Atlassian JIRA
(v6.2#6252)