from:"Alexios Giotis \(JIRA\)"

[jira] [Commented] (FOP-2968) ValidationException: fo:table-row is missing child elements

2020-09-09 Thread Alexios Giotis (Jira)



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

Alexios Giotis commented on FOP-2968:
-

This is still out of the scope of the FOP project and not a bug.The syntax and 
validity of XSL is defined by a W3C specification and not by the output of a 
library. 

 

Ask for alternative ways of achieving this. Other tools, maybe post-processing 
/ fixing the output etc. Starting from version 3.3.0 of doc4j, this feature 
became optional and is not well maintained.

> ValidationException: fo:table-row is missing child elements
> ---
>
> Key: FOP-2968
> URL: https://issues.apache.org/jira/browse/FOP-2968
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 2.5, 2.4
>Reporter: Ed Belov
>Priority: Critical
> Attachments: in3.docx, out3.fo
>
>
> Good day. 
> There is a problem with merging cells. All table cells contain joins. How can 
> I be in this case?
> An error occurs when generating pdf.
> SEVERE: Exception
> org.apache.fop.apps.FOPException: org.apache.fop.fo.ValidationException: 
> "fo:table-row" is missing child elements.
> red content model: (table-cell+) 
> Thank.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (FOP-2968) ValidationException: fo:table-row is missing child elements

2020-09-08 Thread Alexios Giotis (Jira)



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

Alexios Giotis commented on FOP-2968:
-

The FO input given to FOP is not valid, therefore have a look in the docX to FO 
transformation. The next question would be how is done, but still this is not a 
bug or FOP issue.

> ValidationException: fo:table-row is missing child elements
> ---
>
> Key: FOP-2968
> URL: https://issues.apache.org/jira/browse/FOP-2968
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 2.5, 2.4
>Reporter: Ed Belov
>Priority: Critical
> Attachments: in3.docx, out3.fo
>
>
> Good day. 
> There is a problem with merging cells. All table cells contain joins. How can 
> I be in this case?
> An error occurs when generating pdf.
> SEVERE: Exception
> org.apache.fop.apps.FOPException: org.apache.fop.fo.ValidationException: 
> "fo:table-row" is missing child elements.
> red content model: (table-cell+) 
> Thank.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (FOP-2968) ValidationException: fo:table-row is missing child elements

2020-09-07 Thread Alexios Giotis (Jira)



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

Alexios Giotis commented on FOP-2968:
-

This does not look like a bug. In the attached FO, there is indeed a 
fo:table-row with missing child elements.
{code:xml}

{code}
The [Apache FOP Users Mailing 
List|https://xmlgraphics.apache.org/fop/maillist.html] is one place to submit 
questions.

> ValidationException: fo:table-row is missing child elements
> ---
>
> Key: FOP-2968
> URL: https://issues.apache.org/jira/browse/FOP-2968
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 2.5, 2.4
>Reporter: Ed Belov
>Priority: Critical
> Attachments: out3.fo
>
>
> Good day. 
> There is a problem with merging cells. All table cells contain joins. How can 
> I be in this case?
> An error occurs when generating pdf.
> SEVERE: Exception
> org.apache.fop.apps.FOPException: org.apache.fop.fo.ValidationException: 
> "fo:table-row" is missing child elements.
> red content model: (table-cell+) 
> Thank.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (FOP-2917) Superscript / sub script shifted to the next character

2020-03-17 Thread Alexios Giotis (Jira)



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

Alexios Giotis commented on FOP-2917:
-

Hi, you need to provide at least the FOP version, a small input XSL-FO that 
reproduces this problem and fop.xconf. For more information, check 
[https://xmlgraphics.apache.org/fop/bugs.html#issues_new 
|https://xmlgraphics.apache.org/fop/bugs.html#issues_new.]

Increasing the priority of an incomplete issue, has no effect.

> Superscript / sub script shifted to the next character
> --
>
> Key: FOP-2917
> URL: https://issues.apache.org/jira/browse/FOP-2917
> Project: FOP
>  Issue Type: Bug
>Reporter: Fung Cheung
>Priority: Critical
>
> Hello,
>  
> We are experiencing a weird issue where text with superscripts/ subscripts 
> sometimes are changed in the FOP PDF output.
> E.g.
> input text: Gestión
> output text: Gestíon
> input text:  años
> output text: ãnos
>  
> With the same input, the output is always the same. However this doesn't 
> happen to all superscripts. I am not able to find a pattern of what input 
> would trigger the incorrect output.
>  
> Please help, thanks!
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (FOP-2581) [PATCH] NumberFormatException when page-sequence format can't be parsed as an Integer

2016-02-26 Thread Alexios Giotis (JIRA)


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

Alexios Giotis commented on FOP-2581:
-

barcode4j-2.1.jar & barcode4j-fop-ext-2.1.jar need to be in the lib directory.

> [PATCH] NumberFormatException when page-sequence format can't be parsed as an 
> Integer
> -
>
> Key: FOP-2581
> URL: https://issues.apache.org/jira/browse/FOP-2581
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Alexios Giotis
> Attachments: FOP-2581.patch, barcode-test.fo, out.if.xml, out.pdf
>
>
> This was introduced in FOP-2548 "Support Barcode4J page number". The test FO 
> of FOP-2548 was changed by specifying a format in 
> 
> To reproduce it:
> {noformat}
> $ ./fop barcode-test.fo -if out.if.xml
> Feb 26, 2016 2:29:14 PM org.apache.fop.events.LoggingEventListener 
> processEvent
> INFO: Rendered page #1.
> Feb 26, 2016 2:29:14 PM org.apache.fop.events.LoggingEventListener 
> processEvent
> INFO: Rendered page #2.
> $ ./fop -ifin out.if.xml out.pdf
> Feb 26, 2016 2:29:47 PM org.apache.fop.cli.Main startFOP
> SEVERE: Exception
> org.apache.fop.apps.FOPException: For input string: "A"
> java.lang.NumberFormatException: For input string: "A"
>   at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:288)
>   at org.apache.fop.cli.IFInputHandler.renderTo(IFInputHandler.java:77)
>   at org.apache.fop.cli.Main.startFOP(Main.java:186)
>   at org.apache.fop.cli.Main.main(Main.java:217)
> Caused by: java.lang.NumberFormatException: For input string: "A"
>   at 
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
>   at java.lang.Integer.parseInt(Integer.java:492)
>   at java.lang.Integer.parseInt(Integer.java:527)
>   at 
> org.apache.fop.render.intermediate.IFParser$Handler$PageHandler.startElement(IFParser.java:526)
>   at 
> org.apache.fop.render.intermediate.IFParser$Handler.startIFElement(IFParser.java:369)
>   at 
> org.apache.fop.render.intermediate.IFParser$Handler.startElement(IFParser.java:310)
>   at 
> org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1073)
>   at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown 
> Source)
>   at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown 
> Source)
>   at 
> org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown 
> Source)
>   at 
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
>  Source)
>   at 
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
> Source)
>   at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
>   at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
>   at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
>   at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
>   at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown 
> Source)
>   at 
> org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:485)
>   at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:285)
>   ... 3 more
> {noformat}



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

[jira] [Updated] (FOP-2581) [PATCH] NumberFormatException when page-sequence format can't be parsed as an Integer

2016-02-26 Thread Alexios Giotis (JIRA)


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

Alexios Giotis updated FOP-2581:

Description: 
This was introduced in FOP-2548 "Support Barcode4J page number". The test FO of 
FOP-2548 was changed by specifying a format in 




To reproduce it:

{noformat}
$ ./fop barcode-test.fo -if out.if.xml
Feb 26, 2016 2:29:14 PM org.apache.fop.events.LoggingEventListener processEvent
INFO: Rendered page #1.
Feb 26, 2016 2:29:14 PM org.apache.fop.events.LoggingEventListener processEvent
INFO: Rendered page #2.


$ ./fop -ifin out.if.xml out.pdf
Feb 26, 2016 2:29:47 PM org.apache.fop.cli.Main startFOP
SEVERE: Exception
org.apache.fop.apps.FOPException: For input string: "A"
java.lang.NumberFormatException: For input string: "A"
at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:288)
at org.apache.fop.cli.IFInputHandler.renderTo(IFInputHandler.java:77)
at org.apache.fop.cli.Main.startFOP(Main.java:186)
at org.apache.fop.cli.Main.main(Main.java:217)
Caused by: java.lang.NumberFormatException: For input string: "A"
at 
java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:492)
at java.lang.Integer.parseInt(Integer.java:527)
at 
org.apache.fop.render.intermediate.IFParser$Handler$PageHandler.startElement(IFParser.java:526)
at 
org.apache.fop.render.intermediate.IFParser$Handler.startIFElement(IFParser.java:369)
at 
org.apache.fop.render.intermediate.IFParser$Handler.startElement(IFParser.java:310)
at 
org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1073)
at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown 
Source)
at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown 
Source)
at 
org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
 Source)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown 
Source)
at 
org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:485)
at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:285)
... 3 more
{noformat}

  was:
This was introduced in FOP-2548 "Support Barcode4J page number", so I am the 
test FO is based on this.

To reproduce it:

{noformat}
$ ./fop barcode-test.fo -if out.if.xml
Feb 26, 2016 2:29:14 PM org.apache.fop.events.LoggingEventListener processEvent
INFO: Rendered page #1.
Feb 26, 2016 2:29:14 PM org.apache.fop.events.LoggingEventListener processEvent
INFO: Rendered page #2.


