[jira] [Commented] (FOP-2602) block content of list-item overlaps next list-item content
[ https://issues.apache.org/jira/browse/FOP-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15932358#comment-15932358 ] Pascal Sancho commented on FOP-2602: what about replacing fo:inline with fo:wrapper? > block content of list-item overlaps next list-item content > -- > > Key: FOP-2602 > URL: https://issues.apache.org/jira/browse/FOP-2602 > Project: FOP > Issue Type: Bug > Components: fo/block, fo/inline >Affects Versions: 1.1, 2.1 > Environment: server: Linux centOS >Reporter: Nico Krupp > Fix For: trunk, 2.1 > > Attachments: bleeding-list-item.png, fo.xml > > > The block content of a list-item-body inside a list-item, is overlapping the > content of the next list-item, when getting wrapped. > I am glad to provide additional information if needed, but for me it seems > that simple. > E.g.: fo.xml and bleeding-list-item.png -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (FOP-2660) Cannot add cropped pdf as fo:external-graphic
[ https://issues.apache.org/jira/browse/FOP-2660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15643550#comment-15643550 ] Pascal Sancho edited comment on FOP-2660 at 11/7/16 8:58 AM: - this is probably related to prepress concern. Cf. FOP-1742 was (Author: psancho): Probably related issue > Cannot add cropped pdf as fo:external-graphic > -- > > Key: FOP-2660 > URL: https://issues.apache.org/jira/browse/FOP-2660 > Project: FOP > Issue Type: Bug > Components: image/unqualified >Affects Versions: trunk > Environment: Windows 10, FOP r1768353, FOP PDF Images plugin 2.1.0 >Reporter: John Brown > Attachments: lorem.pdf, lorem_cropped.pdf, test.fo, test.pdf > > > My original pdf (created by printing to PDF Creator > (http://www.pdfforge.org/pdfcreator) works as an external graphic in > test.fo. This PDF has 1-inch borders which I removed using Briss > (http://briss.sourceforge.net/). The cropped PDF image is not displayed in > test.pdf. I think that it is present but invisible because when I look at the > document's properties (Fonts), I see two fonts but lorem_cropped.pdf has > 1 font. > To reproduce: > > > http://www.w3.org/1999/XSL/Format;> > > page-width="21.0cm" margin="2cm"> > > > > > > > Hello, World! > > > > > > > > > lorem.pdf is a "Lorem ipsum" paragraph printed to PDF Creator on letter > size paper. > lorem_cropped.pdf is lorem.pdf cropped to contain just the paragraph > with minimal whitespace. > test.pdf is the output of > C:\>fop test.fo test.pdf > I am using fop SVN r1768353 (2016-10-20 17:03:59 -0500) and the fop > PDF Images plugin from > https://dist.apache.org/repos/dist/dev/xmlgraphics/binaries/ on > Windows 10. > You also need the input PDFs. How do I send them to you? > Regards, > John Brown. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2660) Cannot add cropped pdf as fo:external-graphic
[ https://issues.apache.org/jira/browse/FOP-2660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15643550#comment-15643550 ] Pascal Sancho commented on FOP-2660: Probably related issue > Cannot add cropped pdf as fo:external-graphic > -- > > Key: FOP-2660 > URL: https://issues.apache.org/jira/browse/FOP-2660 > Project: FOP > Issue Type: Bug > Components: image/unqualified >Affects Versions: trunk > Environment: Windows 10, FOP r1768353, FOP PDF Images plugin 2.1.0 >Reporter: John Brown > Attachments: lorem.pdf, lorem_cropped.pdf, test.fo, test.pdf > > > My original pdf (created by printing to PDF Creator > (http://www.pdfforge.org/pdfcreator) works as an external graphic in > test.fo. This PDF has 1-inch borders which I removed using Briss > (http://briss.sourceforge.net/). The cropped PDF image is not displayed in > test.pdf. I think that it is present but invisible because when I look at the > document's properties (Fonts), I see two fonts but lorem_cropped.pdf has > 1 font. > To reproduce: > > > http://www.w3.org/1999/XSL/Format;> > > page-width="21.0cm" margin="2cm"> > > > > > > > Hello, World! > > > > > > > > > lorem.pdf is a "Lorem ipsum" paragraph printed to PDF Creator on letter > size paper. > lorem_cropped.pdf is lorem.pdf cropped to contain just the paragraph > with minimal whitespace. > test.pdf is the output of > C:\>fop test.fo test.pdf > I am using fop SVN r1768353 (2016-10-20 17:03:59 -0500) and the fop > PDF Images plugin from > https://dist.apache.org/repos/dist/dev/xmlgraphics/binaries/ on > Windows 10. > You also need the input PDFs. How do I send them to you? > Regards, > John Brown. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2616) Extra blank page gets created even though the content fits in previous page
[ https://issues.apache.org/jira/browse/FOP-2616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15355187#comment-15355187 ] Pascal Sancho commented on FOP-2616: see menu under [More] button above. > Extra blank page gets created even though the content fits in previous page > --- > > Key: FOP-2616 > URL: https://issues.apache.org/jira/browse/FOP-2616 > Project: FOP > Issue Type: Bug > Environment: windows 7, Java 1.8 >Reporter: Ramnikunj Prajapati > > Hi, > We are creating a pdf out of a xml using xsl and FOP library. We have set > header and footer for all pages. We have a coupon which needs to be > positioned at the bottom of last page of pdf and when the coupon is in the > bottom the footer text should not appear. If the data in the current page is > more to accommodate in one page than the extra data and coupon should be > shifted to the next page. The condition for coupon is that it should always > be placed in bottom of last page. We found an issue where if the data in the > body is about 36-39 lines which fits the current page with coupon still an > extra blank page gets added with the header. > For reference please check the xsl, sample xml and pdf which is placed in > this google drive folder: https://goo.gl/4Pwqev Please read the readme file > for more info -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2616) Extra blank page gets created even though the content fits in previous page
[ https://issues.apache.org/jira/browse/FOP-2616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15352564#comment-15352564 ] Pascal Sancho commented on FOP-2616: Please, further info is needed: - provide an XSL-FO file, rather than a xml+xslt pair, as short as possible, reproducing the issue - FOP version - attach files (XSL-FO and PDF) to the issue rather than an external link. > Extra blank page gets created even though the content fits in previous page > --- > > Key: FOP-2616 > URL: https://issues.apache.org/jira/browse/FOP-2616 > Project: FOP > Issue Type: Bug > Environment: windows 7, Java 1.8 >Reporter: Ramnikunj Prajapati > > Hi, > We are creating a pdf out of a xml using xsl and FOP library. We have set > header and footer for all pages. We have a coupon which needs to be > positioned at the bottom of last page of pdf and when the coupon is in the > bottom the footer text should not appear. If the data in the current page is > more to accommodate in one page than the extra data and coupon should be > shifted to the next page. The condition for coupon is that it should always > be placed in bottom of last page. We found an issue where if the data in the > body is about 36-39 lines which fits the current page with coupon still an > extra blank page gets added with the header. > For reference please check the xsl, sample xml and pdf which is placed in > this google drive folder: https://goo.gl/4Pwqev Please read the readme file > for more info -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2569) Exception in thread "main" java.lang.StackOverflowError at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244)
[ https://issues.apache.org/jira/browse/FOP-2569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15131931#comment-15131931 ] Pascal Sancho commented on FOP-2569: OFFO is inactive since 2014, when its author has retired (Cf. [1]). If someone want to help, he certainly will be welcome. [1] http://marc.info/?l=fop-user=138970128225158=2 > Exception in thread "main" java.lang.StackOverflowError at > org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > -- > > Key: FOP-2569 > URL: https://issues.apache.org/jira/browse/FOP-2569 > Project: FOP > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Mathieu Malaterre > Fix For: 1.1 > > > fop + offo is broken since release 2.0 (and 2.1). It used to be possible to > build fop-hyph.jar using fop 1.1. Please resurrect a working hyph building > mechanism. > Here is what it states: > $ /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java -Xss512k -classpath > /home/mathieu/debian/fop/fop-2.1/build/classes > org.apache.fop.hyphenation.SerializeHyphPattern > /home/mathieu/debian/fop/fop-2.1/hyph > /home/mathieu/debian/fop/fop-2.1/build/classes/hyph > Processing /home/mathieu/debian/fop/fop-2.1/hyph/sa.xml > Exception in thread "main" java.lang.StackOverflowError > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > [...] > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > See thread: > http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-users/201602.mbox/%3CCA%2B7wUszWN2PdZY_t_Kgn0E4eatL7CUQswOWj9XC%3Dg9GDdgsyXw%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2571) display is not correct
[ https://issues.apache.org/jira/browse/FOP-2571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15131984#comment-15131984 ] Pascal Sancho commented on FOP-2571: This is not reproducible with FOP 2.x Since there is no maintenance branch for FOP 1.x, I encourage you to upgrade to latest FOP version. > display is not correct > - > > Key: FOP-2571 > URL: https://issues.apache.org/jira/browse/FOP-2571 > Project: FOP > Issue Type: Bug >Affects Versions: 1.1 >Reporter: LiuChuanming > Attachments: 1.fo, 1.pdf > > > Using FOP1.1, generatedPDF by fo. > within the tag, not break page, > some data is not displayed. > Reference： 1.fo and 1.pdf -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2520) Empty elements consume space
[
https://issues.apache.org/jira/browse/FOP-2520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14716732#comment-14716732
]
Pascal Sancho commented on FOP-2520:
All text nodes are processed by FOP, this is the correct behaviour.
If you want to discard spaces, you have to 1st do it at XSLT stage:
- avoid indentation
- do not add unwanted extra white spaces (including linefeed)
- etc.
At FOP stage, you may interact on white spaces using following FO properties:
- linefeed-treatment (http://www.w3.org/TR/xsl/#linefeed-treatment)
- white-space-treatment (http://www.w3.org/TR/xsl/#white-space-treatment)
- white-space-collapse (http://www.w3.org/TR/xsl/#white-space-treatment)
That said, Jira is not the right place to discuss about this.
either fop-users mailing list, or better XSLT/XSL-FO mailing lists, are more
appropriate.
Audience on such lists is larger.
Empty elements consume space
Key: FOP-2520
URL: https://issues.apache.org/jira/browse/FOP-2520
Project: FOP
Issue Type: Bug
Affects Versions: 2.0
Reporter: Björn Kautler
Attachments: empty space that should not be there.png
If you use {{indexterm}} tags in DocBook, the DocBook XSL stylesheets
generate empty {{fo:wrapper}} or {{fo:block}} elements with an {{id}}
attribute. These elements take up visible space if processed with FOP. Using
XEP, those empty tags do not consume any space.
Here an example excerpt from a FO file in question and [attached|^empty space
that should not be there.png] the result.
{code:xml}
fo:block space-before.optimum=0.6em space-before.minimum=0.4em
space-before.maximum=0.8em
fo:wrapper id=N1004F!--table, customize columns--/fo:wrapper
fo:wrapper id=N10056!--customize, table--/fo:wrapper
fo:wrapper id=N1005D!--filter, table--/fo:wrapper
fo:wrapper id=N10064!--table, filter--/fo:wrapperYou can customize
most tables in the product. The configured table view is saved in your user
profile and will be restored when you start the prouct the next time.
/fo:block
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (FOP-2520) Empty elements consume space
[
https://issues.apache.org/jira/browse/FOP-2520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Sancho closed FOP-2520.
--
Resolution: Invalid
Hi,
text nodes are taken into account by both FOP and XEP.
if you want to discard spaces, you have to do it by yourself at XSLT stage,
depending on what XSLT engine (and options) you are using (FOP comes with Xalan
for convenience, but your may use your own).
As a good practice, you should not mix text nodes and FO elements in your XSLT
template, this prevent Xalan (or other) to keep blank text nodes in final
XSL-FO:
use an xsl:text to wrap the text You can customize ... the next time., and
all blank text nodes will magically disappear.
Empty elements consume space
Key: FOP-2520
URL: https://issues.apache.org/jira/browse/FOP-2520
Project: FOP
Issue Type: Bug
Affects Versions: 2.0
Reporter: Björn Kautler
Attachments: empty space that should not be there.png
If you use {{indexterm}} tags in DocBook, the DocBook XSL stylesheets
generate empty {{fo:wrapper}} or {{fo:block}} elements with an {{id}}
attribute. These elements take up visible space if processed with FOP. Using
XEP, those empty tags do not consume any space.
Here an example excerpt from a FO file in question and [attached|^empty space
that should not be there.png] the result.
{code:xml}
fo:block space-before.optimum=0.6em space-before.minimum=0.4em
space-before.maximum=0.8em
fo:wrapper id=N1004F!--table, customize columns--/fo:wrapper
fo:wrapper id=N10056!--customize, table--/fo:wrapper
fo:wrapper id=N1005D!--filter, table--/fo:wrapper
fo:wrapper id=N10064!--table, filter--/fo:wrapperYou can customize
most tables in the product. The configured table view is saved in your user
profile and will be restored when you start the prouct the next time.
/fo:block
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FOP-2518) NullPointerException
[
https://issues.apache.org/jira/browse/FOP-2518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14710934#comment-14710934
]
Pascal Sancho commented on FOP-2518:
Please,
provide further info:
attached XSL-FO file (resulting from XML+XSLT transformation).
Without such material, it's impossible to reproduce the issue.
NullPointerException
Key: FOP-2518
URL: https://issues.apache.org/jira/browse/FOP-2518
Project: FOP
Issue Type: Bug
Affects Versions: 2.0
Reporter: Björn Kautler
Priority: Blocker
FOP throws the following NPE when trying to transform a DocBook document to
PDF:
{noformat}
Caused by: java.lang.NullPointerException
at
org.apache.fop.layoutmgr.list.ListItemLayoutManager.getCombinedKnuthElementsForListItem(ListItemLayoutManager.java:405)
at
org.apache.fop.layoutmgr.list.ListItemLayoutManager.getNextKnuthElements(ListItemLayoutManager.java:326)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:239)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextChildElements(BlockStackingLayoutManager.java:498)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:289)
at
org.apache.fop.layoutmgr.list.ListBlockLayoutManager.getNextKnuthElements(ListBlockLayoutManager.java:103)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:239)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextChildElements(BlockLayoutManager.java:141)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:289)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:113)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:105)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextChildElements(BlockLayoutManager.java:141)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:289)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:113)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:105)
at
org.apache.fop.layoutmgr.FlowLayoutManager.getNextChildElements(FlowLayoutManager.java:223)
at
org.apache.fop.layoutmgr.FlowLayoutManager.addChildElements(FlowLayoutManager.java:147)
at
org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:116)
at
org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:69)
at
org.apache.fop.layoutmgr.PageBreaker.getNextKnuthElements(PageBreaker.java:252)
at
org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker.java:643)
at
org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:178)
at
org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:158)
at
org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:384)
at org.apache.fop.layoutmgr.PageBreaker.doLayout(PageBreaker.java:112)
at
org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:138)
at
org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:267)
at
org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:130)
at
org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:360)
at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:190)
at
org.apache.xalan.transformer.TransformerIdentityImpl.endElement(TransformerIdentityImpl.java:1102)
at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown
Source)
at
org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(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.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:485)
at
[jira] [Resolved] (FOP-2518) NullPointerException
[
https://issues.apache.org/jira/browse/FOP-2518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Sancho resolved FOP-2518.
Resolution: Duplicate
I've just seen the duplicate link, so I resolve it as duplicate.
Please, you can add comment directly on FOP-2461 if needed
NullPointerException
Key: FOP-2518
URL: https://issues.apache.org/jira/browse/FOP-2518
Project: FOP
Issue Type: Bug
Affects Versions: 2.0
Reporter: Björn Kautler
Priority: Blocker
FOP throws the following NPE when trying to transform a DocBook document to
PDF:
{noformat}
Caused by: java.lang.NullPointerException
at
org.apache.fop.layoutmgr.list.ListItemLayoutManager.getCombinedKnuthElementsForListItem(ListItemLayoutManager.java:405)
at
org.apache.fop.layoutmgr.list.ListItemLayoutManager.getNextKnuthElements(ListItemLayoutManager.java:326)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:239)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextChildElements(BlockStackingLayoutManager.java:498)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:289)
at
org.apache.fop.layoutmgr.list.ListBlockLayoutManager.getNextKnuthElements(ListBlockLayoutManager.java:103)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:239)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextChildElements(BlockLayoutManager.java:141)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:289)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:113)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:105)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextChildElements(BlockLayoutManager.java:141)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:289)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:113)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:105)
at
org.apache.fop.layoutmgr.FlowLayoutManager.getNextChildElements(FlowLayoutManager.java:223)
at
org.apache.fop.layoutmgr.FlowLayoutManager.addChildElements(FlowLayoutManager.java:147)
at
org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:116)
at
org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:69)
at
org.apache.fop.layoutmgr.PageBreaker.getNextKnuthElements(PageBreaker.java:252)
at
org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker.java:643)
at
org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:178)
at
org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:158)
at
org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:384)
at org.apache.fop.layoutmgr.PageBreaker.doLayout(PageBreaker.java:112)
at
org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:138)
at
org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:267)
at
org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:130)
at
org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:360)
at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:190)
at
org.apache.xalan.transformer.TransformerIdentityImpl.endElement(TransformerIdentityImpl.java:1102)
at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown
Source)
at
org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(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.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:485)
at
org.apache.xalan.transformer.TransformerIdentityImpl$transform.call(Unknown
[jira] [Commented] (FOP-2517) keep-together.within-page=auto is not work,but the always is work.
[ https://issues.apache.org/jira/browse/FOP-2517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709002#comment-14709002 ] Pascal Sancho commented on FOP-2517: If you want some help, you have to provide usable example and explicit test case. Without such material, FOP team can just infer the issue in a way that can be wrong. Please, attach FO file, PDF files you get with, and describe precisely what you expect. keep-together.within-page=auto is not work,but the always is work. -- Key: FOP-2517 URL: https://issues.apache.org/jira/browse/FOP-2517 Project: FOP Issue Type: Wish Reporter: zhangcui i am use Transformer to convert xml to pdf,the src is FopFactory fF = FopFactory.newInstance(); fF.setUserConfig(..); fF.getFontManager().setFontBaseURL(..); FOUserAgent foUserAgent = fopFactory.newFOUserAgent(); Fop fop = fopFactory.newFop(MimeConstants.MIME_PDF, foUserAgent,out); Result result = new SAXResult(fop.getDefaultHandler()); TransformerFactory tFactory = TransformerFactory.newInstance(); Transformer transformer = tFactory.newTransformer(new StreamSource(xslReader)); transformer.setParameter(tt, paramPath); transformer.transform(xmlSource, result); the xsl is xsl:element name=fo:table-row xsl:attribute name=keep-together.within-page xsl:value-of select=auto/xsl:value-of /xsl:attribute /xsl:element but it's not work.but if i change it to always,it work. why? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2517) keep-together.within-page=auto is not work,but the always is work.
[ https://issues.apache.org/jira/browse/FOP-2517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14706355#comment-14706355 ] Pascal Sancho commented on FOP-2517: Hi, what do you mean by it's not work? please, give further info: FOP version what you expect Vs what you get short XSL-FO (not XSLT) test case attached as files keep-together.within-page=auto is not work,but the always is work. -- Key: FOP-2517 URL: https://issues.apache.org/jira/browse/FOP-2517 Project: FOP Issue Type: Wish Reporter: zhangcui i am use Transformer to convert xml to pdf,the src is FopFactory fF = FopFactory.newInstance(); fF.setUserConfig(..); fF.getFontManager().setFontBaseURL(..); FOUserAgent foUserAgent = fopFactory.newFOUserAgent(); Fop fop = fopFactory.newFop(MimeConstants.MIME_PDF, foUserAgent,out); Result result = new SAXResult(fop.getDefaultHandler()); TransformerFactory tFactory = TransformerFactory.newInstance(); Transformer transformer = tFactory.newTransformer(new StreamSource(xslReader)); transformer.setParameter(tt, paramPath); transformer.transform(xmlSource, result); the xsl is xsl:element name=fo:table-row xsl:attribute name=keep-together.within-page xsl:value-of select=auto/xsl:value-of /xsl:attribute /xsl:element but it's not work.but if i change it to always,it work. why? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2513) First element must be the fo:root formatting object
[ https://issues.apache.org/jira/browse/FOP-2513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14699095#comment-14699095 ] Pascal Sancho commented on FOP-2513: I guess you fed FOP directly with your XML. FOP expects XSL-FO as input. As a convenience, FOP dist provides Xalan, an XSLT engine, letting you to feed FOP with both XML and XSLT; this transformation is completed before feeding FOP internally with the resulting XSL-FO. If I guess wrong, please give further info, if I'm right, please close the issue. First element must be the fo:root formatting object --- Key: FOP-2513 URL: https://issues.apache.org/jira/browse/FOP-2513 Project: FOP Issue Type: Bug Affects Versions: 2.0 Reporter: Mathieu Malaterre With: $ cat in.xml /tmp ?xml version=1.0 encoding=UTF-8? !DOCTYPE article PUBLIC -//OASIS//DTD DocBook XML V4.5//EN http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd; article articleinfo titletitle/title author firstnameauthor/firstname surnameauthor2/surname affiliation orgnamebla/orgname /affiliation /author pubdate2001/pubdate /articleinfo section titlesection 1/title paratext section 1/para figure titlefirst/title mediaobject imageobject imagedata fileref=openlogo-100.png/ /imageobject /mediaobject /figure /section /article and: $ wget http://www.debian.org/logos/openlogo-100.png here is what I get: $ fop in.xml in.pdf [ERROR] FOP - Exception org.apache.fop.apps.FOPException: org.apache.fop.fo.ValidationException: First element must be the fo:root formatting object. Found (Namespace URI: , Local Name: article) instead. Please make sure you're producing a valid XSL-FO document. javax.xml.transform.TransformerException: org.apache.fop.fo.ValidationException: First element must be the fo:root formatting object. Found (Namespace URI: , Local Name: article) instead. Please make sure you're producing a valid XSL-FO document.org.apache.fop.apps.FOPException: org.apache.fop.fo.ValidationException: First element must be the fo:root formatting object. Found (Namespace URI: , Local Name: article) instead. Please make sure you're producing a valid XSL-FO document. javax.xml.transform.TransformerException: org.apache.fop.fo.ValidationException: First element must be the fo:root formatting object. Found (Namespace URI: , Local Name: article) instead. Please make sure you're producing a valid XSL-FO document. at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:288) at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:115) at org.apache.fop.cli.Main.startFOP(Main.java:186) at org.apache.fop.cli.Main.main(Main.java:217) Caused by: javax.xml.transform.TransformerException: org.apache.fop.fo.ValidationException: First element must be the fo:root formatting object. Found (Namespace URI: , Local Name: article) instead. Please make sure you're producing a valid XSL-FO document. at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:502) at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:285) ... 3 more Caused by: org.apache.fop.fo.ValidationException: First element must be the fo:root formatting object. Found (Namespace URI: , Local Name: article) instead. Please make sure you're producing a valid XSL-FO document. at org.apache.fop.events.ValidationExceptionFactory.createException(ValidationExceptionFactory.java:38) at org.apache.fop.events.EventExceptionManager.throwException(EventExceptionManager.java:58) at org.apache.fop.events.DefaultEventBroadcaster$1.invoke(DefaultEventBroadcaster.java:175) at com.sun.proxy.$Proxy0.invalidFORoot(Unknown Source) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:269) at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:179) 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.dtd.XMLDTDValidator.startElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown Source) at
[jira] [Closed] (FOP-2457) afp TLE and page groupedname issues using fop and stylesheet version 2.0
[
https://issues.apache.org/jira/browse/FOP-2457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Sancho closed FOP-2457.
--
Resolution: Invalid
Hi,
There is something wrong in your XSLT, lines 147 and 162.
I don't know what altova:inline-container-substitute should do, but in XSL-FO
lines 6 and 7 they result both in XPATH expressions, withc I guess are not
expected.
You should have a look in that direction, and ask to Altova users list (see
[1]) to get some help.
[1] http://www.altova.com/list/
afp TLE and page groupedname issues using fop and stylesheet version 2.0
Key: FOP-2457
URL: https://issues.apache.org/jira/browse/FOP-2457
Project: Fop
Issue Type: Test
Components: fo/block, fo/page
Affects Versions: 1.1
Environment: java,altova-stylesheet,fop- for generating afp with
index using TLE tag and groupname
Reporter: Dhiraj
Labels: test
Fix For: 1.1
Attachments: Customer.xml, Customer.xsd, Customer.xsl, Customer.xslt,
afp.xconf
Original Estimate: 48h
Remaining Estimate: 48h
Hi,
i am generate AFP from XML using altova stylesheet version 2.0, but i am
facing problem while generating TLE and page groupedname.i have inserted
fo:afp-tag-logical-element under the fo:page-simple-master but i am not
able to see tag or index.
i am looking for help and thanx in advance.
my stylesheet logic is as below:
fo:simple-page-master master-name=page-master0 margin-left=0in
margin-right=0in page-height=11.69in page-width=8.27in margin-top=0in
margin-bottom=0in
afp:include-page-overlay name=Test0001/
afp:tag-logical-element name=Account_Number
value={/DOCUMENT/BASIC_INFORMATION/Account_Number} encoding=500/
afp:tag-logical-element name=Bill No
value={/DOCUMENT/BASIC_INFORMATION/Bill_Number}/
fo:region-body margin-top=2mm margin-bottom=0in column-count=1
column-gap=0.50in/
/fo:simple-page-master
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FOP-2457) afp TLE and page groupedname issues using fop and stylesheet version 2.0
[
https://issues.apache.org/jira/browse/FOP-2457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14370926#comment-14370926
]
Pascal Sancho commented on FOP-2457:
Hi,
FOP input is XSL-FO, not XSLT.
Please, provide short XSL-FO that can help dev team to reproduce the issue.
afp TLE and page groupedname issues using fop and stylesheet version 2.0
Key: FOP-2457
URL: https://issues.apache.org/jira/browse/FOP-2457
Project: Fop
Issue Type: Test
Components: fo/block, fo/page
Affects Versions: 1.1
Environment: java,altova-stylesheet,fop- for generating afp with
index using TLE tag and groupname
Reporter: Dhiraj
Labels: test
Fix For: 1.1
Original Estimate: 48h
Remaining Estimate: 48h
Hi,
i am generate AFP from XML using altova stylesheet version 2.0, but i am
facing problem while generating TLE and page groupedname.i have inserted
fo:afp-tag-logical-element under the fo:page-simple-master but i am not
able to see tag or index.
i am looking for help and thanx in advance.
my stylesheet logic is as below:
fo:simple-page-master master-name=page-master0 margin-left=0in
margin-right=0in page-height=11.69in page-width=8.27in margin-top=0in
margin-bottom=0in
afp:include-page-overlay name=Test0001/
afp:tag-logical-element name=Account_Number
value={/DOCUMENT/BASIC_INFORMATION/Account_Number} encoding=500/
afp:tag-logical-element name=Bill No
value={/DOCUMENT/BASIC_INFORMATION/Bill_Number}/
fo:region-body margin-top=2mm margin-bottom=0in column-count=1
column-gap=0.50in/
/fo:simple-page-master
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (FOP-2453) fo:list-item-label Automatically wrap when it contains japanese character
[
https://issues.apache.org/jira/browse/FOP-2453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Sancho closed FOP-2453.
--
Resolution: Invalid
Hi,
1st, do not provide XSLT as test case, we require here resulting XSL-FO
material (see \[1]).
That said, your algorithm to compute text width assumes that all characters
have the same width, witch is wrong: usually, Japanese chars are wider than
Latin ones.
So that can give unexpected result.
If you want to get text width, that can be done using the intermediate format
(see \[2]):
{code:title=XSL-FO}
fo:inline background-color=whitemy text/fo:inline
{code}
will result in something like that:
{code:title=IF}
rect x=0 y=2484 width=28800 height=9432 fill=#ff/
font family=monospace style=normal weight=400 variant=normal
size=12000 color=#00/
text x=0 y=10032my text/text
{code}
Note that in IF file, units are in millipoints (72000mp = 1in).
Since FOP behaves correctly here, I close the issue.
For such FOP usage questions, please ask on fop-users list; you'll get greater
audience (see \[3]).
\[1] http://xmlgraphics.apache.org/fop/bugs.html#issues_new
\[2] http://xmlgraphics.apache.org/fop/1.1/intermediate.html
\[3] http://xmlgraphics.apache.org/fop/maillist.html#fop-user
fo:list-item-label Automatically wrap when it contains japanese character
-
Key: FOP-2453
URL: https://issues.apache.org/jira/browse/FOP-2453
Project: Fop
Issue Type: Bug
Reporter: zhangcui
xsl:variable name=aa
xsl:value-of select=string-length('1ff章2') + 10 /
xsl:value-of select='mm' /
/xsl:variable
fo:table
fo:table-column column-number=1 /
fo:table-body
fo:table-row
fo:table-cell
fo:list-block
fo:list-item
fo:list-item-label end-indent=label-end()
fo:block
xsl:value-of select='1ff章2' /
/fo:block
/fo:list-item-label
fo:list-item-body start-indent={$aa}
fo:blockxsl:value-of select='HH1' //fo:block
/fo:list-item-body
/fo:list-item
fo:list-item
fo:list-item-label end-indent=label-end()
fo:block/fo:block
/fo:list-item-label
fo:list-item-body start-indent={$startIndent}
fo:blockxsl:value-of select='HH2' //fo:block
/fo:list-item-body
/fo:list-item
/fo:list-block
/fo:table-cell
/fo:table-row
/fo:table-body
/fo:table
it should be
1ff章2---HH1
---HH2
but the result is
1ff---HH1
章
2
---HH2
and if change the '1ff章2' to '1fff6662',it goes well.
if do not use the fo:list-block,like this
fo:table-cell
fo:block
xsl:value-of select='1ff章2' /
/fo:block
/fo:table-cell
the '1ff章2'display in a line,do not wrap.
i cannot find the reason.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (FOP-2452) the string-length($str) result is incorrect if $str contains japanese character
[
https://issues.apache.org/jira/browse/FOP-2452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Sancho closed FOP-2452.
--
Resolution: Invalid
this issue is a pure XSLT issue, and is out of the scope of FOP.
the string-length($str) result is incorrect if $str contains japanese
character
---
Key: FOP-2452
URL: https://issues.apache.org/jira/browse/FOP-2452
Project: Fop
Issue Type: Bug
Environment: fop1.0
Reporter: zhangcui
xsl:variable name=aa
xsl:value-of select=string-length('1ffガメン') + 10 /
xsl:value-of select='mm' /
/xsl:variable
fo:table
fo:table-column column-number=1 /
fo:table-body
fo:table-row
fo:table-cell
fo:block
xsl:value-of select='1ffガメン'
/xsl:value-of select='H1' /
/fo:block
fo:block start-indent={$aa}
xsl:value-of select='HH' /
/fo:block
/fo:table-cell
/fo:table-row
/fo:table-body
/fo:table
result:
1ffガメンH1
---HH
it should be like this
1ffガメンH1
--HH
actually，i want layout like this,H1andHH are Vertical alignment
1ffガメン---H1
--HH
how can theH1andHH become vertical alignment ?
if anyone can help,thank you！
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FOP-2452) the string-length($str) result is incorrect if $str contains japanese character
[
https://issues.apache.org/jira/browse/FOP-2452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14338204#comment-14338204
]
Pascal Sancho commented on FOP-2452:
oups, big fingers...
the string-length($str) result is incorrect if $str contains japanese
character
---
Key: FOP-2452
URL: https://issues.apache.org/jira/browse/FOP-2452
Project: Fop
Issue Type: Bug
Environment: fop1.0
Reporter: zhangcui
xsl:variable name=aa
xsl:value-of select=string-length('1ffガメン') + 10 /
xsl:value-of select='mm' /
/xsl:variable
fo:table
fo:table-column column-number=1 /
fo:table-body
fo:table-row
fo:table-cell
fo:block
xsl:value-of select='1ffガメン'
/xsl:value-of select='H1' /
/fo:block
fo:block start-indent={$aa}
xsl:value-of select='HH' /
/fo:block
/fo:table-cell
/fo:table-row
/fo:table-body
/fo:table
result:
1ffガメンH1
---HH
it should be like this
1ffガメンH1
--HH
actually，i want layout like this,H1andHH are Vertical alignment
1ffガメン---H1
--HH
how can theH1andHH become vertical alignment ?
if anyone can help,thank you！
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FOP-2452) the string-length($str) result is incorrect if $str contains japanese character
[
https://issues.apache.org/jira/browse/FOP-2452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14338208#comment-14338208
]
Pascal Sancho commented on FOP-2452:
you should 1st ask on XSLT user list (Cf. [1]), more appropriate for such
question, and, if issue is confirmed, open an issue on relevant bugtracker,
depending on what XSLT engine you are using.
Note that for convenience, FOP comes with Xalan.
[1] http://xmlgraphics.apache.org/fop/maillist.html#xslt-mulberry
the string-length($str) result is incorrect if $str contains japanese
character
---
Key: FOP-2452
URL: https://issues.apache.org/jira/browse/FOP-2452
Project: Fop
Issue Type: Bug
Environment: fop1.0
Reporter: zhangcui
xsl:variable name=aa
xsl:value-of select=string-length('1ffガメン') + 10 /
xsl:value-of select='mm' /
/xsl:variable
fo:table
fo:table-column column-number=1 /
fo:table-body
fo:table-row
fo:table-cell
fo:block
xsl:value-of select='1ffガメン'
/xsl:value-of select='H1' /
/fo:block
fo:block start-indent={$aa}
xsl:value-of select='HH' /
/fo:block
/fo:table-cell
/fo:table-row
/fo:table-body
/fo:table
result:
1ffガメンH1
---HH
it should be like this
1ffガメンH1
--HH
actually，i want layout like this,H1andHH are Vertical alignment
1ffガメン---H1
--HH
how can theH1andHH become vertical alignment ?
if anyone can help,thank you！
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FOP-2367) [Patch] Support for color space OCA
[ https://issues.apache.org/jira/browse/FOP-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14304820#comment-14304820 ] Pascal Sancho commented on FOP-2367: Hi, you need to apply Patch on FOP source, then build it. see http://xmlgraphics.apache.org/fop/download.html#source to download src [Patch] Support for color space OCA --- Key: FOP-2367 URL: https://issues.apache.org/jira/browse/FOP-2367 Project: Fop Issue Type: Improvement Affects Versions: trunk Reporter: Seifeddine Dridi Priority: Minor Labels: patch Fix For: trunk Attachments: oca-test.fo, ocacolor.patch Hello, I added support for color space OCA. OCA is used in AFP to set text foreground color and it is still useful in old AFP printers that have a limited support for color or don't support other color spaces (RGB, CMYK, etc...). Seifeddine -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2367) [Patch] Support for color space OCA
[ https://issues.apache.org/jira/browse/FOP-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14302920#comment-14302920 ] Pascal Sancho commented on FOP-2367: Hi, on Mac, you can use commad-line svn tools. See https://ariejan.net/2007/07/03/how-to-create-and-apply-a-patch-with-subversion/ [Patch] Support for color space OCA --- Key: FOP-2367 URL: https://issues.apache.org/jira/browse/FOP-2367 Project: Fop Issue Type: Improvement Affects Versions: trunk Reporter: Seifeddine Dridi Priority: Minor Labels: patch Fix For: trunk Attachments: oca-test.fo, ocacolor.patch Hello, I added support for color space OCA. OCA is used in AFP to set text foreground color and it is still useful in old AFP printers that have a limited support for color or don't support other color spaces (RGB, CMYK, etc...). Seifeddine -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (FOP-2439) Using number-rows-spanned results in a ValidationException
[
https://issues.apache.org/jira/browse/FOP-2439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Sancho closed FOP-2439.
--
Resolution: Invalid
Hi,
{quote}
So it seems FO just doesn't support what I'm trying to do
{quote}
Yes, indeed, fo:table-row must contain at least 1 fo:table-cell (see REC FO1.1
[1]).
And, as Thanasis Giannimaras said, the 2nd test case still lakes 1 table-column.
[1] http://www.w3.org/TR/xsl/#fo_table-row
Using number-rows-spanned results in a ValidationException
--
Key: FOP-2439
URL: https://issues.apache.org/jira/browse/FOP-2439
Project: Fop
Issue Type: Bug
Components: renderer/pdf
Affects Versions: 1.1
Environment: Windows 8.1
Reporter: nick.heyworth
Priority: Critical
Attachments: Possible FOP Bug Modified.fo, Possible FOP Bug.fo
The attached file results in a ValidationException when attempting to create
PDF. After changing the value of the number-rows-spanned attribute to 1, PDF
creation works.
In case my FO is incorrect, please let me know.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (FOP-2439) Using number-rows-spanned results in a ValidationException
[ https://issues.apache.org/jira/browse/FOP-2439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Sancho closed FOP-2439. -- Resolution: Invalid in the provided FO test case, the table is a 2x2 matrix: - on 2nd row: - 1st cell is described within the 1st 1st row (using number-row-spanned) - therefore the described cell comes in 2nd column Only 1 column is described, so adding the 2nd table-column resolves the issue. Using number-rows-spanned results in a ValidationException -- Key: FOP-2439 URL: https://issues.apache.org/jira/browse/FOP-2439 Project: Fop Issue Type: Bug Components: renderer/pdf Affects Versions: 1.1 Environment: Windows 8.1 Reporter: nick.heyworth Priority: Critical Attachments: Possible FOP Bug.fo The attached file results in a ValidationException when attempting to create PDF. After changing the value of the number-rows-spanned attribute to 1, PDF creation works. In case my FO is incorrect, please let me know. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2431) Is there any possibility to convert PDF into XML using apache fop?
[ https://issues.apache.org/jira/browse/FOP-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14227409#comment-14227409 ] Pascal Sancho commented on FOP-2431: Hi Swati, Jira is used mainly as a bugtracker, it's not a forum. For such questions, please ask on fop-users list, this is the right place for this (see [1]). You'll get there a larger audience, among witch some people that don't monitor Jira, will read you with interest. Thank you. [1] http://xmlgraphics.apache.org/fop/maillist.html Is there any possibility to convert PDF into XML using apache fop? -- Key: FOP-2431 URL: https://issues.apache.org/jira/browse/FOP-2431 Project: Fop Issue Type: Task Reporter: swati dhingra Labels: newbie Original Estimate: 612h Remaining Estimate: 612h We know Apache is used to convert XML Into PDF and so many other output formats but is there any possibility that we can convert PDF into XML? Any command? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2428) Apache PDF issue with Wingding characters
[ https://issues.apache.org/jira/browse/FOP-2428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14219309#comment-14219309 ] Pascal Sancho commented on FOP-2428: Before filing in an issue, please read Fop guidelines for submitting an issue [1]. More precisely, we encourage you to ask 1st on fop-users mailing list [2], providing exhaustive information: - FOP version, - short XSL-FO file demonstrating the issue, - in your case: fop.xconf, - OS, - how Fop is invoked, - etc. [1] http://xmlgraphics.apache.org/fop/bugs.html#issues_new [2] http://xmlgraphics.apache.org/fop/gethelp.html#user-mailing-list Apache PDF issue with Wingding characters - Key: FOP-2428 URL: https://issues.apache.org/jira/browse/FOP-2428 Project: Fop Issue Type: Bug Components: fo/inline Environment: Windows, Unix Reporter: PRAVAT Priority: Critical Labels: ApachePDf, Wingding The below unicode Character s give different results for Apache RTF and PDF format. The font used here is Winfdings. RTF gives the correct output, where as the PDF does not find these characters. I am using APache FOP 1.0. U+00FDý U+00FEþ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FOP-2403) FOP 1.1 throws a Null pointer exception when FOP 1.0 does not
[ https://issues.apache.org/jira/browse/FOP-2403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Sancho resolved FOP-2403. Resolution: Cannot Reproduce The only issues I get are O.A.F.fo.ValidationException, caused by duplicate ID or empty fo:table-body, against FOP 1.0, 1.1 and TRUNK. I cannot reproduce NPE with the provided material, whatever the FOP version is. As said by Glenn, at least provide Exception trace, that will help in the 1st time to determine if thrown by FOP or other lib. Fill free to reopen if further info 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-2401) NullPointerException near InlineStackingLayoutManager
[ https://issues.apache.org/jira/browse/FOP-2401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14082006#comment-14082006 ] Pascal Sancho commented on FOP-2401: this is caused by empty fo:inline with id NullPointerException near InlineStackingLayoutManager - Key: FOP-2401 URL: https://issues.apache.org/jira/browse/FOP-2401 Project: Fop Issue Type: Bug Affects Versions: 1.0 Environment: debian gnu/linux fop-1:1.0.dfsg2-6 fails; fop-1:1.1.dfsg-2 fails too; Reporter: Bernhard Reutner-Fischer Attachments: fop-bug.xml, fop-bug.xml.fop, fop-bug.xsl, reduced.fop I must be doing something wrong? :) $ xsltproc fop-bug.xsl fop-bug.xml | tee fop-bug.xml.fop | fop -d - ok.pdf [] getNextSimplePageMaster(page=3 isOdd=true isFirst=true isLast=false isBlank=false) [3] PLM flow BPD =697889 start of the next element list is: page=3 col=0 Exception org.apache.fop.apps.FOPException java.lang.NullPointerException at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:302) at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:130) at org.apache.fop.cli.Main.startFOP(Main.java:174) at org.apache.fop.cli.Main.main(Main.java:205) Caused by: java.lang.NullPointerException at org.apache.fop.layoutmgr.inline.InlineStackingLayoutManager.getChangedKnuthElements(InlineStackingLayoutManager.java:376) at org.apache.fop.layoutmgr.inline.InlineLayoutManager.getChangedKnuthElements(InlineLayoutManager.java:537) at org.apache.fop.layoutmgr.inline.InlineStackingLayoutManager.getChangedKnuthElements(InlineStackingLayoutManager.java:381) at org.apache.fop.layoutmgr.inline.InlineLayoutManager.getChangedKnuthElements(InlineLayoutManager.java:537) at org.apache.fop.layoutmgr.inline.LineLayoutManager.processUpdates(LineLayoutManager.java:1349) [] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (FOP-2401) NullPointerException near InlineStackingLayoutManager
[ https://issues.apache.org/jira/browse/FOP-2401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Sancho resolved FOP-2401. Resolution: Duplicate NullPointerException near InlineStackingLayoutManager - Key: FOP-2401 URL: https://issues.apache.org/jira/browse/FOP-2401 Project: Fop Issue Type: Bug Affects Versions: 1.0 Environment: debian gnu/linux fop-1:1.0.dfsg2-6 fails; fop-1:1.1.dfsg-2 fails too; Reporter: Bernhard Reutner-Fischer Attachments: fop-bug.xml, fop-bug.xml.fop, fop-bug.xsl, reduced.fop I must be doing something wrong? :) $ xsltproc fop-bug.xsl fop-bug.xml | tee fop-bug.xml.fop | fop -d - ok.pdf [] getNextSimplePageMaster(page=3 isOdd=true isFirst=true isLast=false isBlank=false) [3] PLM flow BPD =697889 start of the next element list is: page=3 col=0 Exception org.apache.fop.apps.FOPException java.lang.NullPointerException at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:302) at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:130) at org.apache.fop.cli.Main.startFOP(Main.java:174) at org.apache.fop.cli.Main.main(Main.java:205) Caused by: java.lang.NullPointerException at org.apache.fop.layoutmgr.inline.InlineStackingLayoutManager.getChangedKnuthElements(InlineStackingLayoutManager.java:376) at org.apache.fop.layoutmgr.inline.InlineLayoutManager.getChangedKnuthElements(InlineLayoutManager.java:537) at org.apache.fop.layoutmgr.inline.InlineStackingLayoutManager.getChangedKnuthElements(InlineStackingLayoutManager.java:381) at org.apache.fop.layoutmgr.inline.InlineLayoutManager.getChangedKnuthElements(InlineLayoutManager.java:537) at org.apache.fop.layoutmgr.inline.LineLayoutManager.processUpdates(LineLayoutManager.java:1349) [] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (FOP-2401) NullPointerException near InlineStackingLayoutManager
[ https://issues.apache.org/jira/browse/FOP-2401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14082006#comment-14082006 ] Pascal Sancho edited comment on FOP-2401 at 8/1/14 7:14 AM: this is caused by empty fo:inline with id, nested in another fo:inline was (Author: psancho): this is caused by empty fo:inline with id NullPointerException near InlineStackingLayoutManager - Key: FOP-2401 URL: https://issues.apache.org/jira/browse/FOP-2401 Project: Fop Issue Type: Bug Affects Versions: 1.0 Environment: debian gnu/linux fop-1:1.0.dfsg2-6 fails; fop-1:1.1.dfsg-2 fails too; Reporter: Bernhard Reutner-Fischer Attachments: fop-bug.xml, fop-bug.xml.fop, fop-bug.xsl, reduced.fop I must be doing something wrong? :) $ xsltproc fop-bug.xsl fop-bug.xml | tee fop-bug.xml.fop | fop -d - ok.pdf [] getNextSimplePageMaster(page=3 isOdd=true isFirst=true isLast=false isBlank=false) [3] PLM flow BPD =697889 start of the next element list is: page=3 col=0 Exception org.apache.fop.apps.FOPException java.lang.NullPointerException at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:302) at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:130) at org.apache.fop.cli.Main.startFOP(Main.java:174) at org.apache.fop.cli.Main.main(Main.java:205) Caused by: java.lang.NullPointerException at org.apache.fop.layoutmgr.inline.InlineStackingLayoutManager.getChangedKnuthElements(InlineStackingLayoutManager.java:376) at org.apache.fop.layoutmgr.inline.InlineLayoutManager.getChangedKnuthElements(InlineLayoutManager.java:537) at org.apache.fop.layoutmgr.inline.InlineStackingLayoutManager.getChangedKnuthElements(InlineStackingLayoutManager.java:381) at org.apache.fop.layoutmgr.inline.InlineLayoutManager.getChangedKnuthElements(InlineLayoutManager.java:537) at org.apache.fop.layoutmgr.inline.LineLayoutManager.processUpdates(LineLayoutManager.java:1349) [] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FOP-1776) NPE caused by nested empty fo:inline with id
[ https://issues.apache.org/jira/browse/FOP-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Sancho updated FOP-1776: --- Priority: Blocker Summary: NPE caused by nested empty fo:inline with id (was: java.lang.NullPointerException: org.apache.fop.layoutmgr.inline.InlineStackingLayoutManager.getChangedKnuthElements(InlineStackingLayoutManager.java:375)) NPE caused by nested empty fo:inline with id Key: FOP-1776 URL: https://issues.apache.org/jira/browse/FOP-1776 Project: Fop Issue Type: Bug Components: renderer/pdf Affects Versions: trunk Environment: Operating System: All Platform: All Reporter: Mathieu Malaterre Priority: Blocker Attachments: anchor.id.patch, test2.fo Here is my input docbook file: ?xml version='1.0' encoding='UTF-8'? !DOCTYPE article PUBLIC -//OASIS//DTD DocBook XML V4.5//EN http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd; [] article section titletitle/title blockquote para The emphasis role=boldanchor id=example.anchor.1/anchor/emphasis element is empty and contributes nothing to the flow of the content in which it occurs. It is only useful as a target. /para /blockquote /section /article which I process with: /usr/bin/xsltproc --stringparam fop1.extensions 1 --stringparam ulink.show 0 --xinclude -o test2.fo /usr/share/xml/docbook/stylesheet/nwalsh/fo/docbook.xsl test2.xml and lead to: $ ./fop test2.fo test2.pdf Feb 17, 2010 2:52:18 PM org.apache.fop.apps.FOURIResolver resolve SEVERE: Error with opening URL 'http://docbook.sourceforge.net/release/images/draft.png': Network is unreachable Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:9588) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:10285) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:10980) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:11672) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:12361) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:13050) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:13736) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:14427) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:15118) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:15806) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:16496) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:17186) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:17873) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:18563) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:19253) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:19940) Feb 17, 2010 2:52:18 PM
[jira] [Updated] (FOP-1776) NPE caused by nested empty fo:inline with id
[ https://issues.apache.org/jira/browse/FOP-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Sancho updated FOP-1776: --- Component/s: (was: renderer/pdf) layout/inline NPE caused by nested empty fo:inline with id Key: FOP-1776 URL: https://issues.apache.org/jira/browse/FOP-1776 Project: Fop Issue Type: Bug Components: layout/inline Affects Versions: trunk Environment: Operating System: All Platform: All Reporter: Mathieu Malaterre Priority: Blocker Attachments: anchor.id.patch, test2.fo Here is my input docbook file: ?xml version='1.0' encoding='UTF-8'? !DOCTYPE article PUBLIC -//OASIS//DTD DocBook XML V4.5//EN http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd; [] article section titletitle/title blockquote para The emphasis role=boldanchor id=example.anchor.1/anchor/emphasis element is empty and contributes nothing to the flow of the content in which it occurs. It is only useful as a target. /para /blockquote /section /article which I process with: /usr/bin/xsltproc --stringparam fop1.extensions 1 --stringparam ulink.show 0 --xinclude -o test2.fo /usr/share/xml/docbook/stylesheet/nwalsh/fo/docbook.xsl test2.xml and lead to: $ ./fop test2.fo test2.pdf Feb 17, 2010 2:52:18 PM org.apache.fop.apps.FOURIResolver resolve SEVERE: Error with opening URL 'http://docbook.sourceforge.net/release/images/draft.png': Network is unreachable Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:9588) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:10285) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:10980) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:11672) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:12361) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:13050) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:13736) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:14427) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:15118) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:15806) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:16496) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:17186) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:17873) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:18563) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:19253) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:19940) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:20631) Feb 17, 2010 2:52:18
[jira] [Updated] (FOP-1776) NPE caused by nested empty fo:inline with id
[ https://issues.apache.org/jira/browse/FOP-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Sancho updated FOP-1776: --- Attachment: _test.fo attached _test.fo: very short test case (with workaround in comment) NPE caused by nested empty fo:inline with id Key: FOP-1776 URL: https://issues.apache.org/jira/browse/FOP-1776 Project: Fop Issue Type: Bug Components: layout/inline Affects Versions: trunk Environment: Operating System: All Platform: All Reporter: Mathieu Malaterre Priority: Blocker Attachments: _test.fo, anchor.id.patch, test2.fo Here is my input docbook file: ?xml version='1.0' encoding='UTF-8'? !DOCTYPE article PUBLIC -//OASIS//DTD DocBook XML V4.5//EN http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd; [] article section titletitle/title blockquote para The emphasis role=boldanchor id=example.anchor.1/anchor/emphasis element is empty and contributes nothing to the flow of the content in which it occurs. It is only useful as a target. /para /blockquote /section /article which I process with: /usr/bin/xsltproc --stringparam fop1.extensions 1 --stringparam ulink.show 0 --xinclude -o test2.fo /usr/share/xml/docbook/stylesheet/nwalsh/fo/docbook.xsl test2.xml and lead to: $ ./fop test2.fo test2.pdf Feb 17, 2010 2:52:18 PM org.apache.fop.apps.FOURIResolver resolve SEVERE: Error with opening URL 'http://docbook.sourceforge.net/release/images/draft.png': Network is unreachable Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:9588) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:10285) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:10980) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:11672) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:12361) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:13050) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:13736) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:14427) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:15118) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:15806) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:16496) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:17186) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:17873) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:18563) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:19253) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position 2:19940) Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener processEvent SEVERE: Image not found. URI: http://docbook.sourceforge.net/release/images/draft.png. (See position
[jira] [Updated] (FOP-1615) NPE in InlineStackingLayoutManager when hyphenate without break opportunity
[
https://issues.apache.org/jira/browse/FOP-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Sancho updated FOP-1615:
---
Component/s: (was: layout/unqualified)
layout/inline
NPE in InlineStackingLayoutManager when hyphenate without break opportunity
---
Key: FOP-1615
URL: https://issues.apache.org/jira/browse/FOP-1615
Project: Fop
Issue Type: Bug
Components: layout/inline
Affects Versions: 0.95
Environment: Operating System: Linux
Platform: PC
Reporter: Carsten Metzler
Priority: Blocker
Attachments: mantis779.fo, module.fo.gz
In the org.apache.fop.layoutmgr.inline.InlineStackingLayoutManager an
NullPointerException is thrown in the applyChanges-method, when the
variables prevLM AND currLM both are null.
line 333-338:
currLM = (InlineLevelLayoutManager) oldElement.getLayoutManager();
// initialize prevLM
if (prevLM == null) {
prevLM = currLM;
}
The getLayoutManager-method of the ListElement-class returns null when no
position is set, so currLM is null. If prevLM is null, too, prevLM is set to
currLM - so both are null. In the following code the applyChanges-method is
called on prevLM without null-check.
As workaround I inserted the following code after line 338:
if(prevLM == null currLM == null) {
continue;
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (FOP-1615) NPE in InlineStackingLayoutManager when hyphenate without break opportunity
[
https://issues.apache.org/jira/browse/FOP-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Sancho updated FOP-1615:
---
Priority: Blocker
Summary: NPE in InlineStackingLayoutManager when hyphenate without break
opportunity (was: NullPointerException in InlineStackingLayoutManager)
NPE in InlineStackingLayoutManager when hyphenate without break opportunity
---
Key: FOP-1615
URL: https://issues.apache.org/jira/browse/FOP-1615
Project: Fop
Issue Type: Bug
Components: layout/inline
Affects Versions: 0.95
Environment: Operating System: Linux
Platform: PC
Reporter: Carsten Metzler
Priority: Blocker
Attachments: mantis779.fo, module.fo.gz
In the org.apache.fop.layoutmgr.inline.InlineStackingLayoutManager an
NullPointerException is thrown in the applyChanges-method, when the
variables prevLM AND currLM both are null.
line 333-338:
currLM = (InlineLevelLayoutManager) oldElement.getLayoutManager();
// initialize prevLM
if (prevLM == null) {
prevLM = currLM;
}
The getLayoutManager-method of the ListElement-class returns null when no
position is set, so currLM is null. If prevLM is null, too, prevLM is set to
currLM - so both are null. In the following code the applyChanges-method is
called on prevLM without null-check.
As workaround I inserted the following code after line 338:
if(prevLM == null currLM == null) {
continue;
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (FOP-2401) NullPointerException near InlineStackingLayoutManager
[ https://issues.apache.org/jira/browse/FOP-2401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14080821#comment-14080821 ] Pascal Sancho commented on FOP-2401: Please, don't copy/paste pieces of code in comments, rather, attach files. Another thing: attach resulting FO file (reduced as possible), not xml+xslt (that causes extra works before test and check). Testers ans developers will dive into in an easier way. See [1] for further: [1] http://xmlgraphics.apache.org/fop/bugs.html#issues_new Did you check against FOP 1.1 or (better) FOP trunk? NullPointerException near InlineStackingLayoutManager - Key: FOP-2401 URL: https://issues.apache.org/jira/browse/FOP-2401 Project: Fop Issue Type: Bug Affects Versions: 1.0 Environment: debian gnu/linux fop-1:1.0.dfsg2-6 fails; fop-1:1.1.dfsg-2 fails too; Reporter: Bernhard Reutner-Fischer I must be doing something wrong? :) $ xsltproc fop-bug.xsl fop-bug.xml | tee fop-bug.xml.fop | fop -d - ok.pdf [] getNextSimplePageMaster(page=3 isOdd=true isFirst=true isLast=false isBlank=false) [3] PLM flow BPD =697889 start of the next element list is: page=3 col=0 Exception org.apache.fop.apps.FOPException java.lang.NullPointerException at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:302) at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:130) at org.apache.fop.cli.Main.startFOP(Main.java:174) at org.apache.fop.cli.Main.main(Main.java:205) Caused by: java.lang.NullPointerException at org.apache.fop.layoutmgr.inline.InlineStackingLayoutManager.getChangedKnuthElements(InlineStackingLayoutManager.java:376) at org.apache.fop.layoutmgr.inline.InlineLayoutManager.getChangedKnuthElements(InlineLayoutManager.java:537) at org.apache.fop.layoutmgr.inline.InlineStackingLayoutManager.getChangedKnuthElements(InlineStackingLayoutManager.java:381) at org.apache.fop.layoutmgr.inline.InlineLayoutManager.getChangedKnuthElements(InlineLayoutManager.java:537) at org.apache.fop.layoutmgr.inline.LineLayoutManager.processUpdates(LineLayoutManager.java:1349) [] $ cat fop-bug.xml ?xml version=1.0 encoding=UTF-8? !DOCTYPE book PUBLIC -//OASIS//DTD DocBook XML 5.0//EN http://docbook.org/xml/5.0/dtd/docbook.dtd; book info titleBug/title /info part chapter xml:id=chapter.config titleThe configuration/title section xml:id=chapter.config-Available_plugins titleAvailable plugins/title para variablelist varlistentry termanchor xml:id=chapter.config-plugin1_i2/Plugin 1/term listitem para TODO /para para variablelist varlistentry termanchor xml:id=chapter.config-user_i2/user/term listitem para TODO /para /listitem /varlistentry varlistentry termanchor xml:id=chapter.config-password_i2/password/term listitem para TODO /para /listitem /varlistentry /variablelist /para /listitem /varlistentry /variablelist /para /section /chapter /part /book $ cat fop-bug.xsl ?xml version='1.0'? xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; exclude-result-prefixes=xsl xsl:import href=/usr/share/sgml/docbook/stylesheet/xsl/docbook-xsl/fo/docbook.xsl/ xsl:param name=paper.type select='A4'/ xsl:param name=draft.modeyes/xsl:param xsl:output method=xml indent=yes encoding=UTF-8 doctype-public=-//OASIS//DTD DocBook XML 5.0//EN doctype-system=http://www.docbook.org/xml/5.0/dtd/docbook.dtd; / xsl:strip-space elements=*/ xsl:template name=draft.text xsl:choose xsl:when test=$draft.mode = 'yes' xsl:textInternal/xsl:text /xsl:when /xsl:choose /xsl:template xsl:attribute-set name=monospace.verbatim.properties xsl:attribute name=wrap-optionwrap/xsl:attribute /xsl:attribute-set /xsl:stylesheet -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FOP-2383) [patch] table cells inherit inline styles from preceding cells.
[ https://issues.apache.org/jira/browse/FOP-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Sancho updated FOP-2383: --- Component/s: (was: renderer/pdf) renderer/rtf [patch] table cells inherit inline styles from preceding cells. --- Key: FOP-2383 URL: https://issues.apache.org/jira/browse/FOP-2383 Project: Fop Issue Type: Bug Components: renderer/rtf Affects Versions: 1.1 Reporter: Michael Hombre Brinkmann Priority: Minor Attachments: rtf-table-inline-attribute-patch.diff If in a table cell a style bold, italic, strikethrough, underline, super or sub is given, these styles are applied to all subsequent cells of the same row. The given patch only solves the problems for the 6 named styles. It can be probably enhanced to fix also issures #FOP-2225 and #FOP-1487. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FOP-2366) Incorrect Bullets for mulitple para within a single list-item inside a table
[ https://issues.apache.org/jira/browse/FOP-2366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Sancho updated FOP-2366: --- Description: The fix for the bug FOP-1863 (BUGZILLA 50163) doesn't work if the list-block is inside a table. https://issues.apache.org/jira/browse/FOP-1863 Below is the FO. fo:flow flow-name=xsl-region-body fo:table fo:table-column column-width=4.50in/ fo:table-column column-width=2.00in/ fo:table-body fo:table-row padding-top=.00in padding-bottom=.00in fo:table-cell padding=.00in fo:block fo:list-block fo:list-item fo:list-item-label fo:block•/fo:block /fo:list-item-label fo:list-item-body start-indent=body-start() fo:blockTest Block 0/fo:block fo:blockTest Block I/fo:block fo:blockfo:inlineTest Block II/fo:inline/fo:block /fo:list-item-body /fo:list-item /fo:list-block /fo:block /fo:table-cell /fo:table-row /fo:table-body /fo:table /fo:flow was: The fix for the bug 50163 doesn't work if the list-block is inside a table. https://issues.apache.org/bugzilla/show_bug.cgi?id=50163. Below is the FO. fo:flow flow-name=xsl-region-body fo:table fo:table-column column-width=4.50in/ fo:table-column column-width=2.00in/ fo:table-body fo:table-row padding-top=.00in padding-bottom=.00in fo:table-cell padding=.00in fo:block fo:list-block fo:list-item fo:list-item-label fo:block•/fo:block /fo:list-item-label fo:list-item-body start-indent=body-start() fo:blockTest Block 0/fo:block fo:blockTest Block I/fo:block fo:blockfo:inlineTest Block II/fo:inline/fo:block /fo:list-item-body /fo:list-item /fo:list-block /fo:block /fo:table-cell /fo:table-row /fo:table-body /fo:table /fo:flow Incorrect Bullets for mulitple para within a single list-item inside a table - Key: FOP-2366 URL: https://issues.apache.org/jira/browse/FOP-2366 Project: Fop Issue Type: Bug Components: general Affects Versions: 1.0 Environment: Windows 7, Java 6.7 Reporter: Srinivas Bolisetti Labels: patch Original Estimate: 168h Remaining Estimate: 168h The fix for the bug FOP-1863 (BUGZILLA 50163) doesn't work if the list-block is inside a table. https://issues.apache.org/jira/browse/FOP-1863 Below is the FO. fo:flow flow-name=xsl-region-body fo:table fo:table-column column-width=4.50in/ fo:table-column column-width=2.00in/ fo:table-body fo:table-row padding-top=.00in padding-bottom=.00in fo:table-cell padding=.00in fo:block fo:list-block fo:list-item fo:list-item-label fo:block•/fo:block /fo:list-item-label fo:list-item-body start-indent=body-start() fo:blockTest Block 0/fo:block fo:blockTest Block I/fo:block fo:blockfo:inlineTest Block II/fo:inline/fo:block /fo:list-item-body /fo:list-item /fo:list-block /fo:block /fo:table-cell /fo:table-row /fo:table-body /fo:table /fo:flow -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (FOP-2365) pdf's name contains chinese character
[ https://issues.apache.org/jira/browse/FOP-2365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13969307#comment-13969307 ] Pascal Sancho commented on FOP-2365: Hi, I'm pretty sure that the cause is how File system handle filenames. Not all FS used by Windows support UTF8 filenames (Cf. [1]). Another cause could be the codepage used by the Windows shell. Another thing: I guess you are calling fop.bat from Java app; it's not a common way to run FOP from Java... it would be benefit to directly embed FOP calls in your app (see [2]), so you will not be facing to Shell limitations. I expect some feedback before I close this issue as Invalid. [1] http://msdn.microsoft.com/en-us/library/windows/desktop/dd317748%28v=vs.85%29.aspx [2] http://xmlgraphics.apache.org/fop/1.0/embedding.html pdf's name contains chinese character - Key: FOP-2365 URL: https://issues.apache.org/jira/browse/FOP-2365 Project: Fop Issue Type: Bug Components: pdf Affects Versions: 1.0 Environment: Windows 7 Ultimate 64bit Reporter: zhangcui use fop1.0,i create a pdf,if the pdf's name contains chinese character,it will fail. but use the same code,if the server OS is windows 2008 JP,it works fine. my server OS is windows 7 ultimate JP. ListString cmdList = new ArrayListString(); cmdList.add(fop.bat); cmdList.add(c:\\logfile.log); cmdList.add(-xsl); cmdList.add(c:\\myxsl.xsl); cmdList.add(-param); cmdList.add(pp); cmdList.add(c:\\param.txt); cmdList.add(-xml); cmdList.add(c:\\myxml.xml); cmdList.add(-pdf); cmdList.add(c:\\mypdf.pdf); ProcessBuilder pb = new ProcessBuilder(command); p = pb.start(); sorry for my english... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (FOP-2365) pdf's name contains chinese character
[ https://issues.apache.org/jira/browse/FOP-2365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13969398#comment-13969398 ] Pascal Sancho commented on FOP-2365: After changing codepage, you should restart Windows and check in a shell environment that your change is effective. Guessing you are invoking fop.bat through a java process: JVM config can differ between your 2 machines, including java version. Perhaps the ProcessBuilder() contructor set some default values Or maybe a Windows bugfix... Or... googleing: http://www.coderanch.com/t/279253/java-io/java/Unicode-cmd-parameters-main-args This seems to be definitively related to your machine configuration, in such case FOP has nothing to do with this issue. pdf's name contains chinese character - Key: FOP-2365 URL: https://issues.apache.org/jira/browse/FOP-2365 Project: Fop Issue Type: Bug Components: pdf Affects Versions: 1.0 Environment: Windows 7 Ultimate 64bit Reporter: zhangcui use fop1.0,i create a pdf,if the pdf's name contains chinese character,it will fail. but use the same code,if the server OS is windows 2008 JP,it works fine. my server OS is windows 7 ultimate JP. ListString cmdList = new ArrayListString(); cmdList.add(fop.bat); cmdList.add(c:\\logfile.log); cmdList.add(-xsl); cmdList.add(c:\\myxsl.xsl); cmdList.add(-param); cmdList.add(pp); cmdList.add(c:\\param.txt); cmdList.add(-xml); cmdList.add(c:\\myxml.xml); cmdList.add(-pdf); cmdList.add(c:\\mypdf.pdf); ProcessBuilder pb = new ProcessBuilder(command); p = pb.start(); sorry for my english... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (FOP-2352) Unable to render Arabic Text using Apache FOP
[ https://issues.apache.org/jira/browse/FOP-2352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13920879#comment-13920879 ] Pascal Sancho commented on FOP-2352: Hi, Please, for FOP usage related question, ask 1st on fop-user list. That said, '#' is used when required glyph is not available in the font (see FAQ 6.2 at [1]). That can be caused by: - either the used font is not a Unicode one, so the code points do not match to character numbers - or your font is a Unicode one, but doesn't carry arabic subset. I suspect you meet the former case: your font (أوقات رومانية in your example) carries the arabic glyphes, but char codes are offset. In addition, complex script feature uses GPOS and SUBST tables (very usefull for arabic), and not all font files carry them. If confirmed, you should change your font and use one that is known to work like a charm with FOP (see list at [2]). [1] http://xmlgraphics.apache.org/fop/faq.html#pdf-characters [2] http://xmlgraphics.apache.org/fop/1.1/complexscripts.html#fonts_arabic Unable to render Arabic Text using Apache FOP - Key: FOP-2352 URL: https://issues.apache.org/jira/browse/FOP-2352 Project: Fop Issue Type: Bug Components: pdf Affects Versions: 0.95, 1.0, 1.1 Environment: Operating System:Windows Java version : 1.6 Reporter: ramakanthreddy Priority: Critical Attachments: src.zip When trying to render arabic text using Apache FOP # is displayed in pdf file instead of arabic text. Working fine for french and english but fails for arabic Characterset used is : UTF-8 and StreamSource type is StringReader -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FOP-2341) [PATCH] Infinite loop when smaller used with a zero length font-size
[ https://issues.apache.org/jira/browse/FOP-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Sancho updated FOP-2341: --- Fix Version/s: trunk [PATCH] Infinite loop when smaller used with a zero length font-size --- Key: FOP-2341 URL: https://issues.apache.org/jira/browse/FOP-2341 Project: Fop Issue Type: Bug Components: general Affects Versions: 0.95, trunk Reporter: MOHD Priority: Critical Labels: font-size, infinite-loop, smaller Fix For: trunk Attachments: _test.fo, patch.diff Original Estimate: 1m Remaining Estimate: 1m My local FOP engine is hang when below scenario was occur. fo:block font-style=normal font-size=10mmpt role=html:div fo:inline baseline-shift=super font-size=smaller role=html:supth/fo:inlineof each month. /fo:block Please give some suggestion if any one has solution for this issue. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (FOP-2342) Make image from URL abide no-cache HTTP headers
[
https://issues.apache.org/jira/browse/FOP-2342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13901391#comment-13901391
]
Pascal Sancho edited comment on FOP-2342 at 2/14/14 12:43 PM:
--
FOP caches images, and that cache is based on their URI.
You can disable such cache as said there:
[1] http://xmlgraphics.apache.org/fop/1.1/graphics.html#caching
If that doesn't help you, feel free to repoen this issue.
was (Author: psancho):
FOP caches images, and that cache is based on its URI.
You can disable such case as said there:
[1] http://xmlgraphics.apache.org/fop/1.1/graphics.html#caching
If that doesn't help you, feel free to repoen this issue.
Make image from URL abide no-cache HTTP headers
---
Key: FOP-2342
URL: https://issues.apache.org/jira/browse/FOP-2342
Project: Fop
Issue Type: Improvement
Components: images
Affects Versions: 1.1
Environment: Tested on CentOS, Tomcat6 and FOP 1.1rc1 service
Reporter: The BitSmith
Priority: Minor
Labels: http-headers, image
When I include an image, it is cached. So including a dynamic image shows
only the first version of the image. To prevent this, I have to add a
constantly changing parameter (called nonce here):
fo:external-graphic width=140mm height=30mm
content-width=scale-down-to-fit content-height=scale-down-to-fit
inline-progression-dimension.maximum=100% scaling=uniform
vertical-align=-50%
xsl:variable name=orgguid select=Organization/ID /
xsl:variable name=nonce select=Nonce /
xsl:variable name=logo
select=concat('http://localhost/images/fopimages/logo.php?orgid=', $orgguid,
'amp;dummy=', $nonce)/
xsl:attribute name=srcurl(xsl:value-of select=$logo/)/xsl:attribute
/fo:external-graphic
This happens despite the fact that the PHP script that produces the image
sends no-cache headers (PHP code):
header('Expires: Fri, 13 May 1983 18:30:00 GMT');
header('Last-Modified: ' . gmdate('D, d M Y H:i:s') . ' GMT');
header('Cache-Control: no-store, no-cache, must-revalidate'); // HTTP/1.1
header('Cache-Control: post-check=0, pre-check=0', FALSE);
header('Pragma: no-cache'); // HTTP/1.0
header('Content-Type: ' . $this-mstrLogoType);
header('Content-Length: ' . strlen($this-mmixLogoData));
header('Content-Disposition: inline');
header('X-Content-Type-Options: nosniff'); // Workaround for IE bug.
echo $this-mmixLogoData;
It would be nice if the image caching mechanism would abide these headers, so
workarounds like extra parameters are not necessary.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (FOP-2342) Make image from URL abide no-cache HTTP headers
[
https://issues.apache.org/jira/browse/FOP-2342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Sancho resolved FOP-2342.
Resolution: Implemented
FOP caches images, and that cache is based on its URI.
You can disable such case as said there:
[1] http://xmlgraphics.apache.org/fop/1.1/graphics.html#caching
If that doesn't help you, feel free to repoen this issue.
Make image from URL abide no-cache HTTP headers
---
Key: FOP-2342
URL: https://issues.apache.org/jira/browse/FOP-2342
Project: Fop
Issue Type: Improvement
Components: images
Affects Versions: 1.1
Environment: Tested on CentOS, Tomcat6 and FOP 1.1rc1 service
Reporter: The BitSmith
Priority: Minor
Labels: http-headers, image
When I include an image, it is cached. So including a dynamic image shows
only the first version of the image. To prevent this, I have to add a
constantly changing parameter (called nonce here):
fo:external-graphic width=140mm height=30mm
content-width=scale-down-to-fit content-height=scale-down-to-fit
inline-progression-dimension.maximum=100% scaling=uniform
vertical-align=-50%
xsl:variable name=orgguid select=Organization/ID /
xsl:variable name=nonce select=Nonce /
xsl:variable name=logo
select=concat('http://localhost/images/fopimages/logo.php?orgid=', $orgguid,
'amp;dummy=', $nonce)/
xsl:attribute name=srcurl(xsl:value-of select=$logo/)/xsl:attribute
/fo:external-graphic
This happens despite the fact that the PHP script that produces the image
sends no-cache headers (PHP code):
header('Expires: Fri, 13 May 1983 18:30:00 GMT');
header('Last-Modified: ' . gmdate('D, d M Y H:i:s') . ' GMT');
header('Cache-Control: no-store, no-cache, must-revalidate'); // HTTP/1.1
header('Cache-Control: post-check=0, pre-check=0', FALSE);
header('Pragma: no-cache'); // HTTP/1.0
header('Content-Type: ' . $this-mstrLogoType);
header('Content-Length: ' . strlen($this-mmixLogoData));
header('Content-Disposition: inline');
header('X-Content-Type-Options: nosniff'); // Workaround for IE bug.
echo $this-mmixLogoData;
It would be nice if the image caching mechanism would abide these headers, so
workarounds like extra parameters are not necessary.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Comment Edited] (FOP-2342) Make image from URL abide no-cache HTTP headers
[
https://issues.apache.org/jira/browse/FOP-2342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13901391#comment-13901391
]
Pascal Sancho edited comment on FOP-2342 at 2/14/14 12:43 PM:
--
FOP caches images, and that cache is based on their URI.
You can disable such cache as said there:
[1] http://xmlgraphics.apache.org/fop/1.1/graphics.html#caching
If that doesn't help you, feel free to reopen this issue.
was (Author: psancho):
FOP caches images, and that cache is based on their URI.
You can disable such cache as said there:
[1] http://xmlgraphics.apache.org/fop/1.1/graphics.html#caching
If that doesn't help you, feel free to repoen this issue.
Make image from URL abide no-cache HTTP headers
---
Key: FOP-2342
URL: https://issues.apache.org/jira/browse/FOP-2342
Project: Fop
Issue Type: Improvement
Components: images
Affects Versions: 1.1
Environment: Tested on CentOS, Tomcat6 and FOP 1.1rc1 service
Reporter: The BitSmith
Priority: Minor
Labels: http-headers, image
When I include an image, it is cached. So including a dynamic image shows
only the first version of the image. To prevent this, I have to add a
constantly changing parameter (called nonce here):
fo:external-graphic width=140mm height=30mm
content-width=scale-down-to-fit content-height=scale-down-to-fit
inline-progression-dimension.maximum=100% scaling=uniform
vertical-align=-50%
xsl:variable name=orgguid select=Organization/ID /
xsl:variable name=nonce select=Nonce /
xsl:variable name=logo
select=concat('http://localhost/images/fopimages/logo.php?orgid=', $orgguid,
'amp;dummy=', $nonce)/
xsl:attribute name=srcurl(xsl:value-of select=$logo/)/xsl:attribute
/fo:external-graphic
This happens despite the fact that the PHP script that produces the image
sends no-cache headers (PHP code):
header('Expires: Fri, 13 May 1983 18:30:00 GMT');
header('Last-Modified: ' . gmdate('D, d M Y H:i:s') . ' GMT');
header('Cache-Control: no-store, no-cache, must-revalidate'); // HTTP/1.1
header('Cache-Control: post-check=0, pre-check=0', FALSE);
header('Pragma: no-cache'); // HTTP/1.0
header('Content-Type: ' . $this-mstrLogoType);
header('Content-Length: ' . strlen($this-mmixLogoData));
header('Content-Disposition: inline');
header('X-Content-Type-Options: nosniff'); // Workaround for IE bug.
echo $this-mmixLogoData;
It would be nice if the image caching mechanism would abide these headers, so
workarounds like extra parameters are not necessary.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Reopened] (FOP-2341) Infinite loop when smaller used after error on inherited font-size
[ https://issues.apache.org/jira/browse/FOP-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Sancho reopened FOP-2341: Infinite loop when smaller used after error on inherited font-size Key: FOP-2341 URL: https://issues.apache.org/jira/browse/FOP-2341 Project: Fop Issue Type: Bug Components: general Affects Versions: 0.95, trunk Reporter: MOHD Priority: Critical Labels: font-size, infinite-loop, smaller Original Estimate: 1m Remaining Estimate: 1m My local FOP engine is hang when below scenario was occur. fo:block font-style=normal font-size=10mmpt role=html:div fo:inline baseline-shift=super font-size=smaller role=html:supth/fo:inlineof each month. /fo:block Please give some suggestion if any one has solution for this issue. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (FOP-2341) Infinite loop when smaller used after error on inherited font-size
[ https://issues.apache.org/jira/browse/FOP-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Sancho updated FOP-2341: --- Component/s: (was: rtf) general Affects Version/s: trunk Labels: font-size infinite-loop smaller (was: newbie) Summary: Infinite loop when smaller used after error on inherited font-size (was: FOP is hang and not able to generate RTF file) Ok, I see. Tried unsuccessfully with FOP trunk. smaller is fed with inherited font-size trait, witch rose an ERROR. Both smaller and larger behave in the same way. Infinite loop when smaller used after error on inherited font-size Key: FOP-2341 URL: https://issues.apache.org/jira/browse/FOP-2341 Project: Fop Issue Type: Bug Components: general Affects Versions: 0.95, trunk Reporter: MOHD Priority: Critical Labels: font-size, infinite-loop, smaller Original Estimate: 1m Remaining Estimate: 1m My local FOP engine is hang when below scenario was occur. fo:block font-style=normal font-size=10mmpt role=html:div fo:inline baseline-shift=super font-size=smaller role=html:supth/fo:inlineof each month. /fo:block Please give some suggestion if any one has solution for this issue. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (FOP-2341) Infinite loop when smaller used after error on inherited font-size
[ https://issues.apache.org/jira/browse/FOP-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Sancho updated FOP-2341: --- Attachment: _test.fo short FO test case that demonstrates the infinite-loop after ERROR Infinite loop when smaller used after error on inherited font-size Key: FOP-2341 URL: https://issues.apache.org/jira/browse/FOP-2341 Project: Fop Issue Type: Bug Components: general Affects Versions: 0.95, trunk Reporter: MOHD Priority: Critical Labels: font-size, infinite-loop, smaller Attachments: _test.fo Original Estimate: 1m Remaining Estimate: 1m My local FOP engine is hang when below scenario was occur. fo:block font-style=normal font-size=10mmpt role=html:div fo:inline baseline-shift=super font-size=smaller role=html:supth/fo:inlineof each month. /fo:block Please give some suggestion if any one has solution for this issue. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (FOP-2341) Infinite loop when smaller used after error on inherited font-size
[ https://issues.apache.org/jira/browse/FOP-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13897635#comment-13897635 ] Pascal Sancho edited comment on FOP-2341 at 2/11/14 8:40 AM: - Ok, I see. Tried unsuccessfully with FOP trunk. smaller is fed with inherited font-size trait, witch rose an ERROR. Both smaller and larger behave in the same way. Good catch, Mohd! was (Author: psancho): Ok, I see. Tried unsuccessfully with FOP trunk. smaller is fed with inherited font-size trait, witch rose an ERROR. Both smaller and larger behave in the same way. Infinite loop when smaller used after error on inherited font-size Key: FOP-2341 URL: https://issues.apache.org/jira/browse/FOP-2341 Project: Fop Issue Type: Bug Components: general Affects Versions: 0.95, trunk Reporter: MOHD Priority: Critical Labels: font-size, infinite-loop, smaller Attachments: _test.fo Original Estimate: 1m Remaining Estimate: 1m My local FOP engine is hang when below scenario was occur. fo:block font-style=normal font-size=10mmpt role=html:div fo:inline baseline-shift=super font-size=smaller role=html:supth/fo:inlineof each month. /fo:block Please give some suggestion if any one has solution for this issue. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (FOP-2341) Infinite loop when smaller used with a zero length font-size
[ https://issues.apache.org/jira/browse/FOP-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Sancho updated FOP-2341: --- Summary: Infinite loop when smaller used with a zero length font-size (was: Infinite loop when smaller used after error on inherited font-size) Infinite loop when smaller used with a zero length font-size --- Key: FOP-2341 URL: https://issues.apache.org/jira/browse/FOP-2341 Project: Fop Issue Type: Bug Components: general Affects Versions: 0.95, trunk Reporter: MOHD Priority: Critical Labels: font-size, infinite-loop, smaller Attachments: _test.fo Original Estimate: 1m Remaining Estimate: 1m My local FOP engine is hang when below scenario was occur. fo:block font-style=normal font-size=10mmpt role=html:div fo:inline baseline-shift=super font-size=smaller role=html:supth/fo:inlineof each month. /fo:block Please give some suggestion if any one has solution for this issue. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (FOP-2341) FOP is hang and not able to generate RTF file
[
https://issues.apache.org/jira/browse/FOP-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Sancho resolved FOP-2341.
Resolution: Not A Problem
Fix Version/s: (was: 0.95)
Hi,
please, for FOP usage question, ask 1st on appropriate mailing list (see [1]).
That said, in your snippet there is a mismatch:
{code}
font-size=10mmpt
{code}
will throw (FOP output):
{code}
[ERROR] PropertyMaker - Unknown length unit 'mmpt'
{code}
[1] http://xmlgraphics.apache.org/fop/gethelp.html
FOP is hang and not able to generate RTF file
--
Key: FOP-2341
URL: https://issues.apache.org/jira/browse/FOP-2341
Project: Fop
Issue Type: Bug
Components: rtf
Affects Versions: 0.95
Reporter: MOHD
Priority: Critical
Labels: newbie
Original Estimate: 1m
Remaining Estimate: 1m
My local FOP engine is hang when below scenario was occur.
fo:block font-style=normal font-size=10mmpt role=html:div
fo:inline baseline-shift=super font-size=smaller
role=html:supth/fo:inlineof each month.
/fo:block
Please give some suggestion if any one has solution for this issue.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (FOP-2335) Content is missing after IPD change
[ https://issues.apache.org/jira/browse/FOP-2335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Sancho updated FOP-2335: --- Summary: Content is missing after IPD change (was: Content is missing when rendering attached fo file) This seems to be caused by changing IPD of region-body, when the generated area overflows the first region-body. When resulting IPD are equals (after millipoint conversion), or when inserting a page-break before the issued area, the issue disappears. Content is missing after IPD change --- Key: FOP-2335 URL: https://issues.apache.org/jira/browse/FOP-2335 Project: Fop Issue Type: Bug Components: page-master/layout Affects Versions: trunk Reporter: Matthias Reischenbacher Priority: Critical Attachments: fop-2335-sample-file.fo When rendering the attached fo file, the second page is missing. Changing the page-master and/or region-body margins makes the second page appear. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (FOP-2318) [PATCH] Caching FontInfo class/constructors in AbstractFOPBridgeContext
[ https://issues.apache.org/jira/browse/FOP-2318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Sancho updated FOP-2318: --- Summary: [PATCH] Caching FontInfo class/constructors in AbstractFOPBridgeContext (was: Caching FontInfo class/constructors in AbstractFOPBridgeContext) [PATCH] Caching FontInfo class/constructors in AbstractFOPBridgeContext --- Key: FOP-2318 URL: https://issues.apache.org/jira/browse/FOP-2318 Project: Fop Issue Type: Improvement Components: fonts, svg Affects Versions: trunk Environment: Tested on Mac OSX 10.9, Java SE 7 (1.7.0_04) Reporter: Gonzalo Vasquez Priority: Minor Labels: perfomance Attachments: AbstractFOPBridgeContext.patch This my second performance oriented patch, that also improves a little more document generation speed. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (FOP-1342) [PATCH] Incorrect rendering of GIF images
[ https://issues.apache.org/jira/browse/FOP-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Sancho updated FOP-1342: --- Priority: Blocker Summary: [PATCH] Incorrect rendering of GIF images (was: Incorrect rendering of GIF images) [PATCH] Incorrect rendering of GIF images - Key: FOP-1342 URL: https://issues.apache.org/jira/browse/FOP-1342 Project: Fop Issue Type: Bug Components: images Affects Versions: trunk Environment: Operating System: other Platform: Other Reporter: Trejkaz Priority: Blocker Attachments: fop-gif-scaling-bug.zip, imageio-size-fix.patch, scale.patch Attached zip file contains an example with a single GIF, which exhibits two problems: 1. the GIF is scaled in a strange fashion, and 2. the black lines are lost. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (FOP-1801) [PATCH] conversion BW GIF=PDF creates PDF with colorspace RGB if FOP0.95 and Gray if FOP0.20.5
[ https://issues.apache.org/jira/browse/FOP-1801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Sancho updated FOP-1801: --- Priority: Blocker Summary: [PATCH] conversion BW GIF=PDF creates PDF with colorspace RGB if FOP0.95 and Gray if FOP0.20.5 (was: conversion BW GIF=PDF creates PDF with colorspace RGB if FOP0.95 and Gray if FOP0.20.5) [PATCH] conversion BW GIF=PDF creates PDF with colorspace RGB if FOP0.95 and Gray if FOP0.20.5 Key: FOP-1801 URL: https://issues.apache.org/jira/browse/FOP-1801 Project: Fop Issue Type: Bug Components: awt renderer Affects Versions: 0.95 Environment: Operating System: Linux Platform: Other Reporter: Isidora Priority: Blocker Attachments: fop.patch, test.fo, weather.gif, xgc.patch Even though the PDFs obtained with both FOP versions look and print OK, when the one created with 0.95 is pushed through the FAX system, the image obtained contains dotted areas that correspond to white areas in the PDF created with 0.20.5. I posted the question to FOP forum and Jeremias Maerki helped me research the issue. If the PDF with problems is manipulated by : changing /ColorSpace [/Indexed /DeviceRGB 1 FF00] to: /ColorSpace [/Indexed /DeviceGray 1 FF00 the dotted areas go back to be white areas. i.e. the problem is resolved by this change When I asked him if I could make this change in colorspace from inside my XSL-FO he responded: If you want this kind of functionality, it has to be fixed in Java code first.If you want to give this a try, the place to fix this is: org.apache.fop.render.pdf.ImageRenderedAdapter.populateXObjectDictionary(PDFDictionary) There, a check has to be implemented to see if all palette entries are plain grayscale values (red, green and blue all the same) in which case /DeviceGray can be specified instead of /DeviceRGB. And of course, the palette entries need to be 8bit rather than 24bits then. My expertise in manipulating colors and graphics is not big enough for me to make changes to this code. So, I hope someone with more knowledge could fix this bug. Thank you -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (FOP-916) [PATCH] URL in basic-link is scrambled by encryption
[ https://issues.apache.org/jira/browse/FOP-916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Sancho updated FOP-916: -- Priority: Blocker Summary: [PATCH] URL in basic-link is scrambled by encryption (was: URL in basic-link is scrambled by encryption) [PATCH] URL in basic-link is scrambled by encryption Key: FOP-916 URL: https://issues.apache.org/jira/browse/FOP-916 Project: Fop Issue Type: Bug Components: pdf Affects Versions: trunk Environment: Operating System: other Platform: PC Reporter: Hans Benedict Priority: Blocker Attachments: simple-noprint.pdf, simple-unencrypted.pdf, simple.xml, simple.xsl, trunkencryptionlink.patch When I process a document with a tag fo:basic-link external-destination=whateversometext/fo:basic-link the link in the resulting pdf points to something that I presume is the *encrypted* URL. This of course doesn't work. I am using JDK 1.4.2 on linux and the Bouncy Castle crypto provider version 1.24. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (FOP-2315) [PATCH] Incorrect example for leaders (leader.fo)
[ https://issues.apache.org/jira/browse/FOP-2315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Sancho updated FOP-2315: --- Summary: [PATCH] Incorrect example for leaders (leader.fo) (was: Incorrect example for leaders (leader.fo)) [PATCH] Incorrect example for leaders (leader.fo) - Key: FOP-2315 URL: https://issues.apache.org/jira/browse/FOP-2315 Project: Fop Issue Type: Bug Components: documentation Affects Versions: trunk Environment: Any Reporter: Alexey Neyman Priority: Trivial Attachments: leader-example.diff One of the examples in leader.fo does not have text-align-last=justify property set/inherited, resulting in weird leaders (with just a single dot). -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (FOP-2308) text-transform=capitalize assumes input text is lowercase
[
https://issues.apache.org/jira/browse/FOP-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13808854#comment-13808854
]
Pascal Sancho commented on FOP-2308:
Luis, I agree with Alexey's comment.
{quote}
In any case, give me an example where that behavior is desirable and may revert
the change. If I want to capitalize a title, uppercasing the first letter and
lowercasing the others seems reasonable.
{quote}
I do have a use case:
using Capitalize on text that contains uppercase acronym should not affect
it, and should leave it as uppercase.
See our web site, the acronym FOP is used everywhere, and still remains
uppercased...
text-transform=capitalize assumes input text is lowercase
---
Key: FOP-2308
URL: https://issues.apache.org/jira/browse/FOP-2308
Project: Fop
Issue Type: Bug
Reporter: Luis Bernardo
Fix For: trunk
Attachments: test.fo
fo:block text-transform=capitalizeCAPITALIZE/fo:block should output
Capitalize, not CAPITALIZE as it does currently.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (FOP-2308) text-transform=capitalize assumes input text is lowercase
[
https://issues.apache.org/jira/browse/FOP-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13808868#comment-13808868
]
Pascal Sancho commented on FOP-2308:
{quote}
by the same token text-transform=lowercase should not lowercase an acronym,
right?
{quote}
Yes, that should. In orthotypography [1], there is a difference between
uppercase (french: Capitale) and Capitale (french: Majuscule).
In short: the former is related to style (layout), the latter is related to
content.
So, if the acronym is written with Capitales (french: Majuscules), those
letters should remain Capitales (french: Majuscules), and be not affected by
lowercase (french: bas de case).
But I don't know any keyboard that allow such subtle difference
[1] http://www.carlosdetoro.com/2013/05/22/orthotypography-what-is-it/
text-transform=capitalize assumes input text is lowercase
---
Key: FOP-2308
URL: https://issues.apache.org/jira/browse/FOP-2308
Project: Fop
Issue Type: Bug
Reporter: Luis Bernardo
Fix For: trunk
Attachments: test.fo
fo:block text-transform=capitalizeCAPITALIZE/fo:block should output
Capitalize, not CAPITALIZE as it does currently.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (FOP-1444) PDF table of contents generated with incorrect page number alignments
[ https://issues.apache.org/jira/browse/FOP-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13796512#comment-13796512 ] Pascal Sancho commented on FOP-1444: To Alexey: the cited thread was about extra spaces that were taken into account, witch was unexpected; the current issue was related to FOP design, IIRC regarding area reservation for page-number-citation, witch content (i.e. the page number) is computed later after the area construction. The rendering is better with latest releases, but issue still persists in FOP 1.1. PDF table of contents generated with incorrect page number alignments - Key: FOP-1444 URL: https://issues.apache.org/jira/browse/FOP-1444 Project: Fop Issue Type: Bug Components: pdf Affects Versions: 0.94 Environment: Operating System: Windows XP Platform: PC Reporter: David H. Gutteridge Attachments: FOP_TOC_Bug_Test.dbk, FOP_TOC_Bug_Test.fo, FOP_TOC_Bug_Test.pdf It seems there's a threshold where FOP does not align page number references correctly when generating tables of contents in PDF documents. I see that you have a reference to this in your FAQ (question 3.10), but it says The most recent FOP releases should have this problem fixed, I'm seeing this problem with 0.94. (I have a sample FO document I will attach, looks like the initial bug reporting interface doesn't let me do this.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (FOP-1444) PDF table of contents generated with incorrect page number alignments
[ https://issues.apache.org/jira/browse/FOP-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Sancho updated FOP-1444: --- Affects Version/s: 0.95 PDF table of contents generated with incorrect page number alignments - Key: FOP-1444 URL: https://issues.apache.org/jira/browse/FOP-1444 Project: Fop Issue Type: Bug Components: pdf Affects Versions: 0.94, trunk Environment: Operating System: Windows XP Platform: PC Reporter: David H. Gutteridge Attachments: FOP_TOC_Bug_Test.dbk, FOP_TOC_Bug_Test.fo, FOP_TOC_Bug_Test.pdf It seems there's a threshold where FOP does not align page number references correctly when generating tables of contents in PDF documents. I see that you have a reference to this in your FAQ (question 3.10), but it says The most recent FOP releases should have this problem fixed, I'm seeing this problem with 0.94. (I have a sample FO document I will attach, looks like the initial bug reporting interface doesn't let me do this.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Comment Edited] (FOP-1444) PDF table of contents generated with incorrect page number alignments
[ https://issues.apache.org/jira/browse/FOP-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13796512#comment-13796512 ] Pascal Sancho edited comment on FOP-1444 at 10/16/13 7:47 AM: -- To Alexey: the cited thread was about extra spaces that were taken into account, witch was unexpected; the current issue was related to FOP design, IIRC regarding area reservation for page-number-citation, witch content (i.e. the page number) is computed later after the area construction. The rendering is better with latest releases, but issue still persists in trunk post FOP 1.1. was (Author: psancho): To Alexey: the cited thread was about extra spaces that were taken into account, witch was unexpected; the current issue was related to FOP design, IIRC regarding area reservation for page-number-citation, witch content (i.e. the page number) is computed later after the area construction. The rendering is better with latest releases, but issue still persists in FOP 1.1. PDF table of contents generated with incorrect page number alignments - Key: FOP-1444 URL: https://issues.apache.org/jira/browse/FOP-1444 Project: Fop Issue Type: Bug Components: pdf Affects Versions: 0.94, trunk Environment: Operating System: Windows XP Platform: PC Reporter: David H. Gutteridge Attachments: FOP_TOC_Bug_Test.dbk, FOP_TOC_Bug_Test.fo, FOP_TOC_Bug_Test.pdf It seems there's a threshold where FOP does not align page number references correctly when generating tables of contents in PDF documents. I see that you have a reference to this in your FAQ (question 3.10), but it says The most recent FOP releases should have this problem fixed, I'm seeing this problem with 0.94. (I have a sample FO document I will attach, looks like the initial bug reporting interface doesn't let me do this.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (FOP-1444) PDF table of contents generated with incorrect page number alignments
[ https://issues.apache.org/jira/browse/FOP-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Sancho updated FOP-1444: --- Affects Version/s: (was: 0.95) trunk PDF table of contents generated with incorrect page number alignments - Key: FOP-1444 URL: https://issues.apache.org/jira/browse/FOP-1444 Project: Fop Issue Type: Bug Components: pdf Affects Versions: 0.94, trunk Environment: Operating System: Windows XP Platform: PC Reporter: David H. Gutteridge Attachments: FOP_TOC_Bug_Test.dbk, FOP_TOC_Bug_Test.fo, FOP_TOC_Bug_Test.pdf It seems there's a threshold where FOP does not align page number references correctly when generating tables of contents in PDF documents. I see that you have a reference to this in your FAQ (question 3.10), but it says The most recent FOP releases should have this problem fixed, I'm seeing this problem with 0.94. (I have a sample FO document I will attach, looks like the initial bug reporting interface doesn't let me do this.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (FOP-2293) Whitespace management extension
[
https://issues.apache.org/jira/browse/FOP-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13782869#comment-13782869
]
Pascal Sancho commented on FOP-2293:
{quote}
By adding some fox:fitting-strategy property to fo:multi-switch, we are moving
away from its mere function of listing possibilities, and we are adding
selection semantics. I reckon this violates the (spirit of the) Recommendation,
that gives one function and only one to an element.
{quote}
I do not share your point of view, the Recommendation being quite imprecise,
just giving limited (non-realist) use-case.
But I want to see this extension implemented, so your syntactic proposal sounds
good for me.
Whitespace management extension
---
Key: FOP-2293
URL: https://issues.apache.org/jira/browse/FOP-2293
Project: Fop
Issue Type: New Feature
Components: general
Affects Versions: trunk
Reporter: Seifeddine Dridi
Priority: Minor
Labels: XSL-FO
Fix For: trunk
Attachments: bestfit.fo, doc.pdf, FO_multi-switch.patch,
FO_multi-switch_test.fo, multiple-feasible-nodes.fo, multi-switch_bestfit.fo,
patch.patch, patch-rev1.1.patch, patch-rev1.patch, patch-rev2.patch
I have been working on an extension for whitespace management, similar to
what's described here:
http://wiki.apache.org/xmlgraphics-fop/WhitespaceManagement
The logic of the extension is very simple: the user defines a set of
alternatives that he wishes to insert at the end of a page, then if there is
enough space left, FOP will pick the alternative that best matches the user's
selection criteria (first fit, smallest fit, biggest fit).
This is my first work on FOP and it took me almost 2 months to reach this
stage in development. But it's not the end of course, so I'm relying on your
feedback to improve it.
Thank you
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (FOP-2293) Whitespace management extension
[ https://issues.apache.org/jira/browse/FOP-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13783049#comment-13783049 ] Pascal Sancho commented on FOP-2293: Despite of different interpretations of REC, in fine we have 2 alternatives to define the toggle mechanic: - use only fox attributes - use fox element. From userland, the attribute based approach seems more appropriate: - replace all fo:multi-toggle with only one fox attribute - at a glance, the user can understand what is the present role the multi-switch - all fox material is in the same location, and fox overload is minimal. Internally, I've not investigated to know what approach is the best one. I definitively prefer the only-attribute approach, but I will follow the general consensus (if any...) Whitespace management extension --- Key: FOP-2293 URL: https://issues.apache.org/jira/browse/FOP-2293 Project: Fop Issue Type: New Feature Components: general Affects Versions: trunk Reporter: Seifeddine Dridi Priority: Minor Labels: XSL-FO Fix For: trunk Attachments: bestfit.fo, doc.pdf, FO_multi-switch.patch, FO_multi-switch_test.fo, multiple-feasible-nodes.fo, multi-switch_bestfit.fo, patch.patch, patch-rev1.1.patch, patch-rev1.patch, patch-rev2.patch I have been working on an extension for whitespace management, similar to what's described here: http://wiki.apache.org/xmlgraphics-fop/WhitespaceManagement The logic of the extension is very simple: the user defines a set of alternatives that he wishes to insert at the end of a page, then if there is enough space left, FOP will pick the alternative that best matches the user's selection criteria (first fit, smallest fit, biggest fit). This is my first work on FOP and it took me almost 2 months to reach this stage in development. But it's not the end of course, so I'm relying on your feedback to improve it. Thank you -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (FOP-2293) Whitespace management extension
[ https://issues.apache.org/jira/browse/FOP-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Sancho updated FOP-2293: --- Attachment: multi-switch_bestfit.fo Regarding your latest test.fo case, I don't understand how you plan to add the whitespace management extension. IIUC, and based on GA suggestion, I've imagined something like that: - use a fo:multi-switch structure, with some fo:multi-case - add the fox:fitting-strategy attribute directly on fo:multi-switch element - use fo:multi-toggle only if needed by extension implementation, i.e. adding either a new fox:atttribute, or a new fox:value for the switch-to attribute; this addition aiming to indicate witch strategy is used. This is illustrated in the proposed FO file, with 3 alternatives: case 1: without fo:multi-toggle case 2: with fo:multi-toggle and new attribute fox:auto-switch case 3: with fo:multi-toggle and new value fox:bestfit for attribute switch-to the 3rd case breaks the REC conformance, so I don't like it. Whitespace management extension --- Key: FOP-2293 URL: https://issues.apache.org/jira/browse/FOP-2293 Project: Fop Issue Type: New Feature Components: general Affects Versions: trunk Reporter: Seifeddine Dridi Priority: Minor Labels: XSL-FO Fix For: trunk Attachments: bestfit.fo, doc.pdf, FO_multi-switch.patch, FO_multi-switch_test.fo, multiple-feasible-nodes.fo, multi-switch_bestfit.fo, patch.patch, patch-rev1.1.patch, patch-rev1.patch, patch-rev2.patch I have been working on an extension for whitespace management, similar to what's described here: http://wiki.apache.org/xmlgraphics-fop/WhitespaceManagement The logic of the extension is very simple: the user defines a set of alternatives that he wishes to insert at the end of a page, then if there is enough space left, FOP will pick the alternative that best matches the user's selection criteria (first fit, smallest fit, biggest fit). This is my first work on FOP and it took me almost 2 months to reach this stage in development. But it's not the end of course, so I'm relying on your feedback to improve it. Thank you -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (FOP-2293) Whitespace management extension
[ https://issues.apache.org/jira/browse/FOP-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13781803#comment-13781803 ] Pascal Sancho commented on FOP-2293: I had a private discussion with Vincent and we agreed that it is best to implement FOX best-fit as a new element NOT a property of FO multi-switch. I'm still open to more suggestions, though. Didn't know that. public debates should remain public... I'm not convinced on why new fox element is better than new fox attribute. See prepress extension, it only add new fox attributes. And IMHO, as GA pointed it, multi-switch goals cover the needs of best-fit extension; it just lakes some mechanism that extension should provide. In my opinion, best-fit is not the same as multi-toggle, the latter acts on a single multi-case while the former has to process the list of multi-case(s) at once, so it doesn't make much sense to put it into the switch-to property. I agree on that, switch-to property should remain as what described in REC. That why I propose the 2nd case: new fox property. That said, the most important is to have a working extension, implementing it in one or alternate way remains a background question. WDYT? Whitespace management extension --- Key: FOP-2293 URL: https://issues.apache.org/jira/browse/FOP-2293 Project: Fop Issue Type: New Feature Components: general Affects Versions: trunk Reporter: Seifeddine Dridi Priority: Minor Labels: XSL-FO Fix For: trunk Attachments: bestfit.fo, doc.pdf, FO_multi-switch.patch, FO_multi-switch_test.fo, multiple-feasible-nodes.fo, multi-switch_bestfit.fo, patch.patch, patch-rev1.1.patch, patch-rev1.patch, patch-rev2.patch I have been working on an extension for whitespace management, similar to what's described here: http://wiki.apache.org/xmlgraphics-fop/WhitespaceManagement The logic of the extension is very simple: the user defines a set of alternatives that he wishes to insert at the end of a page, then if there is enough space left, FOP will pick the alternative that best matches the user's selection criteria (first fit, smallest fit, biggest fit). This is my first work on FOP and it took me almost 2 months to reach this stage in development. But it's not the end of course, so I'm relying on your feedback to improve it. Thank you -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (FOP-2293) Whitespace management extension
[
https://issues.apache.org/jira/browse/FOP-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13781843#comment-13781843
]
Pascal Sancho commented on FOP-2293:
{quote}
Me neither. However, it is not optimal to create a new element when there is
already an element with the same semantics. In such case, adding an extension
property would be best.
{quote}
hehe,
so, I reiterate my proposition:
{code:xml}
fo:multi-switch fox:fitting-strategy=biggest-fit
fo:multi-case case-name=case1 starting-state=show
fo:multi-toggle fox:auto-switch=bestfit/
fo:blockCase 1/fo:block
/fo:multi-case
fo:multi-case case-name=case2 starting-state=hide
fo:multi-toggle fox:auto-switch=bestfit/
fo:blockCase 2/fo:block
/fo:multi-case
/fo:multi-switch
{code}
Whitespace management extension
---
Key: FOP-2293
URL: https://issues.apache.org/jira/browse/FOP-2293
Project: Fop
Issue Type: New Feature
Components: general
Affects Versions: trunk
Reporter: Seifeddine Dridi
Priority: Minor
Labels: XSL-FO
Fix For: trunk
Attachments: bestfit.fo, doc.pdf, FO_multi-switch.patch,
FO_multi-switch_test.fo, multiple-feasible-nodes.fo, multi-switch_bestfit.fo,
patch.patch, patch-rev1.1.patch, patch-rev1.patch, patch-rev2.patch
I have been working on an extension for whitespace management, similar to
what's described here:
http://wiki.apache.org/xmlgraphics-fop/WhitespaceManagement
The logic of the extension is very simple: the user defines a set of
alternatives that he wishes to insert at the end of a page, then if there is
enough space left, FOP will pick the alternative that best matches the user's
selection criteria (first fit, smallest fit, biggest fit).
This is my first work on FOP and it took me almost 2 months to reach this
stage in development. But it's not the end of course, so I'm relying on your
feedback to improve it.
Thank you
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Comment Edited] (FOP-2293) Whitespace management extension
[
https://issues.apache.org/jira/browse/FOP-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13781894#comment-13781894
]
Pascal Sancho edited comment on FOP-2293 at 9/30/13 2:50 PM:
-
It seems that we need 2 properties:
- one for auto-toggling
- one for fitting strategy
{code:xml}
fo:multi-switch fox:auto-toggle=best-fit fox:fitting-strategy=biggest-fit
fo:multi-case starting-state=show
fo:blockCase 1/fo:block
/fo:multi-case
fo:multi-case starting-state=hide
fo:blockCase 2/fo:block
/fo:multi-case
/fo:multi-switch
{code}
was (Author: psancho):
It seems that we need 2 properties:
- one for auto-toggling
- one for fitting strategy
{code:xml}
fo:multi-switch fox:auto-toggle=best-fit fox:fitting-strategy=biggest-fit
fo:multi-case case-name=case1 starting-state=show
fo:blockCase 1/fo:block
/fo:multi-case
fo:multi-case case-name=case2 starting-state=hide
fo:blockCase 2/fo:block
/fo:multi-case
/fo:multi-switch
{code}
Whitespace management extension
---
Key: FOP-2293
URL: https://issues.apache.org/jira/browse/FOP-2293
Project: Fop
Issue Type: New Feature
Components: general
Affects Versions: trunk
Reporter: Seifeddine Dridi
Priority: Minor
Labels: XSL-FO
Fix For: trunk
Attachments: bestfit.fo, doc.pdf, FO_multi-switch.patch,
FO_multi-switch_test.fo, multiple-feasible-nodes.fo, multi-switch_bestfit.fo,
patch.patch, patch-rev1.1.patch, patch-rev1.patch, patch-rev2.patch
I have been working on an extension for whitespace management, similar to
what's described here:
http://wiki.apache.org/xmlgraphics-fop/WhitespaceManagement
The logic of the extension is very simple: the user defines a set of
alternatives that he wishes to insert at the end of a page, then if there is
enough space left, FOP will pick the alternative that best matches the user's
selection criteria (first fit, smallest fit, biggest fit).
This is my first work on FOP and it took me almost 2 months to reach this
stage in development. But it's not the end of course, so I'm relying on your
feedback to improve it.
Thank you
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (FOP-2106) [PATCH] docbook footnote and body text overlap (example fo file included)
[ https://issues.apache.org/jira/browse/FOP-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Sancho updated FOP-2106: --- Priority: Blocker Summary: [PATCH] docbook footnote and body text overlap (example fo file included) (was: docbook footnote and body text overlap (example fo file included)) [PATCH] docbook footnote and body text overlap (example fo file included) - Key: FOP-2106 URL: https://issues.apache.org/jira/browse/FOP-2106 Project: Fop Issue Type: Bug Components: page-master/layout Affects Versions: 1.0 Environment: Operating System: Linux Platform: PC Reporter: Petter Reinholdtsen Priority: Blocker Attachments: bad-footnote.fo, fop-2106.diff, fop-2106.diff I discovered this problem with the fop backend of xmlto when using it to create a PDF. The docbook document in question is rather large, but I managed to extract an except demonstrating the problem. The problem is that the footnote text and the body text overlap. I initially reported it to Debian as URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683197 but thought it best to report it here too. The docbook source and the generated PDF is attached to the Debian bug report. Notice in the example how the text of the footnote on the second to last page is overlapping with the body. I generated the PDF using this command: xmlto --noautosize -m xmlto-pdf.xsl --with-fop pdf bad-footnote.xml The full document set is available from URL: https://github.com/petterreinholdtsen/free-culture-lessig , if you want to check it out. When I investigated some more, I concluded that the problem is with the fop processor, not xmlto. The problem exist in both fop versions 1:0.95.dfsg-11 and 1:1.0.dfsg2-6 in Debian. The fo code generated by xmlto include the footnote content as it should, and when I manually process the .fo file using fop, the resulting PDF have the overlapping text. I am attaching the .fo file I used to test this, to allow you to reproduce the problem and try to find a fix. :) Could this be the same problem reported in URL: https://issues.apache.org/bugzilla/show_bug.cgi?id=51304 This issue make fop useless for making the PDF version of the Free Culture book. :( -- 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-2293) Whitespace management extension
[ https://issues.apache.org/jira/browse/FOP-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13770777#comment-13770777 ] Pascal Sancho commented on FOP-2293: Hi, [1] REC XSL-FO 1.1, §6.9.3 - fo:multi-switch: The user may switch between the available multi-cases. Each fo:multi-case may contain one or more fo:multi-toggle objects, which controls the fo:multi-case switching of the fo:multi-switch. IIUC, fo:multi-toggle should be used for responding to user action. So, if the selection is made by the user agent (FOP), there is no user action; fo:multi-toggle is not usefull if fox:fitting-strategy is explicitly used on fo:multi-switch. [1] http://www.w3.org/TR/xsl/#fo_multi-switch Whitespace management extension --- Key: FOP-2293 URL: https://issues.apache.org/jira/browse/FOP-2293 Project: Fop Issue Type: New Feature Components: general Affects Versions: trunk Reporter: Seifeddine Dridi Priority: Minor Labels: XSL-FO Fix For: trunk Attachments: bestfit.fo, doc.pdf, multiple-feasible-nodes.fo, patch.patch, patch-rev1.1.patch, patch-rev1.patch, patch-rev2.patch I have been working on an extension for whitespace management, similar to what's described here: http://wiki.apache.org/xmlgraphics-fop/WhitespaceManagement The logic of the extension is very simple: the user defines a set of alternatives that he wishes to insert at the end of a page, then if there is enough space left, FOP will pick the alternative that best matches the user's selection criteria (first fit, smallest fit, biggest fit). This is my first work on FOP and it took me almost 2 months to reach this stage in development. But it's not the end of course, so I'm relying on your feedback to improve it. Thank you -- 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-2293) Whitespace management extension
[ https://issues.apache.org/jira/browse/FOP-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13761905#comment-13761905 ] Pascal Sancho commented on FOP-2293: I agree with GA's perspective, it seems quite elegant to me. perhaps this option needs a wider consensus from FOP team? I'll vote +1. Whitespace management extension --- Key: FOP-2293 URL: https://issues.apache.org/jira/browse/FOP-2293 Project: Fop Issue Type: New Feature Components: general Affects Versions: trunk Reporter: Seifeddine Dridi Priority: Minor Labels: XSL-FO Fix For: trunk Attachments: bestfit.fo, doc.pdf, multiple-feasible-nodes.fo, patch.patch, patch-rev1.1.patch, patch-rev1.patch I have been working on an extension for whitespace management, similar to what's described here: http://wiki.apache.org/xmlgraphics-fop/WhitespaceManagement The logic of the extension is very simple: the user defines a set of alternatives that he wishes to insert at the end of a page, then if there is enough space left, FOP will pick the alternative that best matches the user's selection criteria (first fit, smallest fit, biggest fit). This is my first work on FOP and it took me almost 2 months to reach this stage in development. But it's not the end of course, so I'm relying on your feedback to improve it. Thank you -- 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-2293) Whitespace management extension
[ https://issues.apache.org/jira/browse/FOP-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13758866#comment-13758866 ] Pascal Sancho commented on FOP-2293: Regarding your suggestion Pascal, do I have to define the fitting-strategy property twice in FOPropertyMapping? One with the fox namespace and an other without it. This is outside my knowlegde; I guess you should handle the 2 cases. In current fop extensions, I see no examples that have the double scope (inside/outside fox element). But there are some examples for the 2 cases: FOX attribute inside a FOX namespace element: fox:destination/@internal-destination FOX attribute inside a non-FOX namespace element: @fox:transform, all prepress atributes HTH. Whitespace management extension --- Key: FOP-2293 URL: https://issues.apache.org/jira/browse/FOP-2293 Project: Fop Issue Type: New Feature Components: general Affects Versions: trunk Reporter: Seifeddine Dridi Priority: Minor Labels: XSL-FO Fix For: trunk Attachments: bestfit.fo, doc.pdf, multiple-feasible-nodes.fo, patch.patch, patch-rev1.1.patch, patch-rev1.patch I have been working on an extension for whitespace management, similar to what's described here: http://wiki.apache.org/xmlgraphics-fop/WhitespaceManagement The logic of the extension is very simple: the user defines a set of alternatives that he wishes to insert at the end of a page, then if there is enough space left, FOP will pick the alternative that best matches the user's selection criteria (first fit, smallest fit, biggest fit). This is my first work on FOP and it took me almost 2 months to reach this stage in development. But it's not the end of course, so I'm relying on your feedback to improve it. Thank you -- 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-2293) Whitespace management extension
[ https://issues.apache.org/jira/browse/FOP-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13758871#comment-13758871 ] Pascal Sancho commented on FOP-2293: since the fitting-strategy property is meant to be used on a fox element only, it shouldn’t be put in the fox namespace. So, there is no need to handle the case when @fox:fitting-strategy is used on FO element. Whitespace management extension --- Key: FOP-2293 URL: https://issues.apache.org/jira/browse/FOP-2293 Project: Fop Issue Type: New Feature Components: general Affects Versions: trunk Reporter: Seifeddine Dridi Priority: Minor Labels: XSL-FO Fix For: trunk Attachments: bestfit.fo, doc.pdf, multiple-feasible-nodes.fo, patch.patch, patch-rev1.1.patch, patch-rev1.patch I have been working on an extension for whitespace management, similar to what's described here: http://wiki.apache.org/xmlgraphics-fop/WhitespaceManagement The logic of the extension is very simple: the user defines a set of alternatives that he wishes to insert at the end of a page, then if there is enough space left, FOP will pick the alternative that best matches the user's selection criteria (first fit, smallest fit, biggest fit). This is my first work on FOP and it took me almost 2 months to reach this stage in development. But it's not the end of course, so I'm relying on your feedback to improve it. Thank you -- 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-2293) Whitespace management extension
[ https://issues.apache.org/jira/browse/FOP-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13758866#comment-13758866 ] Pascal Sancho edited comment on FOP-2293 at 9/5/13 8:01 AM: Regarding your suggestion Pascal, do I have to define the fitting-strategy property twice in FOPropertyMapping? One with the fox namespace and an other without it. This is outside my knowlegde; I guess you should handle the 2 cases. In current fop extensions, I see no examples that have the double scope (inside/outside fox element). But there are some examples for the 2 cases: FOX attribute inside a FOX namespace element: fox:destination/@internal-destination FOX attribute inside a non-FOX namespace element: @fox:transform, all prepress attributes HTH. was (Author: psancho): Regarding your suggestion Pascal, do I have to define the fitting-strategy property twice in FOPropertyMapping? One with the fox namespace and an other without it. This is outside my knowlegde; I guess you should handle the 2 cases. In current fop extensions, I see no examples that have the double scope (inside/outside fox element). But there are some examples for the 2 cases: FOX attribute inside a FOX namespace element: fox:destination/@internal-destination FOX attribute inside a non-FOX namespace element: @fox:transform, all prepress atributes HTH. Whitespace management extension --- Key: FOP-2293 URL: https://issues.apache.org/jira/browse/FOP-2293 Project: Fop Issue Type: New Feature Components: general Affects Versions: trunk Reporter: Seifeddine Dridi Priority: Minor Labels: XSL-FO Fix For: trunk Attachments: bestfit.fo, doc.pdf, multiple-feasible-nodes.fo, patch.patch, patch-rev1.1.patch, patch-rev1.patch I have been working on an extension for whitespace management, similar to what's described here: http://wiki.apache.org/xmlgraphics-fop/WhitespaceManagement The logic of the extension is very simple: the user defines a set of alternatives that he wishes to insert at the end of a page, then if there is enough space left, FOP will pick the alternative that best matches the user's selection criteria (first fit, smallest fit, biggest fit). This is my first work on FOP and it took me almost 2 months to reach this stage in development. But it's not the end of course, so I'm relying on your feedback to improve it. Thank you -- 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-2293) Whitespace management extension
[ https://issues.apache.org/jira/browse/FOP-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13757528#comment-13757528 ] Pascal Sancho commented on FOP-2293: What you have said is true Pascal but extension properties in FOP are defined separately regardless of their host element (see FOPropertyMapping). Well, in that case the presence/absence of explicit namespace for an attribute depends on the namespace of the element carrier: if namespace are the same, then the namespace must be omitted for the attribute if namespace are different, then the namespace must be explicitly set for the attribute See the use-attribute-sets usage inside or outside the xsl namespace: xsl:attribute-set name=mySet use-attribute-sets=hisSet/ Vs fo:block xsl:use-attribute-sets=hisSet/ Whitespace management extension --- Key: FOP-2293 URL: https://issues.apache.org/jira/browse/FOP-2293 Project: Fop Issue Type: New Feature Components: general Affects Versions: trunk Reporter: Seifeddine Dridi Priority: Minor Labels: XSL-FO Fix For: trunk Attachments: bestfit.fo, doc.pdf, multiple-feasible-nodes.fo, patch.patch, patch-rev1.1.patch, patch-rev1.patch I have been working on an extension for whitespace management, similar to what's described here: http://wiki.apache.org/xmlgraphics-fop/WhitespaceManagement The logic of the extension is very simple: the user defines a set of alternatives that he wishes to insert at the end of a page, then if there is enough space left, FOP will pick the alternative that best matches the user's selection criteria (first fit, smallest fit, biggest fit). This is my first work on FOP and it took me almost 2 months to reach this stage in development. But it's not the end of course, so I'm relying on your feedback to improve it. Thank you -- 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-2293) Whitespace management extension
[ https://issues.apache.org/jira/browse/FOP-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13757790#comment-13757790 ] Pascal Sancho commented on FOP-2293: ok, in short: fitting-strategy IS a FOX namespaced attribute. When used on a FOX namespaced element,the fox: prefix must be ommitted; when used on an FO namespaced element, the fox: prefix must be explicitely used; AFAICK, no new attribute is added in FO namespace. Whitespace management extension --- Key: FOP-2293 URL: https://issues.apache.org/jira/browse/FOP-2293 Project: Fop Issue Type: New Feature Components: general Affects Versions: trunk Reporter: Seifeddine Dridi Priority: Minor Labels: XSL-FO Fix For: trunk Attachments: bestfit.fo, doc.pdf, multiple-feasible-nodes.fo, patch.patch, patch-rev1.1.patch, patch-rev1.patch I have been working on an extension for whitespace management, similar to what's described here: http://wiki.apache.org/xmlgraphics-fop/WhitespaceManagement The logic of the extension is very simple: the user defines a set of alternatives that he wishes to insert at the end of a page, then if there is enough space left, FOP will pick the alternative that best matches the user's selection criteria (first fit, smallest fit, biggest fit). This is my first work on FOP and it took me almost 2 months to reach this stage in development. But it's not the end of course, so I'm relying on your feedback to improve it. Thank you -- 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-2293) Whitespace management extension
[ https://issues.apache.org/jira/browse/FOP-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13756688#comment-13756688 ] Pascal Sancho commented on FOP-2293: In addition to namepsace discussion: in XML 1.1 REC §6.2, para 2 [1]: A default namespace declaration applies to all unprefixed element names within its scope. Default namespace declarations do not apply directly to attribute names; the interpretation of unprefixed attributes is determined by the element on which they appear. [1] http://www.w3.org/TR/2006/REC-xml-names11-20060816/#defaulting Whitespace management extension --- Key: FOP-2293 URL: https://issues.apache.org/jira/browse/FOP-2293 Project: Fop Issue Type: New Feature Components: general Affects Versions: trunk Reporter: Seifeddine Dridi Priority: Minor Labels: XSL-FO Fix For: trunk Attachments: bestfit.fo, doc.pdf, multiple-feasible-nodes.fo, patch.patch, patch-rev1.1.patch, patch-rev1.patch I have been working on an extension for whitespace management, similar to what's described here: http://wiki.apache.org/xmlgraphics-fop/WhitespaceManagement The logic of the extension is very simple: the user defines a set of alternatives that he wishes to insert at the end of a page, then if there is enough space left, FOP will pick the alternative that best matches the user's selection criteria (first fit, smallest fit, biggest fit). This is my first work on FOP and it took me almost 2 months to reach this stage in development. But it's not the end of course, so I'm relying on your feedback to improve it. Thank you -- 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-2293) Whitespace management extension
[ https://issues.apache.org/jira/browse/FOP-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13756682#comment-13756682 ] Pascal Sancho commented on FOP-2293: regarding the following construction: fox:best-fit fox:fitting-strategy=biggest-fit best-fit element is in the fox namespace. so, the default namespace for all attributes set on such element is fox namespace. You just have to specify it on carrier element. In that case, the correct construction is: fox:best-fit fitting-strategy=biggest-fit Note that double setting same namespace (both on element and on attribute) can produce unexpected behaviour with some xml parsers Whitespace management extension --- Key: FOP-2293 URL: https://issues.apache.org/jira/browse/FOP-2293 Project: Fop Issue Type: New Feature Components: general Affects Versions: trunk Reporter: Seifeddine Dridi Priority: Minor Labels: XSL-FO Fix For: trunk Attachments: bestfit.fo, doc.pdf, multiple-feasible-nodes.fo, patch.patch, patch-rev1.1.patch, patch-rev1.patch I have been working on an extension for whitespace management, similar to what's described here: http://wiki.apache.org/xmlgraphics-fop/WhitespaceManagement The logic of the extension is very simple: the user defines a set of alternatives that he wishes to insert at the end of a page, then if there is enough space left, FOP will pick the alternative that best matches the user's selection criteria (first fit, smallest fit, biggest fit). This is my first work on FOP and it took me almost 2 months to reach this stage in development. But it's not the end of course, so I'm relying on your feedback to improve it. Thank you -- 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-2292) [PATCH] NullPointerException after page IPD change
[ https://issues.apache.org/jira/browse/FOP-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Sancho updated FOP-2292: --- Attachment: fop.pdf fop.pdf is what I get against v1.1 without any Exception [PATCH] NullPointerException after page IPD change -- Key: FOP-2292 URL: https://issues.apache.org/jira/browse/FOP-2292 Project: Fop Issue Type: Bug Components: general Affects Versions: 1.0 Reporter: Seifeddine Dridi Fix For: 1.1 Attachments: expected.pdf, fop.pdf, idea.patch, test.fo The error occurs when FOP detects an IPD change and redoes phase 1 of the layout process. A NullPointerException is fired in getNextBlockListChangedIPD() at line 820, it seems that getPosition() is returning null. Can anyone confirm this issue? -- 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-2292) [PATCH] NullPointerException after page IPD change
[ https://issues.apache.org/jira/browse/FOP-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13749869#comment-13749869 ] Pascal Sancho commented on FOP-2292: Can anyone confirm this issue? Hi, in order to confirm, please attach a short XSL-FO test case; [PATCH] NullPointerException after page IPD change -- Key: FOP-2292 URL: https://issues.apache.org/jira/browse/FOP-2292 Project: Fop Issue Type: Bug Components: general Affects Versions: trunk Reporter: Seifeddine Dridi Attachments: idea.patch The error occurs when FOP detects an IPD change and redoes phase 1 of the layout process. A NullPointerException is fired in getNextBlockListChangedIPD() at line 820, it seems that getPosition() is returning null. Can anyone confirm this issue? -- 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] [Resolved] (FOP-2292) [PATCH] NullPointerException after page IPD change
[ https://issues.apache.org/jira/browse/FOP-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Sancho resolved FOP-2292. Resolution: Fixed Fix Version/s: 1.1 [PATCH] NullPointerException after page IPD change -- Key: FOP-2292 URL: https://issues.apache.org/jira/browse/FOP-2292 Project: Fop Issue Type: Bug Components: general Affects Versions: trunk Reporter: Seifeddine Dridi Fix For: 1.1 Attachments: expected.pdf, idea.patch, test.fo The error occurs when FOP detects an IPD change and redoes phase 1 of the layout process. A NullPointerException is fired in getNextBlockListChangedIPD() at line 820, it seems that getPosition() is returning null. Can anyone confirm this issue? -- 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-2292) [PATCH] NullPointerException after page IPD change
[ https://issues.apache.org/jira/browse/FOP-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Sancho updated FOP-2292: --- Affects Version/s: (was: trunk) 1.0 [PATCH] NullPointerException after page IPD change -- Key: FOP-2292 URL: https://issues.apache.org/jira/browse/FOP-2292 Project: Fop Issue Type: Bug Components: general Affects Versions: 1.0 Reporter: Seifeddine Dridi Fix For: 1.1 Attachments: expected.pdf, idea.patch, test.fo The error occurs when FOP detects an IPD change and redoes phase 1 of the layout process. A NullPointerException is fired in getNextBlockListChangedIPD() at line 820, it seems that getPosition() is returning null. Can anyone confirm this issue? -- 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-2292) [PATCH] NullPointerException after page IPD change
[ https://issues.apache.org/jira/browse/FOP-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13749994#comment-13749994 ] Pascal Sancho commented on FOP-2292: Feeding FOP with test.fo result in NPE only with FOP 1.0 Both latest FOP release (v1.1) and development version do not throw any Exception. Looking at the expected.pdf, it appears to be generated with FOP v1.0a, witch is quite old. I close this issue, but fell free to reopen if you can reproduce it against more recent FOP version. [PATCH] NullPointerException after page IPD change -- Key: FOP-2292 URL: https://issues.apache.org/jira/browse/FOP-2292 Project: Fop Issue Type: Bug Components: general Affects Versions: trunk Reporter: Seifeddine Dridi Attachments: expected.pdf, idea.patch, test.fo The error occurs when FOP detects an IPD change and redoes phase 1 of the layout process. A NullPointerException is fired in getNextBlockListChangedIPD() at line 820, it seems that getPosition() is returning null. Can anyone confirm this issue? -- 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-2268) Empty wrapper in otherwise empty block results in an area
[ https://issues.apache.org/jira/browse/FOP-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13690130#comment-13690130 ] Pascal Sancho commented on FOP-2268: hmm, this is a bug: fo:block containing only an empty fo:wrapper with no id generates one area (should be zero-height): this is expected. But it generates also an unexpected inline area (try it with 'at' output). So, yes, this is a bug. See [1] [2] for further info [1] http://www.w3.org/TR/xsl/#fo_block [2] http://www.w3.org/TR/xsl/#fo_wrapper Empty wrapper in otherwise empty block results in an area - Key: FOP-2268 URL: https://issues.apache.org/jira/browse/FOP-2268 Project: Fop Issue Type: Bug Components: pdf Affects Versions: 1.1 Environment: Windows (probably occurs regardless of the OS) Reporter: Nick Heyworth Priority: Minor Attachments: test.fo The attached FO contains 1) an empty block 2) an empty wrapper 3) an empty wrapper in a block I was expecting none of these to render an area, but 3) causes some empty space to be rendered. Am I expecting the wrong thing, or is this a bug? -- 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-2268) Empty wrapper in otherwise empty block results in an extra inline area
[ https://issues.apache.org/jira/browse/FOP-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Sancho updated FOP-2268: --- Summary: Empty wrapper in otherwise empty block results in an extra inline area (was: Empty wrapper in otherwise empty block results in an area) Empty wrapper in otherwise empty block results in an extra inline area -- Key: FOP-2268 URL: https://issues.apache.org/jira/browse/FOP-2268 Project: Fop Issue Type: Bug Components: pdf Affects Versions: 1.1 Environment: Windows (probably occurs regardless of the OS) Reporter: Nick Heyworth Priority: Minor Attachments: test.fo The attached FO contains 1) an empty block 2) an empty wrapper 3) an empty wrapper in a block I was expecting none of these to render an area, but 3) causes some empty space to be rendered. Am I expecting the wrong thing, or is this a bug? -- 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] [Reopened] (FOP-2267) fo:table nested in fo:inline cause overflow at the end of page
[ https://issues.apache.org/jira/browse/FOP-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Sancho reopened FOP-2267: bug is still there. workaround doesn't fix it. fo:table nested in fo:inline cause overflow at the end of page -- Key: FOP-2267 URL: https://issues.apache.org/jira/browse/FOP-2267 Project: Fop Issue Type: Bug Affects Versions: 0.95, 1.1 Environment: Windows 7 Reporter: Json Attachments: test.fo, TestResult(error).png I'm using FOP 0.95. In case the number of row in my table is over 100 rows (multipages). The row at the end of page is lost occasionally ? Please help me ! (Please see 'TestResult(error).png') -- 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-2267) The row at the end of page was lost
[ https://issues.apache.org/jira/browse/FOP-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13689022#comment-13689022 ] Pascal Sancho commented on FOP-2267: There is fo:inline element that contains the whole table construction; see attached testcase, line 460. Removing that fo:inline should resolve the issue. While this is a legal stuff (according to XSL-REC), this is not a recommended one. If this element is used as a property carrier, you should replace it with a fo:wrapper. The row at the end of page was lost --- Key: FOP-2267 URL: https://issues.apache.org/jira/browse/FOP-2267 Project: Fop Issue Type: Bug Affects Versions: 0.95 Environment: Windows 7 Reporter: Json Attachments: test.fo, TestResult(error).png I'm using FOP 0.95. In case the number of row in my table is over 100 rows (multipages). The row at the end of page is lost occasionally ? Please help me ! (Please see 'TestResult(error).png') -- 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-2267) fo:table nested in fo:inline cause overflow at the end of page
[ https://issues.apache.org/jira/browse/FOP-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Sancho updated FOP-2267: --- Affects Version/s: 1.1 Summary: fo:table nested in fo:inline cause overflow at the end of page (was: The row at the end of page was lost) fo:table nested in fo:inline cause overflow at the end of page -- Key: FOP-2267 URL: https://issues.apache.org/jira/browse/FOP-2267 Project: Fop Issue Type: Bug Affects Versions: 0.95, 1.1 Environment: Windows 7 Reporter: Json Attachments: test.fo, TestResult(error).png I'm using FOP 0.95. In case the number of row in my table is over 100 rows (multipages). The row at the end of page is lost occasionally ? Please help me ! (Please see 'TestResult(error).png') -- 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-2267) fo:table nested in fo:inline cause overflow at the end of page
[ https://issues.apache.org/jira/browse/FOP-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13689242#comment-13689242 ] Pascal Sancho commented on FOP-2267: fo:wrapper is a property carrier (see [1]). So, you can use any inherited property as you want with this FO (font-size is one of them). [1] http://www.w3.org/TR/xsl/#fo_wrapper fo:table nested in fo:inline cause overflow at the end of page -- Key: FOP-2267 URL: https://issues.apache.org/jira/browse/FOP-2267 Project: Fop Issue Type: Bug Affects Versions: 0.95, 1.1 Environment: Windows 7 Reporter: Json Attachments: test.fo, TestResult(error).png I'm using FOP 0.95. In case the number of row in my table is over 100 rows (multipages). The row at the end of page is lost occasionally ? Please help me ! (Please see 'TestResult(error).png') -- 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-1124) percent in table-cell width are not correctly handled
[ https://issues.apache.org/jira/browse/FOP-1124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Sancho updated FOP-1124: --- Attachment: _test.fo reviewed test case percent in table-cell width are not correctly handled - Key: FOP-1124 URL: https://issues.apache.org/jira/browse/FOP-1124 Project: Fop Issue Type: Bug Components: page-master/layout Affects Versions: 0.91, trunk Environment: Operating System: Windows XP Platform: PC Reporter: Pascal Sancho Priority: Minor Attachments: go_ex.fo, _test.fo When the table property border-separation.b-p-d is greater than 0: 1. the table header is not layed out if the table overflows the first page; 2. in Awt renderer, the vertical space between 2 cells seems to be ignored. -- 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-1124) percent in table-cell width are not correctly handled
[ https://issues.apache.org/jira/browse/FOP-1124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Sancho updated FOP-1124: --- Component/s: (was: general) page-master/layout Priority: Minor Affects Version/s: trunk Summary: percent in table-cell width are not correctly handled (was: border-separation disturbs table layout) After deeper analyse, the behaviour is caused by using percent values on table-cell, witch causes the following error: [ERROR] AbstractBaseLayoutManager - Cannot find LM to handle given FO for LengthBase. (fo:table-cell, location: 13:63) percent in table-cell width are not correctly handled - Key: FOP-1124 URL: https://issues.apache.org/jira/browse/FOP-1124 Project: Fop Issue Type: Bug Components: page-master/layout Affects Versions: 0.91, trunk Environment: Operating System: Windows XP Platform: PC Reporter: Pascal Sancho Priority: Minor Attachments: go_ex.fo, _test.fo When the table property border-separation.b-p-d is greater than 0: 1. the table header is not layed out if the table overflows the first page; 2. in Awt renderer, the vertical space between 2 cells seems to be ignored. -- 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-2230) RowSpanning will not effect, if there is not a column with all rows
[ https://issues.apache.org/jira/browse/FOP-2230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13634947#comment-13634947 ] Pascal Sancho commented on FOP-2230: I agree with Vincent's analyse. IMHO, that could be related with the relative-align property [1]. Unfortunately, FOP doesn't implement it. [1] http://www.w3.org/TR/xsl/#relative-align RowSpanning will not effect, if there is not a column with all rows --- Key: FOP-2230 URL: https://issues.apache.org/jira/browse/FOP-2230 Project: Fop Issue Type: Bug Components: pdf Affects Versions: 1.1 Reporter: Markus Sticker Attachments: table_error_expected.pdf, table_error.fo, table_error.pdf, table_error.rtf RowSpanning will not effect, if there is not a column with all rows -- 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-2233) RSS-feed link on website broken
[ https://issues.apache.org/jira/browse/FOP-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13623420#comment-13623420 ] Pascal Sancho commented on FOP-2233: RSS links were built by Forrest, but as we migrated doc to a new CMS, AFAIK there is no mechanics in it to reenable RSS links. However, this is a Jira feature, and as we migrated from Bugzilla to Jira, we can add new RSS links besed on Jira search capability. Cf. Jira doc: https://confluence.atlassian.com/display/JIRA052/Receiving+Search+Results+as+an+RSS+Feed RSS-feed link on website broken --- Key: FOP-2233 URL: https://issues.apache.org/jira/browse/FOP-2233 Project: Fop Issue Type: Bug Components: documentation Environment: Reporter: paull lachewsky Priority: Minor The RSS-link for the FOP news ist broken Page:http://xmlgraphics.apache.org/fop/news.html Link: http://xmlgraphics.apache.org/fop/subproject-news-feed.rss Couldn't find any contact-information regarding webmaster/mistress, so I figured I'd need to file a bug.. Hope that's okay imho rss-feeds are the best thing to stay updated with software-news. I'd be very happy if you can fix it. -- 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-2233) RSS-feed link on website broken
[ https://issues.apache.org/jira/browse/FOP-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13623420#comment-13623420 ] Pascal Sancho edited comment on FOP-2233 at 4/5/13 6:59 AM: RSS links were built by Forrest, but as we migrated doc to a new CMS, AFAIK there is no mechanics in it to reenable RSS links. However, this is a Jira feature, and as we migrated from Bugzilla to Jira, we can add new RSS links based on Jira search capability. Cf. Jira doc: https://confluence.atlassian.com/display/JIRA052/Receiving+Search+Results+as+an+RSS+Feed was (Author: psancho): RSS links were built by Forrest, but as we migrated doc to a new CMS, AFAIK there is no mechanics in it to reenable RSS links. However, this is a Jira feature, and as we migrated from Bugzilla to Jira, we can add new RSS links besed on Jira search capability. Cf. Jira doc: https://confluence.atlassian.com/display/JIRA052/Receiving+Search+Results+as+an+RSS+Feed RSS-feed link on website broken --- Key: FOP-2233 URL: https://issues.apache.org/jira/browse/FOP-2233 Project: Fop Issue Type: Bug Components: documentation Environment: Reporter: paull lachewsky Priority: Minor The RSS-link for the FOP news ist broken Page:http://xmlgraphics.apache.org/fop/news.html Link: http://xmlgraphics.apache.org/fop/subproject-news-feed.rss Couldn't find any contact-information regarding webmaster/mistress, so I figured I'd need to file a bug.. Hope that's okay imho rss-feeds are the best thing to stay updated with software-news. I'd be very happy if you can fix it. -- 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] [Closed] (FOP-2227) Rendering of before, after, start, end regions does not conform with W3C standards
[ https://issues.apache.org/jira/browse/FOP-2227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Sancho closed FOP-2227. -- Resolution: Invalid The behaviour is dictated by the precedence property, witch applies on region-before and region-after, and witch defaults to false. So, by default, both region-start and region-end have precedence over region-before and region-after. W3C scheme shows what is expected when precendence properties are set to true on region-before and refion-after. So, FOP behaves as expected. See: http://www.w3.org/TR/xsl/#precedence http://www.w3.org/TR/xsl/#fo_region-before http://www.w3.org/TR/xsl/#fo_region-after http://www.w3.org/TR/xsl/#fo_region-start http://www.w3.org/TR/xsl/#fo_region-end Rendering of before, after, start, end regions does not conform with W3C standards -- Key: FOP-2227 URL: https://issues.apache.org/jira/browse/FOP-2227 Project: Fop Issue Type: Bug Components: page-master/layout Affects Versions: 1.1 Environment: Windows 7 64bit Professional HUN running on Oralce Virtualbox 4.2.10 r84104 running on 64bit Ubuntu 12.04 LTS Host machine Reporter: Szeak Attachments: region-test.fo By W3C standards, the region-before and region-after default must be horizontally fill out the width of the page between page left and right margins. Region-start and region-end must be vertically fill out the height of the page between region-before and region-after. FOP renders these regions as follows: region-start and region-end fill out vertically the page height between page top and bottom margins, region-before and region-end fill out horizontally the space between region-start and region-end. Steps to Reproduce: Render to any output format the attached fo: The original W3C standard image from the regions: http://www.w3.org/TR/xsl/#fo_simple-page-master Reference from w3schools: http://www.w3schools.com/xslfo/xslfo_pages.asp -- 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] [Resolved] (FOP-2218) 1.1 is reported working with JRE = 1.4
[ https://issues.apache.org/jira/browse/FOP-2218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Sancho resolved FOP-2218. Resolution: Invalid Running and Buiding are 2 distinct actions. for building, 1.5 is required for running, 1.4 is ok. If you are facing to a problem when running, feel free to reopen this file, giving actual java version (vendor + version number), OS, etc. 1.1 is reported working with JRE = 1.4 --- Key: FOP-2218 URL: https://issues.apache.org/jira/browse/FOP-2218 Project: Fop Issue Type: Bug Components: documentation Affects Versions: 1.1 Reporter: Francesco Chicchiriccò In [1] it is stated that Java 1.4.x or later Runtime Environment. is required for running FOP 1.1. However, as reported in [2], 1.5 is required. [1] http://xmlgraphics.apache.org/fop/1.1/running.html [2] http://svn.apache.org/repos/asf/xmlgraphics/fop/tags/fop-1_1/build.xml -- 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] [Resolved] (FOP-2218) 1.1 is reported working with JRE = 1.4
[ https://issues.apache.org/jira/browse/FOP-2218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Sancho resolved FOP-2218. Resolution: Fixed Fix Version/s: 1.1 trunk thanks for pointing that. 1.1 is reported working with JRE = 1.4 --- Key: FOP-2218 URL: https://issues.apache.org/jira/browse/FOP-2218 Project: Fop Issue Type: Bug Components: documentation Affects Versions: 1.1 Reporter: Francesco Chicchiriccò Assignee: Pascal Sancho Fix For: trunk, 1.1 In [1] it is stated that Java 1.4.x or later Runtime Environment. is required for running FOP 1.1. However, as reported in [2], 1.5 is required. [1] http://xmlgraphics.apache.org/fop/1.1/running.html [2] http://svn.apache.org/repos/asf/xmlgraphics/fop/tags/fop-1_1/build.xml -- 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] [Resolved] (FOP-2218) 1.1 is reported working with JRE = 1.4
[ https://issues.apache.org/jira/browse/FOP-2218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Sancho resolved FOP-2218. Resolution: Fixed Fix Version/s: 1.1 trunk thanks for pointing that. 1.1 is reported working with JRE = 1.4 --- Key: FOP-2218 URL: https://issues.apache.org/jira/browse/FOP-2218 Project: Fop Issue Type: Bug Components: documentation Affects Versions: 1.1 Reporter: Francesco Chicchiriccò Assignee: Pascal Sancho Fix For: trunk, 1.1 In [1] it is stated that Java 1.4.x or later Runtime Environment. is required for running FOP 1.1. However, as reported in [2], 1.5 is required. [1] http://xmlgraphics.apache.org/fop/1.1/running.html [2] http://svn.apache.org/repos/asf/xmlgraphics/fop/tags/fop-1_1/build.xml -- 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-2203) fop-configuration.xsd is invalid
[ https://issues.apache.org/jira/browse/FOP-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Sancho updated FOP-2203: --- Assignee: Pascal Sancho fop-configuration.xsd is invalid Key: FOP-2203 URL: https://issues.apache.org/jira/browse/FOP-2203 Project: Fop Issue Type: Bug Components: general Affects Versions: 1.1 Reporter: Will May Assignee: Pascal Sancho src/foschema/fop-configuration.xsd is invalid as line 51 doesn't end with a ''. 'xsd:element name=complex-scripts minOccurs=0' should be 'xsd:element name=complex-scripts minOccurs=0' -- 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