$ ./fop -ifin out.if.xml out.pdf
Feb 26, 2016 2:29:47 PM org.apache.fop.cli.Main startFOP
SEVERE: Exception
org.apache.fop.apps.FOPException: For input string: "A"
java.lang.NumberFormatException: For input string: "A"
at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:288)
at org.apache.fop.cli.IFInputHandler.renderTo(IFInputHandler.java:77)
at org.apache.fop.cli.Main.startFOP(Main.java:186)
at org.apache.fop.cli.Main.main(Main.java:217)
Caused by: java.lang.NumberFormatException: For input string: "A"
at 
java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:492)
at java.lang.Integer.parseInt(Integer.java:527)
at 
org.apache.fop.render.intermediate.IFParser$Handler$PageHandler.startElement(IFParser.java:526)
at 
org.apache.fop.render.intermediate.IFParser$Handler.startIFElement(IFParser.java:369)
at 
org.apache.fop.render.intermediate.IFParser$Handler.startElement(IFParser.java:310)
at 
org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1073)
at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown 
Source)
at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown 
Source)
at 
org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
 Source)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)

[jira] [Updated] (FOP-2581) NumberFormatException when page-sequence format can't be parsed as an Integer

2016-02-26 Thread Alexios Giotis (JIRA)


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

Alexios Giotis updated FOP-2581:

Attachment: FOP-2581.patch

Patch, test input & output files attached.

> NumberFormatException when page-sequence format can't be parsed as an Integer
> -
>
> Key: FOP-2581
> URL: https://issues.apache.org/jira/browse/FOP-2581
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Alexios Giotis
> Attachments: FOP-2581.patch, barcode-test.fo, out.if.xml, out.pdf
>
>
> This was introduced in FOP-2548 "Support Barcode4J page number", so I am the 
> test FO is based on this.
> To reproduce it:
> {noformat}
> $ ./fop barcode-test.fo -if out.if.xml
> Feb 26, 2016 2:29:14 PM org.apache.fop.events.LoggingEventListener 
> processEvent
> INFO: Rendered page #1.
> Feb 26, 2016 2:29:14 PM org.apache.fop.events.LoggingEventListener 
> processEvent
> INFO: Rendered page #2.
> $ ./fop -ifin out.if.xml out.pdf
> Feb 26, 2016 2:29:47 PM org.apache.fop.cli.Main startFOP
> SEVERE: Exception
> org.apache.fop.apps.FOPException: For input string: "A"
> java.lang.NumberFormatException: For input string: "A"
>   at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:288)
>   at org.apache.fop.cli.IFInputHandler.renderTo(IFInputHandler.java:77)
>   at org.apache.fop.cli.Main.startFOP(Main.java:186)
>   at org.apache.fop.cli.Main.main(Main.java:217)
> Caused by: java.lang.NumberFormatException: For input string: "A"
>   at 
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
>   at java.lang.Integer.parseInt(Integer.java:492)
>   at java.lang.Integer.parseInt(Integer.java:527)
>   at 
> org.apache.fop.render.intermediate.IFParser$Handler$PageHandler.startElement(IFParser.java:526)
>   at 
> org.apache.fop.render.intermediate.IFParser$Handler.startIFElement(IFParser.java:369)
>   at 
> org.apache.fop.render.intermediate.IFParser$Handler.startElement(IFParser.java:310)
>   at 
> org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1073)
>   at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown 
> Source)
>   at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown 
> Source)
>   at 
> org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown 
> Source)
>   at 
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
>  Source)
>   at 
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
> Source)
>   at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
>   at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
>   at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
>   at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
>   at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown 
> Source)
>   at 
> org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:485)
>   at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:285)
>   ... 3 more
> {noformat}



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

[jira] [Updated] (FOP-2581) [PATCH] NumberFormatException when page-sequence format can't be parsed as an Integer

2016-02-26 Thread Alexios Giotis (JIRA)


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

Alexios Giotis updated FOP-2581:

Summary: [PATCH] NumberFormatException when page-sequence format can't be 
parsed as an Integer  (was: NumberFormatException when page-sequence format 
can't be parsed as an Integer)

> [PATCH] NumberFormatException when page-sequence format can't be parsed as an 
> Integer
> -
>
> Key: FOP-2581
> URL: https://issues.apache.org/jira/browse/FOP-2581
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Alexios Giotis
> Attachments: FOP-2581.patch, barcode-test.fo, out.if.xml, out.pdf
>
>
> This was introduced in FOP-2548 "Support Barcode4J page number", so I am the 
> test FO is based on this.
> To reproduce it:
> {noformat}
> $ ./fop barcode-test.fo -if out.if.xml
> Feb 26, 2016 2:29:14 PM org.apache.fop.events.LoggingEventListener 
> processEvent
> INFO: Rendered page #1.
> Feb 26, 2016 2:29:14 PM org.apache.fop.events.LoggingEventListener 
> processEvent
> INFO: Rendered page #2.
> $ ./fop -ifin out.if.xml out.pdf
> Feb 26, 2016 2:29:47 PM org.apache.fop.cli.Main startFOP
> SEVERE: Exception
> org.apache.fop.apps.FOPException: For input string: "A"
> java.lang.NumberFormatException: For input string: "A"
>   at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:288)
>   at org.apache.fop.cli.IFInputHandler.renderTo(IFInputHandler.java:77)
>   at org.apache.fop.cli.Main.startFOP(Main.java:186)
>   at org.apache.fop.cli.Main.main(Main.java:217)
> Caused by: java.lang.NumberFormatException: For input string: "A"
>   at 
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
>   at java.lang.Integer.parseInt(Integer.java:492)
>   at java.lang.Integer.parseInt(Integer.java:527)
>   at 
> org.apache.fop.render.intermediate.IFParser$Handler$PageHandler.startElement(IFParser.java:526)
>   at 
> org.apache.fop.render.intermediate.IFParser$Handler.startIFElement(IFParser.java:369)
>   at 
> org.apache.fop.render.intermediate.IFParser$Handler.startElement(IFParser.java:310)
>   at 
> org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1073)
>   at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown 
> Source)
>   at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown 
> Source)
>   at 
> org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown 
> Source)
>   at 
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
>  Source)
>   at 
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
> Source)
>   at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
>   at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
>   at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
>   at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
>   at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown 
> Source)
>   at 
> org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:485)
>   at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:285)
>   ... 3 more
> {noformat}



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

[jira] [Updated] (FOP-2581) NumberFormatException when page-sequence format can't be parsed as an Integer

2016-02-26 Thread Alexios Giotis (JIRA)


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

Alexios Giotis updated FOP-2581:

Attachment: out.pdf
out.if.xml
barcode-test.fo

> NumberFormatException when page-sequence format can't be parsed as an Integer
> -
>
> Key: FOP-2581
> URL: https://issues.apache.org/jira/browse/FOP-2581
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Alexios Giotis
> Attachments: barcode-test.fo, out.if.xml, out.pdf
>
>
> This was introduced in FOP-2548 "Support Barcode4J page number", so I am the 
> test FO is based on this.
> To reproduce it:
> {noformat}
> $ ./fop barcode-test.fo -if out.if.xml
> Feb 26, 2016 2:29:14 PM org.apache.fop.events.LoggingEventListener 
> processEvent
> INFO: Rendered page #1.
> Feb 26, 2016 2:29:14 PM org.apache.fop.events.LoggingEventListener 
> processEvent
> INFO: Rendered page #2.
> $ ./fop -ifin out.if.xml out.pdf
> Feb 26, 2016 2:29:47 PM org.apache.fop.cli.Main startFOP
> SEVERE: Exception
> org.apache.fop.apps.FOPException: For input string: "A"
> java.lang.NumberFormatException: For input string: "A"
>   at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:288)
>   at org.apache.fop.cli.IFInputHandler.renderTo(IFInputHandler.java:77)
>   at org.apache.fop.cli.Main.startFOP(Main.java:186)
>   at org.apache.fop.cli.Main.main(Main.java:217)
> Caused by: java.lang.NumberFormatException: For input string: "A"
>   at 
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
>   at java.lang.Integer.parseInt(Integer.java:492)
>   at java.lang.Integer.parseInt(Integer.java:527)
>   at 
> org.apache.fop.render.intermediate.IFParser$Handler$PageHandler.startElement(IFParser.java:526)
>   at 
> org.apache.fop.render.intermediate.IFParser$Handler.startIFElement(IFParser.java:369)
>   at 
> org.apache.fop.render.intermediate.IFParser$Handler.startElement(IFParser.java:310)
>   at 
> org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1073)
>   at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown 
> Source)
>   at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown 
> Source)
>   at 
> org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown 
> Source)
>   at 
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
>  Source)
>   at 
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
> Source)
>   at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
>   at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
>   at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
>   at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
>   at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown 
> Source)
>   at 
> org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:485)
>   at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:285)
>   ... 3 more
> {noformat}



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

[jira] [Created] (FOP-2581) NumberFormatException when page-sequence format can't be parsed as an Integer

2016-02-26 Thread Alexios Giotis (JIRA)

Alexios Giotis created FOP-2581:
---

 Summary: NumberFormatException when page-sequence format can't be 
parsed as an Integer
 Key: FOP-2581
 URL: https://issues.apache.org/jira/browse/FOP-2581
 Project: FOP
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Alexios Giotis


This was introduced in FOP-2548 "Support Barcode4J page number", so I am the 
test FO is based on this.

To reproduce it:

{noformat}
$ ./fop barcode-test.fo -if out.if.xml
Feb 26, 2016 2:29:14 PM org.apache.fop.events.LoggingEventListener processEvent
INFO: Rendered page #1.
Feb 26, 2016 2:29:14 PM org.apache.fop.events.LoggingEventListener processEvent
INFO: Rendered page #2.


$ ./fop -ifin out.if.xml out.pdf
Feb 26, 2016 2:29:47 PM org.apache.fop.cli.Main startFOP
SEVERE: Exception
org.apache.fop.apps.FOPException: For input string: "A"
java.lang.NumberFormatException: For input string: "A"
at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:288)
at org.apache.fop.cli.IFInputHandler.renderTo(IFInputHandler.java:77)
at org.apache.fop.cli.Main.startFOP(Main.java:186)
at org.apache.fop.cli.Main.main(Main.java:217)
Caused by: java.lang.NumberFormatException: For input string: "A"
at 
java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:492)
at java.lang.Integer.parseInt(Integer.java:527)
at 
org.apache.fop.render.intermediate.IFParser$Handler$PageHandler.startElement(IFParser.java:526)
at 
org.apache.fop.render.intermediate.IFParser$Handler.startIFElement(IFParser.java:369)
at 
org.apache.fop.render.intermediate.IFParser$Handler.startElement(IFParser.java:310)
at 
org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1073)
at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown 
Source)
at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown 
Source)
at 
org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
 Source)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown 
Source)
at 
org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:485)
at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:285)
... 3 more
{noformat}



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

[jira] [Resolved] (FOP-2400) HashCode collisions

2014-07-25 Thread Alexios Giotis (JIRA)


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

Alexios Giotis resolved FOP-2400.
-

Resolution: Fixed

Thank you for providing a test case. I could reproduce the issue with FOP 1.1 
but not with FOP trunk after the recent ( 2014-07-23 12:03:37 +) commit by 
Luis Bernardo. I also did a temporary local commit in PropertyCache.java to 
check that the PropertyCache is indeed caching  returning among other, 
instances of  
org.apache.fop.fo.properties.CommonBorderPaddingBackground$BorderInfo.
{quote}
apache-fop $ git checkout fop-1_1
apache-fop $ ant clean package

apache-fop $ ./fop -fo hashcode_collision.fo -pdf hashcode_collision.pdf 21 | 
grep hashCode 
INFO: 10 hashCode() collisions for org.apache.fop.fo.properties.ColorProperty
INFO: 20 hashCode() collisions for org.apache.fop.fo.properties.ColorProperty


apache-fop $ git checkout trunk
apache-fop $ ant clean package
apache-fop $ ./fop -fo hashcode_collision.fo -pdf hashcode_collision.pdf 21 | 
grep hashCode 
apache-fop $ git-log  | head -1
* 79d889c 2014-07-23 12:03:37 + Luis Bernardo  (HEAD, origin/trunk, 
origin/HEAD, trunk)FOP-2307: Weird border color inheritance (hashCode 
collisions); change suggested by Alexios Giotis.
{quote}

So, I am resolving this.



 HashCode collisions
 ---

 Key: FOP-2400
 URL: https://issues.apache.org/jira/browse/FOP-2400
 Project: Fop
  Issue Type: Bug
Affects Versions: 1.1
Reporter: Jan Tošovský
Priority: Minor
 Attachments: hashcode_collision.fo


 As discussed in https://issues.apache.org/jira/browse/FOP-2307 I've prepared 
 a simple test case for testing hash collisions.



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

[jira] [Updated] (FOP-2307) Weird border color inheritance (hashCode collisions)

2014-07-25 Thread Alexios Giotis (JIRA)


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

Alexios Giotis updated FOP-2307:


Attachment: fop-2307.patch

 Weird border color inheritance (hashCode collisions)
 

 Key: FOP-2307
 URL: https://issues.apache.org/jira/browse/FOP-2307
 Project: Fop
  Issue Type: Bug
  Components: renderer/pdf
Affects Versions: 1.1
 Environment: Windows 7/64-bit, Oracle JDK 7.0.45 64-bit
Reporter: Jan Tošovský
  Labels: border, cmyk, color
 Fix For: trunk

 Attachments: fop-2307.patch


 When I define an object with a specific border and the thickness of this 
 border matches with the one defined in the static-content, the latter color 
 is used instead. But it appears only if my object color is specified using 
 the pseudo #CMYK profile.
 It can be tested with this simplified test case:
 http://drifted.in/other/_border.fo
 http://drifted.in/other/_border.pdf
 The first object border uses the standard color so it is unaffected.
 The second is affected.
 The third uses a different thickness (3.5pt instead of 2.5) so it is also 
 unaffected.
 In the generating log there are lot of following hashCode collisions so I 
 suppose it relates together:
 X 23, 2013 5:09:34 ODP. org.apache.fop.fo.properties.PropertyCache fetch
 INFO: 60 hashCode() collisions for org.apache.fop.fo.properties.ColorProperty
 X 23, 2013 5:09:34 ODP. org.apache.fop.fo.properties.PropertyCache fetch
 INFO: 70 hashCode() collisions for org.apache.fop.fo.properties.ColorProperty



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

[jira] [Updated] (FOP-2307) [PATCH] Weird border color inheritance (hashCode collisions)

2014-07-25 Thread Alexios Giotis (JIRA)


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

Alexios Giotis updated FOP-2307:


Summary: [PATCH] Weird border color inheritance (hashCode collisions)  
(was: Weird border color inheritance (hashCode collisions))

 [PATCH] Weird border color inheritance (hashCode collisions)
 

 Key: FOP-2307
 URL: https://issues.apache.org/jira/browse/FOP-2307
 Project: Fop
  Issue Type: Bug
  Components: renderer/pdf
Affects Versions: 1.1
 Environment: Windows 7/64-bit, Oracle JDK 7.0.45 64-bit
Reporter: Jan Tošovský
  Labels: border, cmyk, color
 Fix For: trunk

 Attachments: fop-2307.patch


 When I define an object with a specific border and the thickness of this 
 border matches with the one defined in the static-content, the latter color 
 is used instead. But it appears only if my object color is specified using 
 the pseudo #CMYK profile.
 It can be tested with this simplified test case:
 http://drifted.in/other/_border.fo
 http://drifted.in/other/_border.pdf
 The first object border uses the standard color so it is unaffected.
 The second is affected.
 The third uses a different thickness (3.5pt instead of 2.5) so it is also 
 unaffected.
 In the generating log there are lot of following hashCode collisions so I 
 suppose it relates together:
 X 23, 2013 5:09:34 ODP. org.apache.fop.fo.properties.PropertyCache fetch
 INFO: 60 hashCode() collisions for org.apache.fop.fo.properties.ColorProperty
 X 23, 2013 5:09:34 ODP. org.apache.fop.fo.properties.PropertyCache fetch
 INFO: 70 hashCode() collisions for org.apache.fop.fo.properties.ColorProperty



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

[jira] [Updated] (FOP-2307) [PATCH] Weird border color inheritance (hashCode collisions)

2014-07-25 Thread Alexios Giotis (JIRA)


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

Alexios Giotis updated FOP-2307:


Attachment: FOP-2307-NOT_FOR_COMMIT.patch

A method to verify it is to *temporarily* make the change in attached  
FOP-2307-NOT_FOR_COMMIT.patch and execute

 bq. ./fop -fo hashcode_collision.fo -pdf hashcode_collision.pdf
The hashcode_collision.fo is the one attached in FOP-2400.

Before the fix in XGC, no info messages should be logged by the changed 
PropertyCache. After the fix, 60 lines containing {{Returning cached 
org.apache.fop.fo.properties.ColorProperty}} should be logged.


 [PATCH] Weird border color inheritance (hashCode collisions)
 

 Key: FOP-2307
 URL: https://issues.apache.org/jira/browse/FOP-2307
 Project: Fop
  Issue Type: Bug
  Components: renderer/pdf
Affects Versions: 1.1
 Environment: Windows 7/64-bit, Oracle JDK 7.0.45 64-bit
Reporter: Jan Tošovský
  Labels: border, cmyk, color
 Fix For: trunk

 Attachments: FOP-2307-NOT_FOR_COMMIT.patch, fop-2307.patch


 When I define an object with a specific border and the thickness of this 
 border matches with the one defined in the static-content, the latter color 
 is used instead. But it appears only if my object color is specified using 
 the pseudo #CMYK profile.
 It can be tested with this simplified test case:
 http://drifted.in/other/_border.fo
 http://drifted.in/other/_border.pdf
 The first object border uses the standard color so it is unaffected.
 The second is affected.
 The third uses a different thickness (3.5pt instead of 2.5) so it is also 
 unaffected.
 In the generating log there are lot of following hashCode collisions so I 
 suppose it relates together:
 X 23, 2013 5:09:34 ODP. org.apache.fop.fo.properties.PropertyCache fetch
 INFO: 60 hashCode() collisions for org.apache.fop.fo.properties.ColorProperty
 X 23, 2013 5:09:34 ODP. org.apache.fop.fo.properties.PropertyCache fetch
 INFO: 70 hashCode() collisions for org.apache.fop.fo.properties.ColorProperty



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

[jira] [Commented] (FOP-2157) Deadlock in CompareUtil class

2014-03-26 Thread Alexios Giotis (JIRA)


[ 
https://issues.apache.org/jira/browse/FOP-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13947949#comment-13947949
 ] 

Alexios Giotis commented on FOP-2157:
-

I think the suggestion above would fix it, since this is a lock ordering 
deadlock. I also don't expect to see any difference in performance, 
System.identityHashCode is a relatively cheap operation. 

Johannes Herr, since you were able to reproduce it in the past, could you check 
that the above patch fixes this problem ?

 Deadlock in CompareUtil class
 -

 Key: FOP-2157
 URL: https://issues.apache.org/jira/browse/FOP-2157
 Project: Fop
  Issue Type: Bug
  Components: general
Affects Versions: trunk
 Environment: Operating System: All
 Platform: PC
Reporter: Matthias Reischenbacher
Assignee: Alexios Giotis
 Attachments: FOP DEADLOCK jakarta_service_20121107.log, 
 report-dump.txt, thread-dump.txt


 I'm getting a dead lock in the CompareUtil class, see the attached thread 
 dump. 
 Here small fragment of the thread dump
 [2012-11-07 14:06:25] [info] Found one Java-level deadlock:
 [2012-11-07 14:06:25] [info] =
 [2012-11-07 14:06:25] [info] 
 [2012-11-07 14:06:25] [info] http-80-exec-58:
 [2012-11-07 14:06:25] [info]   waiting to lock monitor 0x06ca9480
 [2012-11-07 14:06:25] [info]  (object 0x00071fe9bd00, a java.util.Vector)
 [2012-11-07 14:06:25] [info] ,
   which is held by http-80-exec-5
 [2012-11-07 14:06:25] [info] 
 [2012-11-07 14:06:25] [info] http-80-exec-5:
 [2012-11-07 14:06:25] [info]   waiting to lock monitor 0x116ecfc8
 [2012-11-07 14:06:25] [info]  (object 0x00071fe9a000, a java.util.Vector)
 [2012-11-07 14:06:25] [info] ,
   which is held by http-80-exec-18
 [2012-11-07 14:06:25] [info] 
 [2012-11-07 14:06:25] [info] http-80-exec-18:
 [2012-11-07 14:06:25] [info]   waiting to lock monitor 0x06ca9480
 [2012-11-07 14:06:25] [info]  (object 0x00071fe9bd00, a java.util.Vector)
 [2012-11-07 14:06:25] [info] ,
   which is held by http-80-exec-5
 [2012-11-07 14:06:25] [info] 
 [2012-11-07 14:06:25] [info] 
 [2012-11-07 14:06:25] [info] Java stack information for the threads listed 
 above:
 [2012-11-07 14:06:25] [info] 
 ===
 [2012-11-07 14:06:25] [info] http-80-exec-58:
 [2012-11-07 14:06:25] [info]  at java.util.Vector.equals(Vector.java:925)
 [2012-11-07 14:06:25] [info]  - waiting to lock 0x00071fe9bd00 
 [2012-11-07 14:06:25] [info] (a java.util.Vector)
 [2012-11-07 14:06:25] [info]  at 
 org.apache.fop.util.CompareUtil.equal(CompareUtil.java:38)
 [2012-11-07 14:06:25] [info]  at 
 org.apache.fop.fo.properties.ListProperty.equals(ListProperty.java:123)
 [2012-11-07 14:06:25] [info]  at 
 org.apache.fop.fo.properties.PropertyCache.eq(PropertyCache.java:193)
 [2012-11-07 14:06:25] [info]  at 
 org.apache.fop.fo.properties.PropertyCache.fetch(PropertyCache.java:134)
 [2012-11-07 14:06:26] [info]  at 
 org.apache.fop.fo.properties.FontFamilyProperty$Maker.make(FontFamilyProperty.java:94)
 [2012-11-07 14:06:26] [info]  at 
 org.apache.fop.fo.PropertyList.convertAttributeToProperty(PropertyList.java:413)
 [2012-11-07 14:06:26] [info]  at 
 org.apache.fop.fo.PropertyList.addAttributesToList(PropertyList.java:321)
 [2012-11-07 14:06:26] [info]  at 
 org.apache.fop.fo.FObj.processNode(FObj.java:122)
 [2012-11-07 14:06:26] [info]  at 
 org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:280)
 [2012-11-07 14:06:26] [info]  at 
 org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:175)
 [2012-11-07 14:06:26] [info]  at 
 org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1073)
 [2012-11-07 14:06:26] [info]  at 
 org.apache.xml.serializer.TreeWalker.startNode(TreeWalker.java:359)
 [2012-11-07 14:06:26] [info]  at 
 org.apache.xml.serializer.TreeWalker.traverse(TreeWalker.java:145)
 [2012-11-07 14:06:26] [info]  at 
 org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:390)
 [2012-11-07 14:06:26] [info]  at 
 smc.fop.FopWrapper.transform(FopWrapper.java:150)
 [2012-11-07 14:06:26] [info]  at 
 smc.fop.FopWrapper.transform(FopWrapper.java:125)
 [2012-11-07 14:06:26] [info]  at smc.plugin.Dom2PDF.process(Dom2PDF.java:179)
 [2012-11-07 14:06:26] [info]  at 
 sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
 [2012-11-07 14:06:26] [info]  at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 [2012-11-07 14:06:26] [info]  at 
 java.lang.reflect.Method.invoke(Method.java:597)
 [2012-11-07 14:06:26] [info]  at 
 smc.transform.core.dynacode.DynaCode$MyInvocationHandler.invoke(DynaCode.java:374)
 [2012-11-07 14:06:26] [info]  at $Proxy35.process(Unknown

[jira] [Commented] (FOP-2307) Weird border color inheritance (hashCode collisions)

2013-10-26 Thread Alexios Giotis (JIRA)


[ 
https://issues.apache.org/jira/browse/FOP-2307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13806153#comment-13806153
 ] 

Alexios Giotis commented on FOP-2307:
-

Jan, could you please attach an XSL:FO file that reproduces at least the 
hashCode collisions message ?

The log message is written to discover objects with inconsistent 
hashCode/equals methods that could not be found at development time. Here, we 
found such an object.

 Weird border color inheritance (hashCode collisions)
 

 Key: FOP-2307
 URL: https://issues.apache.org/jira/browse/FOP-2307
 Project: Fop
  Issue Type: Bug
  Components: pdf
Affects Versions: 1.1
 Environment: Windows 7/64-bit, Oracle JDK 7.0.45 64-bit
Reporter: Jan Tošovský
  Labels: border, cmyk, color

 When I define an object with a specific border and the thickness of this 
 border matches with the one defined in the static-content, the latter color 
 is used instead. But it appears only if my object color is specified using 
 the pseudo #CMYK profile.
 It can be tested with this simplified test case:
 http://drifted.in/other/_border.fo
 http://drifted.in/other/_border.pdf
 The first object border uses the standard color so it is unaffected.
 The second is affected.
 The third uses a different thickness (3.5pt instead of 2.5) so it is also 
 unaffected.
 In the generating log there are lot of following hashCode collisions so I 
 suppose it relates together:
 X 23, 2013 5:09:34 ODP. org.apache.fop.fo.properties.PropertyCache fetch
 INFO: 60 hashCode() collisions for org.apache.fop.fo.properties.ColorProperty
 X 23, 2013 5:09:34 ODP. org.apache.fop.fo.properties.PropertyCache fetch
 INFO: 70 hashCode() collisions for org.apache.fop.fo.properties.ColorProperty



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (FOP-2307) Weird border color inheritance (hashCode collisions)

2013-10-25 Thread Alexios Giotis (JIRA)

[
https://issues.apache.org/jira/browse/FOP-2307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13805302#comment-13805302
]

Alexios Giotis commented on FOP-2307:
-

I was not able to reproduce this in FOP 1.1 or trunk by executing
fop -fo _border.fo -pdf _border.pdf

What do you reproduce it ?

I assume that many PDFs are created since there are hashCode() collisions.
This is an INFO message to inform that a FOP internal cache is not optimally
used and it should not be related to any color problems.

In more details, this means that the FOP internal cache is filled with
org.apache.fop.fo.properties.ColorProperty objects that have the same hashCode
but are not equal. The key of the cache is the hashCode so only one of them can
be cached. New instances are created for the other ones, so there is a
suboptimal use of the cache.

Having a look at the code, this happens when ColorProperty objects (put in the
cache) have a color that is an instance of
org.apache.xmlgraphics.java2d.color.ColorWithAlternatives. In that case, the
hashCode is generated using only the RGB value of the java.awt.Color and not
taking into account the alternativeColors.

I could submit a patch to avoid collisions and make better use of the cache but
I don't think it will resolve the main issue reported here.

Weird border color inheritance (hashCode collisions)

Key: FOP-2307
URL: https://issues.apache.org/jira/browse/FOP-2307
Project: Fop
Issue Type: Bug
Components: pdf
Affects Versions: 1.1
Environment: Windows 7/64-bit, Oracle JDK 7.0.45 64-bit
Reporter: Jan Tošovský
Labels: border, cmyk, color

When I define an object with a specific border and the thickness of this
border matches with the one defined in the static-content, the latter color
is used instead. But it appears only if my object color is specified using
the pseudo #CMYK profile.
It can be tested with this simplified test case:
http://drifted.in/other/_border.fo
http://drifted.in/other/_border.pdf
The first object border uses the standard color so it is unaffected.
The second is affected.
The third uses a different thickness (3.5pt instead of 2.5) so it is also
unaffected.
In the generating log there are lot of following hashCode collisions so I
suppose it relates together:
X 23, 2013 5:09:34 ODP. org.apache.fop.fo.properties.PropertyCache fetch
INFO: 60 hashCode() collisions for org.apache.fop.fo.properties.ColorProperty
X 23, 2013 5:09:34 ODP. org.apache.fop.fo.properties.PropertyCache fetch
INFO: 70 hashCode() collisions for org.apache.fop.fo.properties.ColorProperty

--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (FOP-2211) [PATCH] Fix improve the handling of temporary files using the new URI resource resolvers

2013-04-16 Thread Alexios Giotis (JIRA)

[
https://issues.apache.org/jira/browse/FOP-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13633353#comment-13633353
]

Alexios Giotis commented on FOP-2211:
-

Peter, thanks for committing this.

Vincent, I have not started working since the patch addresses my runtime issues
and I was not sure if there was an agreement on changing that. After an
official release, it will be much harder to improve the handling of temporary
resources as it's part of the public API. So, I will give it a try next week
and if it looks good, I will post the patches for FOP and XGC.

[PATCH] Fix improve the handling of temporary files using the new URI
resource resolvers
--

Key: FOP-2211
URL: https://issues.apache.org/jira/browse/FOP-2211
Project: Fop
Issue Type: Bug
Components: general
Affects Versions: trunk
Reporter: Alexios Giotis
Assignee: Peter Hancock
Fix For: trunk

Attachments: fop.patch, fop.patch, tempurisimple.patch, xgc.patch

As written in http://markmail.org/message/zelumstxxsdyvkcz , after the merge
of the Temp_URI_Resolution branch (Sept 2012), the actual pattern of using
temp files has changed from:
{code}
File tmpFile = File.createTempFile();
// Write and read from the file
tmpFile.delete();
{code}
to:
{code}
File tmpFile = new File(System.getProperty(java.io.tmpdir),
counterStartingFrom1AsString);
tmpFile.deleteOnExit();
// Write and read from the file
{code}
This is fine when FOP is executed from the command line (which I guess this
is how most people use it) but it introduces a number of bad side effects for
long running processes that use FOP embedded.

1. Different FOP processes can't be executed in parallel on the same system
because creating the same temp file fails.
2. If the JVM is not normally terminated, the temp files are never deleted
and the next invocation of the JVM fails to run.
3. deleteOnExit() keeps for the life of the JVM an unknown number of temp
files both on disk and a reference in memory.
There should not be a need to implement a custom resource resolver when using
FOP embedded in order to fix those issues. The default implementation should
work at least as good as it worked in FOP 1.1 or earlier.
Attached are 2 patches, one for XGC and one for FOP that should fix and
improve the handling of at least the temporary files.
For reference, [1] lists some reasons for implementing the new URI resource
resolvers.
[1] http://wiki.apache.org/xmlgraphics-fop/URIResolution

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (FOP-2211) [PATCH] Fix improve the handling of temporary files using the new URI resource resolvers

2013-04-08 Thread Alexios Giotis (JIRA)


[ 
https://issues.apache.org/jira/browse/FOP-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13625920#comment-13625920
 ] 

Alexios Giotis commented on FOP-2211:
-

Peter (or any other committer), will you commit your (Peter's) patch with the 
exception of the deleteOnExit() method ?

Or do you prefer that I create another (bigger) patch that will not be 100% 
compatible with the current trunk but will attempt to give an elegant way of 
handling temp files ?

 [PATCH] Fix  improve the handling of temporary files using the new URI 
 resource resolvers
 --

 Key: FOP-2211
 URL: https://issues.apache.org/jira/browse/FOP-2211
 Project: Fop
  Issue Type: Bug
  Components: general
Affects Versions: trunk
Reporter: Alexios Giotis
 Fix For: trunk

 Attachments: fop.patch, fop.patch, tempurisimple.patch, xgc.patch


 As written in http://markmail.org/message/zelumstxxsdyvkcz , after the merge 
 of the Temp_URI_Resolution branch (Sept 2012), the actual pattern of using 
 temp files has changed from:
 {code}
 File tmpFile = File.createTempFile();
 // Write and read from the file
 tmpFile.delete();
 {code}
 to:
 {code}
 File tmpFile = new File(System.getProperty(java.io.tmpdir), 
 counterStartingFrom1AsString);
 tmpFile.deleteOnExit();
 // Write and read from the file
 {code}
 This is fine when FOP is executed from the command line (which I guess this 
 is how most people use it) but it introduces a number of bad side effects for 
 long running processes that use FOP embedded.
  
 1. Different FOP processes can't be executed in parallel on the same system 
 because creating the same temp file fails.
 2. If the JVM is not normally terminated, the temp files are never deleted 
 and the next invocation of the JVM fails to run.
 3. deleteOnExit() keeps for the life of the JVM an unknown number of temp 
 files both on disk and a reference in memory.
 There should not be a need to implement a custom resource resolver when using 
 FOP embedded in order to fix those issues. The default implementation should 
 work at least as good as it worked in FOP 1.1 or earlier. 
 Attached are 2 patches, one for XGC and one for FOP that should fix and 
 improve the handling of at least the temporary files.
 For reference, [1] lists some reasons for implementing the new URI resource 
 resolvers.
 [1] http://wiki.apache.org/xmlgraphics-fop/URIResolution

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (FOP-2211) [PATCH] Fix improve the handling of temporary files using the new URI resource resolvers

2013-03-12 Thread Alexios Giotis (JIRA)


[ 
https://issues.apache.org/jira/browse/FOP-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13600242#comment-13600242
 ] 

Alexios Giotis commented on FOP-2211:
-

Hi Peter,

Thanks for the patch. In general I find that the current handling of temp 
resources is not optimal but if we don't want to go for bigger changes, this 
patch is an improvement of the current situation. Related to the 3rd point I 
mentioned in the issue description, would you please delete in your patch the 
line  tempFile.deleteOnExit(); ?

Normally, you don't need to do this and it is a memory hog. Have you seen the 
implementation in java.io.DeleteOnExitHook ? Every file is put in a 
LinkedHashSet.




 [PATCH] Fix  improve the handling of temporary files using the new URI 
 resource resolvers
 --

 Key: FOP-2211
 URL: https://issues.apache.org/jira/browse/FOP-2211
 Project: Fop
  Issue Type: Bug
  Components: general
Affects Versions: trunk
Reporter: Alexios Giotis
 Fix For: trunk

 Attachments: fop.patch, fop.patch, tempurisimple.patch, xgc.patch


 As written in http://markmail.org/message/zelumstxxsdyvkcz , after the merge 
 of the Temp_URI_Resolution branch (Sept 2012), the actual pattern of using 
 temp files has changed from:
 {code}
 File tmpFile = File.createTempFile();
 // Write and read from the file
 tmpFile.delete();
 {code}
 to:
 {code}
 File tmpFile = new File(System.getProperty(java.io.tmpdir), 
 counterStartingFrom1AsString);
 tmpFile.deleteOnExit();
 // Write and read from the file
 {code}
 This is fine when FOP is executed from the command line (which I guess this 
 is how most people use it) but it introduces a number of bad side effects for 
 long running processes that use FOP embedded.
  
 1. Different FOP processes can't be executed in parallel on the same system 
 because creating the same temp file fails.
 2. If the JVM is not normally terminated, the temp files are never deleted 
 and the next invocation of the JVM fails to run.
 3. deleteOnExit() keeps for the life of the JVM an unknown number of temp 
 files both on disk and a reference in memory.
 There should not be a need to implement a custom resource resolver when using 
 FOP embedded in order to fix those issues. The default implementation should 
 work at least as good as it worked in FOP 1.1 or earlier. 
 Attached are 2 patches, one for XGC and one for FOP that should fix and 
 improve the handling of at least the temporary files.
 For reference, [1] lists some reasons for implementing the new URI resource 
 resolvers.
 [1] http://wiki.apache.org/xmlgraphics-fop/URIResolution

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (FOP-2211) [PATCH] Fix improve the handling of temporary files using the new URI resource resolvers

2013-03-05 Thread Alexios Giotis (JIRA)

[
https://issues.apache.org/jira/browse/FOP-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13593313#comment-13593313
]

Alexios Giotis commented on FOP-2211:
-

Hi Simon,

Thank you for the patch. I looked at it and it does not resolve the issue of
keeping on disk many and big files. In a test we did last week, the temp file
was 100GB and for sure we don't wish to keep such files until the JVM is
normally terminated. For us, this is several months or a year.

Also, I don't think that backwards compatibility is an issue here. This is
trunk, there are many changes since 1.1 that do affect users embedding FOP in
their apps and this is not one of them. I am sure it will be easy to change
your code or to create an adapter.

I will try to find some time to submit updated versions of the patches that
take into account the comments above.

[PATCH] Fix improve the handling of temporary files using the new URI
resource resolvers
--

Key: FOP-2211
URL: https://issues.apache.org/jira/browse/FOP-2211
Project: Fop
Issue Type: Bug
Components: general
Affects Versions: trunk
Reporter: Alexios Giotis
Fix For: trunk

Attachments: fop.patch, tempurisimple.patch, xgc.patch

[jira] [Commented] (FOP-2211) [PATCH] Fix improve the handling of temporary files using the new URI resource resolvers

2013-02-19 Thread Alexios Giotis (JIRA)

[
https://issues.apache.org/jira/browse/FOP-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13581402#comment-13581402
]

Alexios Giotis commented on FOP-2211:
-

Hi Chris,

I don't understand the advantages of such a virtual file system or why would
anyone need to isolate the *temp* resources of different tenants that are using
a common filesystem. Are you afraid of collision on filenames ? Or that if the
application crashes, the temp files will not be deleted ?

Anyway, that would need going into more details about the use case and the
relevant cloud infrastructure. I will assume that you really have this need. I
will wait a few more days in case the initial authors (Peter and Mehdi) have
some more input. Then, I will update the 2 patches taking under consideration
the comments so far.

[PATCH] Fix improve the handling of temporary files using the new URI
resource resolvers
--

Key: FOP-2211
URL: https://issues.apache.org/jira/browse/FOP-2211
Project: Fop
Issue Type: Bug
Components: general
Affects Versions: trunk
Reporter: Alexios Giotis
Fix For: trunk

Attachments: fop.patch, xgc.patch

[jira] [Commented] (FOP-2211) [PATCH] Fix improve the handling of temporary files using the new URI resource resolvers

2013-02-14 Thread Alexios Giotis (JIRA)

[
https://issues.apache.org/jira/browse/FOP-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13578494#comment-13578494
]

Alexios Giotis commented on FOP-2211:
-

Hi Simon, since DefaultTempResourceResolver and TempAwareResourceResolver are
both private inner classes of ResourceResolverFactory, I guess your are calling
the public static ResourceResolver createTempAwareResourceResolver(). In
that case you are passing an implementation of TempResourceResolver and
another implementation of ResourceResolver. I will wait for some more input
before creating another patch.

In the meantime, it would help to understand why you need to create your own
temp resource handler. There are currently 3 cases for using temp resources.

1. CachedRenderPagesModel which is used if
(userAgent.isConserveMemoryPolicyEnabled()). Trying to conserve memory by
serialising Java objects in memory sounds a bad idea.

2. AFPStream
Writing an AFP document in memory is again questionable. AFP documents are
typically used for printing and to my experience each AFP file contains
thousands of pages (unless this is a test).

3. PSDocumentHandler
This is used to optimise the postscript resources and actually writes the
postscript output firstly in the temp resource and then in normal output
stream. So, it depends on the size of the output.

Which use case are you using ? Is there a measurable difference in performance ?

My experience is that FOP performance is CPU and memory bound, not disk bound.
What is yours ?

[PATCH] Fix improve the handling of temporary files using the new URI
resource resolvers
--

Key: FOP-2211
URL: https://issues.apache.org/jira/browse/FOP-2211
Project: Fop
Issue Type: Bug
Components: general
Affects Versions: trunk
Reporter: Alexios Giotis
Fix For: trunk

Attachments: fop.patch, xgc.patch

[jira] [Commented] (FOP-2211) [PATCH] Fix improve the handling of temporary files using the new URI resource resolvers

2013-02-12 Thread Alexios Giotis (JIRA)

[
https://issues.apache.org/jira/browse/FOP-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13577086#comment-13577086
]

Alexios Giotis commented on FOP-2211:
-

Hi Vincent,

Thanks for your prompt comment. I don't think that the patch prevents anyone
from plugging another implementation keeping files in memory but I also see
that discrepancy. My opinion is indeed that temporary resources should not be
handled through URIs. As you might noticed in the patch, it makes code more
complex. I had to keep a map from the 'unique' tmp URI to the actual unique
file. A non-URI related class handling them could use the
DeferredFileOutputStream [1] of commons-io (an existing FOP dependency). This
stream has a threshold for switching from memory to disk. If there is a need to
customize something besides that threshold, then we could extract another
interface and have a default implementation using such a stream.

If there is a consensus, I could remove the delete() method from the
ResourceResolver and write a new class for handling temp resources (or an
interface if this needs to be configurable). I think it will be better than
switching back to the createTempFile.

[1]
http://commons.apache.org/io/api-1.3/org/apache/commons/io/output/DeferredFileOutputStream.html

[PATCH] Fix improve the handling of temporary files using the new URI
resource resolvers
--

Key: FOP-2211
URL: https://issues.apache.org/jira/browse/FOP-2211
Project: Fop
Issue Type: Bug
Components: general
Affects Versions: trunk
Reporter: Alexios Giotis
Fix For: trunk

Attachments: fop.patch, xgc.patch

[jira] [Commented] (FOP-1840) [PATCH] Region-Body Column balancing incorrect if content is table with header

2012-12-13 Thread Alexios Giotis (JIRA)

[
https://issues.apache.org/jira/browse/FOP-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13530948#comment-13530948
]

Alexios Giotis commented on FOP-1840:
-

Luis Robert thank you for your quick replies patch. Related to the need to
have span=all, you are of course correct...

Related to the balance-4.fo, it was confusing as I put too many spans. I am
attaching balance-5.fo which contains two span=all, one after each table. In
the balance-4-edited.fo.xml, the result was the expected but by removing the
first table. Actually, by just changing by 1mm, the margin-top=206mm, this
problem goes away. I am not sure if this is related to the balancing algorithm
or to roundings.

[PATCH] Region-Body Column balancing incorrect if content is table with header
--

Key: FOP-1840
URL: https://issues.apache.org/jira/browse/FOP-1840
Project: Fop
Issue Type: Improvement
Components: page-master/layout
Affects Versions: 1.0
Environment: Operating System: All
Platform: PC
Reporter: a.kovacs
Assignee: fop-dev
Attachments: b49801_dirty_hack.patch, b49801.fo,
balance-2-expected.pdf, balance-2.fo, balance-2.pdf, balance-3.fo.xml,
balance-4-edited.fo.xml, balance-4.fo.xml, balance-4-none.fo.xml,
balance-4.pdf, balancing-fos.zip, fix.diff, fo.xml, patch.diff,
test-after.pdf, test-before.pdf

To reproduce bug please do the following:
Use:
fo:region-body region-name=PageBody column-count=2 /
Fill the region-body with content like :
fo:block span=none ...(content is table with header) ..
fo:block span=all ... (one line (summary)) ..
If the content is made of normal blocks the columns are balanced before the
span=all summary line.
like:
123456456789
234567567890
345678678901
Summary: 1234567890
If the content is a table without headers the columns are balanced correct.
like:
123456456789
234567567890
345678678901
Summary: 1234567890
If the content is a table with header the columns are not balanced correct.
(the right one is shorter.)
HeaderHeader
123456567890
234567678901
345678
456789
Summary: 1234567890
The computeDemerits() algorithm is wrong in class
BalancingColumnBreakingAlgorithm.
The fullLen value is to short. Exactly the replicated header width is
missing. In the par list the header is contained only once although the
header is displayed in every column. (in the example twice)
Solution could be to place the header as many times in the par list as many
columns exist, or to count the existing one header as many times as needed.

[jira] [Commented] (FOP-1840) [PATCH] Region-Body Column balancing incorrect if content is table with header

2012-12-13 Thread Alexios Giotis (JIRA)

[
https://issues.apache.org/jira/browse/FOP-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13530948#comment-13530948
]

Alexios Giotis commented on FOP-1840:
-

Luis Robert thank you for your quick replies patch. Related to the need to
have span=all, you are of course correct...

[PATCH] Region-Body Column balancing incorrect if content is table with header
--

[jira] [Updated] (FOP-1840) [PATCH] Region-Body Column balancing incorrect if content is table with header

2012-12-13 Thread Alexios Giotis (JIRA)


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

Alexios Giotis updated FOP-1840:


Attachment: balance-5.fo

 [PATCH] Region-Body Column balancing incorrect if content is table with header
 --

 Key: FOP-1840
 URL: https://issues.apache.org/jira/browse/FOP-1840
 Project: Fop
  Issue Type: Improvement
  Components: page-master/layout
Affects Versions: 1.0
 Environment: Operating System: All
 Platform: PC
Reporter: a.kovacs
Assignee: fop-dev
 Attachments: b49801_dirty_hack.patch, b49801.fo, 
 balance-2-expected.pdf, balance-2.fo, balance-2.pdf, balance-3.fo.xml, 
 balance-4-edited.fo.xml, balance-4.fo.xml, balance-4-none.fo.xml, 
 balance-4.pdf, balance-5.fo, balancing-fos.zip, fix.diff, fo.xml, patch.diff, 
 test-after.pdf, test-before.pdf


 To reproduce bug please do the following:
 Use:
 fo:region-body region-name=PageBody column-count=2 /
 Fill the region-body with content like :
 fo:block span=none  ...(content is table with header) ..
 fo:block span=all ... (one line (summary)) ..
 If the content is made of normal blocks the columns are balanced before the 
 span=all summary line.
 like:
 123456456789
 234567567890
 345678678901
 Summary: 1234567890
 If the content is a table without headers the columns are balanced correct. 
 like:
 123456456789
 234567567890
 345678678901
 Summary: 1234567890
 If the content is a table with header the columns are not balanced correct. 
 (the right one is shorter.)
 HeaderHeader
 123456567890
 234567678901
 345678
 456789
 Summary: 1234567890
 The computeDemerits() algorithm is wrong in class 
 BalancingColumnBreakingAlgorithm.
 The fullLen value is to short. Exactly the replicated header width is 
 missing. In the par list the header is contained only once although the 
 header is displayed in every column. (in the example twice)
 Solution could be to place the header as many times in the par list as many 
 columns exist, or to count the existing one header as many times as needed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (FOP-1840) [PATCH] Region-Body Column balancing incorrect if content is table with header

2012-12-13 Thread Alexios Giotis (JIRA)


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

Alexios Giotis updated FOP-1840:


Attachment: balance-5.fo

 [PATCH] Region-Body Column balancing incorrect if content is table with header
 --

 Key: FOP-1840
 URL: https://issues.apache.org/jira/browse/FOP-1840
 Project: Fop
  Issue Type: Improvement
  Components: page-master/layout
Affects Versions: 1.0
 Environment: Operating System: All
 Platform: PC
Reporter: a.kovacs
Assignee: fop-dev
 Attachments: b49801_dirty_hack.patch, b49801.fo, 
 balance-2-expected.pdf, balance-2.fo, balance-2.pdf, balance-3.fo.xml, 
 balance-4-edited.fo.xml, balance-4.fo.xml, balance-4-none.fo.xml, 
 balance-4.pdf, balance-5.fo, balancing-fos.zip, fix.diff, fo.xml, patch.diff, 
 test-after.pdf, test-before.pdf


 To reproduce bug please do the following:
 Use:
 fo:region-body region-name=PageBody column-count=2 /
 Fill the region-body with content like :
 fo:block span=none  ...(content is table with header) ..
 fo:block span=all ... (one line (summary)) ..
 If the content is made of normal blocks the columns are balanced before the 
 span=all summary line.
 like:
 123456456789
 234567567890
 345678678901
 Summary: 1234567890
 If the content is a table without headers the columns are balanced correct. 
 like:
 123456456789
 234567567890
 345678678901
 Summary: 1234567890
 If the content is a table with header the columns are not balanced correct. 
 (the right one is shorter.)
 HeaderHeader
 123456567890
 234567678901
 345678
 456789
 Summary: 1234567890
 The computeDemerits() algorithm is wrong in class 
 BalancingColumnBreakingAlgorithm.
 The fullLen value is to short. Exactly the replicated header width is 
 missing. In the par list the header is contained only once although the 
 header is displayed in every column. (in the example twice)
 Solution could be to place the header as many times in the par list as many 
 columns exist, or to count the existing one header as many times as needed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (FOP-1840) [PATCH] Region-Body Column balancing incorrect if content is table with header

2012-12-12 Thread Alexios Giotis (JIRA)


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

Alexios Giotis updated FOP-1840:


Attachment: balance-3.fo.xml

Nice, with the fix balance-2.fo works as expected. I now wonder why the 2 page 
balance-3.fo.xml is not working. If you comment out the fo:block span=all/ 
near the end of the file, the output is as expected.

I have another case in which the last row at the bottom of the left column is 
missing (empty space). The table ends in the next page. Currently I have a 
screenshot, I am trying to make the 8MB input smaller.

 [PATCH] Region-Body Column balancing incorrect if content is table with header
 --

 Key: FOP-1840
 URL: https://issues.apache.org/jira/browse/FOP-1840
 Project: Fop
  Issue Type: Improvement
  Components: page-master/layout
Affects Versions: 1.0
 Environment: Operating System: All
 Platform: PC
Reporter: a.kovacs
Assignee: fop-dev
 Attachments: b49801_dirty_hack.patch, b49801.fo, 
 balance-2-expected.pdf, balance-2.fo, balance-2.pdf, balance-3.fo.xml, 
 balancing-fos.zip, fix.diff, fo.xml, patch.diff, test-after.pdf, 
 test-before.pdf


 To reproduce bug please do the following:
 Use:
 fo:region-body region-name=PageBody column-count=2 /
 Fill the region-body with content like :
 fo:block span=none  ...(content is table with header) ..
 fo:block span=all ... (one line (summary)) ..
 If the content is made of normal blocks the columns are balanced before the 
 span=all summary line.
 like:
 123456456789
 234567567890
 345678678901
 Summary: 1234567890
 If the content is a table without headers the columns are balanced correct. 
 like:
 123456456789
 234567567890
 345678678901
 Summary: 1234567890
 If the content is a table with header the columns are not balanced correct. 
 (the right one is shorter.)
 HeaderHeader
 123456567890
 234567678901
 345678
 456789
 Summary: 1234567890
 The computeDemerits() algorithm is wrong in class 
 BalancingColumnBreakingAlgorithm.
 The fullLen value is to short. Exactly the replicated header width is 
 missing. In the par list the header is contained only once although the 
 header is displayed in every column. (in the example twice)
 Solution could be to place the header as many times in the par list as many 
 columns exist, or to count the existing one header as many times as needed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (FOP-1840) [PATCH] Region-Body Column balancing incorrect if content is table with header

2012-12-12 Thread Alexios Giotis (JIRA)

[
https://issues.apache.org/jira/browse/FOP-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13530111#comment-13530111
]

Alexios Giotis edited comment on FOP-1840 at 12/12/12 5:03 PM:
---

Nice, with the fix balance-2.fo works as expected. I now wonder why the 2nd
page of the attached balance-3.fo.xml is not working. If you comment out the
fo:block span=all/ near the end of the file, the output is as expected.

I also have another case in which the last row at the bottom of the left column
is missing (empty space). The table ends in the next page. Currently I have a
screenshot, I am trying to make the 8MB input smaller.

was (Author: alex.giotis):
Nice, with the fix balance-2.fo works as expected. I now wonder why the 2
page balance-3.fo.xml is not working. If you comment out the fo:block
span=all/ near the end of the file, the output is as expected.

I have another case in which the last row at the bottom of the left column is
missing (empty space). The table ends in the next page. Currently I have a
screenshot, I am trying to make the 8MB input smaller.

[PATCH] Region-Body Column balancing incorrect if content is table with header
--

Key: FOP-1840
URL: https://issues.apache.org/jira/browse/FOP-1840
Project: Fop
Issue Type: Improvement
Components: page-master/layout
Affects Versions: 1.0
Environment: Operating System: All
Platform: PC
Reporter: a.kovacs
Assignee: fop-dev
Attachments: b49801_dirty_hack.patch, b49801.fo,
balance-2-expected.pdf, balance-2.fo, balance-2.pdf, balance-3.fo.xml,
balancing-fos.zip, fix.diff, fo.xml, patch.diff, test-after.pdf,
test-before.pdf

[jira] [Comment Edited] (FOP-1840) [PATCH] Region-Body Column balancing incorrect if content is table with header

2012-12-12 Thread Alexios Giotis (JIRA)

[
https://issues.apache.org/jira/browse/FOP-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13530111#comment-13530111
]

Alexios Giotis edited comment on FOP-1840 at 12/12/12 5:03 PM:
---

[PATCH] Region-Body Column balancing incorrect if content is table with header
--

Key: FOP-1840
URL: https://issues.apache.org/jira/browse/FOP-1840
Project: Fop
Issue Type: Improvement
Components: page-master/layout
Affects Versions: 1.0
Environment: Operating System: All
Platform: PC
Reporter: a.kovacs
Assignee: fop-dev
Attachments: b49801_dirty_hack.patch, b49801.fo,
balance-2-expected.pdf, balance-2.fo, balance-2.pdf, balance-3.fo.xml,
balancing-fos.zip, fix.diff, fo.xml, patch.diff, test-after.pdf,
test-before.pdf

[jira] [Updated] (FOP-1840) [PATCH] Region-Body Column balancing incorrect if content is table with header

2012-12-12 Thread Alexios Giotis (JIRA)


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

Alexios Giotis updated FOP-1840:


Attachment: balance-4.pdf
balance-4.fo.xml

balance-4.fo.xml is the problem I mentioned before. Check the gap after the 
last row of the left column of the first page.

 [PATCH] Region-Body Column balancing incorrect if content is table with header
 --

 Key: FOP-1840
 URL: https://issues.apache.org/jira/browse/FOP-1840
 Project: Fop
  Issue Type: Improvement
  Components: page-master/layout
Affects Versions: 1.0
 Environment: Operating System: All
 Platform: PC
Reporter: a.kovacs
Assignee: fop-dev
 Attachments: b49801_dirty_hack.patch, b49801.fo, 
 balance-2-expected.pdf, balance-2.fo, balance-2.pdf, balance-3.fo.xml, 
 balance-4.fo.xml, balance-4.pdf, balancing-fos.zip, fix.diff, fo.xml, 
 patch.diff, test-after.pdf, test-before.pdf


 To reproduce bug please do the following:
 Use:
 fo:region-body region-name=PageBody column-count=2 /
 Fill the region-body with content like :
 fo:block span=none  ...(content is table with header) ..
 fo:block span=all ... (one line (summary)) ..
 If the content is made of normal blocks the columns are balanced before the 
 span=all summary line.
 like:
 123456456789
 234567567890
 345678678901
 Summary: 1234567890
 If the content is a table without headers the columns are balanced correct. 
 like:
 123456456789
 234567567890
 345678678901
 Summary: 1234567890
 If the content is a table with header the columns are not balanced correct. 
 (the right one is shorter.)
 HeaderHeader
 123456567890
 234567678901
 345678
 456789
 Summary: 1234567890
 The computeDemerits() algorithm is wrong in class 
 BalancingColumnBreakingAlgorithm.
 The fullLen value is to short. Exactly the replicated header width is 
 missing. In the par list the header is contained only once although the 
 header is displayed in every column. (in the example twice)
 Solution could be to place the header as many times in the par list as many 
 columns exist, or to count the existing one header as many times as needed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (FOP-1840) [PATCH] Region-Body Column balancing incorrect if content is table with header

2012-12-11 Thread Alexios Giotis (JIRA)

[
https://issues.apache.org/jira/browse/FOP-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13529137#comment-13529137
]

Alexios Giotis commented on FOP-1840:
-

The algorithm seems broken when the content is more than one page. I am
attaching a 2 page XSL:FO (balance-2.fo), the actual PDF output using trunk
revision=1419183 (balance-2.pdf) and the expected PDF output
(balance-2-expected.pdf). For the latter, I used the dirty hack I have attached
on this issue.

[PATCH] Region-Body Column balancing incorrect if content is table with header
--

[jira] [Commented] (FOP-1840) [PATCH] Region-Body Column balancing incorrect if content is table with header

2012-12-11 Thread Alexios Giotis (JIRA)

[
https://issues.apache.org/jira/browse/FOP-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13529137#comment-13529137
]

Alexios Giotis commented on FOP-1840:
-

[PATCH] Region-Body Column balancing incorrect if content is table with header
--

[jira] [Updated] (FOP-1840) [PATCH] Region-Body Column balancing incorrect if content is table with header

2012-12-11 Thread Alexios Giotis (JIRA)


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

Alexios Giotis updated FOP-1840:


Attachment: balance-2-expected.pdf
balance-2.pdf
balance-2.fo

 [PATCH] Region-Body Column balancing incorrect if content is table with header
 --

 Key: FOP-1840
 URL: https://issues.apache.org/jira/browse/FOP-1840
 Project: Fop
  Issue Type: Improvement
  Components: page-master/layout
Affects Versions: 1.0
 Environment: Operating System: All
 Platform: PC
Reporter: a.kovacs
Assignee: fop-dev
 Attachments: b49801_dirty_hack.patch, b49801.fo, 
 balance-2-expected.pdf, balance-2.fo, balance-2.pdf, balancing-fos.zip, 
 fo.xml, patch.diff, test-after.pdf, test-before.pdf


 To reproduce bug please do the following:
 Use:
 fo:region-body region-name=PageBody column-count=2 /
 Fill the region-body with content like :
 fo:block span=none  ...(content is table with header) ..
 fo:block span=all ... (one line (summary)) ..
 If the content is made of normal blocks the columns are balanced before the 
 span=all summary line.
 like:
 123456456789
 234567567890
 345678678901
 Summary: 1234567890
 If the content is a table without headers the columns are balanced correct. 
 like:
 123456456789
 234567567890
 345678678901
 Summary: 1234567890
 If the content is a table with header the columns are not balanced correct. 
 (the right one is shorter.)
 HeaderHeader
 123456567890
 234567678901
 345678
 456789
 Summary: 1234567890
 The computeDemerits() algorithm is wrong in class 
 BalancingColumnBreakingAlgorithm.
 The fullLen value is to short. Exactly the replicated header width is 
 missing. In the par list the header is contained only once although the 
 header is displayed in every column. (in the example twice)
 Solution could be to place the header as many times in the par list as many 
 columns exist, or to count the existing one header as many times as needed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (FOP-1840) [PATCH] Region-Body Column balancing incorrect if content is table with header

2012-12-11 Thread Alexios Giotis (JIRA)


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

Alexios Giotis updated FOP-1840:


Attachment: balance-2-expected.pdf
balance-2.pdf
balance-2.fo

 [PATCH] Region-Body Column balancing incorrect if content is table with header
 --

 Key: FOP-1840
 URL: https://issues.apache.org/jira/browse/FOP-1840
 Project: Fop
  Issue Type: Improvement
  Components: page-master/layout
Affects Versions: 1.0
 Environment: Operating System: All
 Platform: PC
Reporter: a.kovacs
Assignee: fop-dev
 Attachments: b49801_dirty_hack.patch, b49801.fo, 
 balance-2-expected.pdf, balance-2.fo, balance-2.pdf, balancing-fos.zip, 
 fo.xml, patch.diff, test-after.pdf, test-before.pdf


 To reproduce bug please do the following:
 Use:
 fo:region-body region-name=PageBody column-count=2 /
 Fill the region-body with content like :
 fo:block span=none  ...(content is table with header) ..
 fo:block span=all ... (one line (summary)) ..
 If the content is made of normal blocks the columns are balanced before the 
 span=all summary line.
 like:
 123456456789
 234567567890
 345678678901
 Summary: 1234567890
 If the content is a table without headers the columns are balanced correct. 
 like:
 123456456789
 234567567890
 345678678901
 Summary: 1234567890
 If the content is a table with header the columns are not balanced correct. 
 (the right one is shorter.)
 HeaderHeader
 123456567890
 234567678901
 345678
 456789
 Summary: 1234567890
 The computeDemerits() algorithm is wrong in class 
 BalancingColumnBreakingAlgorithm.
 The fullLen value is to short. Exactly the replicated header width is 
 missing. In the par list the header is contained only once although the 
 header is displayed in every column. (in the example twice)
 Solution could be to place the header as many times in the par list as many 
 columns exist, or to count the existing one header as many times as needed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (FOP-2968) ValidationException: fo:table-row is missing child elements

[jira] [Commented] (FOP-2968) ValidationException: fo:table-row is missing child elements

[jira] [Commented] (FOP-2968) ValidationException: fo:table-row is missing child elements

[jira] [Commented] (FOP-2917) Superscript / sub script shifted to the next character

[jira] [Commented] (FOP-2581) [PATCH] NumberFormatException when page-sequence format can't be parsed as an Integer

[jira] [Updated] (FOP-2581) [PATCH] NumberFormatException when page-sequence format can't be parsed as an Integer

[jira] [Updated] (FOP-2581) NumberFormatException when page-sequence format can't be parsed as an Integer

[jira] [Updated] (FOP-2581) [PATCH] NumberFormatException when page-sequence format can't be parsed as an Integer

[jira] [Updated] (FOP-2581) NumberFormatException when page-sequence format can't be parsed as an Integer

[jira] [Created] (FOP-2581) NumberFormatException when page-sequence format can't be parsed as an Integer

[jira] [Resolved] (FOP-2400) HashCode collisions

[jira] [Updated] (FOP-2307) Weird border color inheritance (hashCode collisions)

[jira] [Updated] (FOP-2307) [PATCH] Weird border color inheritance (hashCode collisions)

[jira] [Updated] (FOP-2307) [PATCH] Weird border color inheritance (hashCode collisions)

[jira] [Commented] (FOP-2157) Deadlock in CompareUtil class

[jira] [Commented] (FOP-2307) Weird border color inheritance (hashCode collisions)

[jira] [Commented] (FOP-2307) Weird border color inheritance (hashCode collisions)

[jira] [Commented] (FOP-2211) [PATCH] Fix improve the handling of temporary files using the new URI resource resolvers

[jira] [Commented] (FOP-2211) [PATCH] Fix improve the handling of temporary files using the new URI resource resolvers

[jira] [Commented] (FOP-2211) [PATCH] Fix improve the handling of temporary files using the new URI resource resolvers

[jira] [Commented] (FOP-2211) [PATCH] Fix improve the handling of temporary files using the new URI resource resolvers

[jira] [Commented] (FOP-2211) [PATCH] Fix improve the handling of temporary files using the new URI resource resolvers

[jira] [Commented] (FOP-2211) [PATCH] Fix improve the handling of temporary files using the new URI resource resolvers

[jira] [Commented] (FOP-2211) [PATCH] Fix improve the handling of temporary files using the new URI resource resolvers

[jira] [Commented] (FOP-1840) [PATCH] Region-Body Column balancing incorrect if content is table with header

[jira] [Commented] (FOP-1840) [PATCH] Region-Body Column balancing incorrect if content is table with header

[jira] [Updated] (FOP-1840) [PATCH] Region-Body Column balancing incorrect if content is table with header

[jira] [Updated] (FOP-1840) [PATCH] Region-Body Column balancing incorrect if content is table with header

[jira] [Updated] (FOP-1840) [PATCH] Region-Body Column balancing incorrect if content is table with header

[jira] [Comment Edited] (FOP-1840) [PATCH] Region-Body Column balancing incorrect if content is table with header

[jira] [Comment Edited] (FOP-1840) [PATCH] Region-Body Column balancing incorrect if content is table with header

[jira] [Updated] (FOP-1840) [PATCH] Region-Body Column balancing incorrect if content is table with header

[jira] [Commented] (FOP-1840) [PATCH] Region-Body Column balancing incorrect if content is table with header

[jira] [Commented] (FOP-1840) [PATCH] Region-Body Column balancing incorrect if content is table with header

[jira] [Updated] (FOP-1840) [PATCH] Region-Body Column balancing incorrect if content is table with header

[jira] [Updated] (FOP-1840) [PATCH] Region-Body Column balancing incorrect if content is table with header

36 matches

Site Navigation

Mail list logo

Footer information