Re: OTF CFF Implementation
Hi, unless I'm missing something, fontbox dev activity is quite slow (latest commit was on 2007-10-01, 6 years ago, see [1]). IMHO, introducing a dependency on such project witch will need some improvement is not a good thing, unless we can ensure that submitting patches to it will be applied on demand. [1] http://sourceforge.net/projects/fontbox/stats/scm?repo=CVSRepositorydates=2007-01-10+to+2013-01-10 2013/1/9 Robert Meyer rme...@hotmail.co.uk: Hi All, Unless someone else has been developing this in secret, I am planning to make a start on adding support for OTF CFF (Open Type - Compact Font Format). There are two choices I can see which are available and would like to ask for your opinion. These are: 1) Using the implementation from fontbox and write adapter classes to allow it to work with FOP. 2) Write a dedicated FOP implementation. There are pro's and con's to each. Firstly, using fontbox will create another dependency to FOP which is generally never a good thing. It will also means if there is a problem with their implementation, we have to rely upon them to commit the patch (either written by us or by themselves). I don't know what their uptake is on committing patches, but unlike FOP the control would be taken out of our hands. Saying this however, using their implementation will cut the development time as the majority of work will already have been done. There is also the advantage that their implementation will have been around for a while and will have benefited from subsequent use and have ironed out any bugs. If you have any other comments for or against each option please post them. Regards, Robert Meyer -- pascal
[jira] [Resolved] (FOP-2180) [PATCH] TTFReader: Output bounding box information for glyphs
[ https://issues.apache.org/jira/browse/FOP-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Hancock resolved FOP-2180. Resolution: Implemented Assignee: Peter Hancock Thanks to Alexey Neyman [PATCH] TTFReader: Output bounding box information for glyphs - Key: FOP-2180 URL: https://issues.apache.org/jira/browse/FOP-2180 Project: Fop Issue Type: Wish Components: fonts Affects Versions: 1.1 Reporter: Alexey Neyman Assignee: Peter Hancock Priority: Minor Attachments: ttfreader.diff As I mentioned in another email, I am trying to constrain FOP to use only local fonts (i.e. ones described in fop.cfg). For SVGs, I have a workaround: - Generate fonts in SVG format using ttf2svg utility from Batik; - Use an XSL stylesheet to embed all the fonts used by an SVG image into the image itself; - Use such preprocessed SVG image as the input to FOP. This does not work well with JEuclid, though. When JEuclid generates SVG from MathML, it performs font rendering - that is, replaces characters by actual paths. And again, it uses system fonts, not the fonts available in FOP - even if running as FOP plugin. To work around this issue for MathML, I am currently switching from JEuclid to pMML2SVG (http://pmml2svg.sourceforge.net). It generates SVGs with text characters, not paths. But in order to do so, it needs font metrics. Unfortunately, font metrics produced by stock FOP TTFReader are not sufficient - this stylesheet also needs bounding box for each glyph. To obtain these, pMML2SVG currently packages an augmented TTFReader Java sources which are to be compiled and used in lieu of the stock one. Given that the patch is very small and as far as I can tell, compatible with current users of font metrics (it just adds 4 attributes to glyph description), is it possible to integrate this support into stock FOP? Patch from pMML2SVG, slightly modified to apply to FOP 1.1 sources, attached. -- 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-1069) No error message on illegal/unknown values on a property
[ https://issues.apache.org/jira/browse/FOP-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Hancock resolved FOP-1069. Resolution: Fixed Assignee: Peter Hancock Resolved thanks to Robert Meyer No error message on illegal/unknown values on a property Key: FOP-1069 URL: https://issues.apache.org/jira/browse/FOP-1069 Project: Fop Issue Type: Bug Components: fo tree Affects Versions: trunk Environment: Operating System: All Platform: All Reporter: Jeremias Maerki Assignee: Peter Hancock Attachments: patch.diff, test2.fo I've written border=solit 1pt into an FO file. When I realized my typo I went looking for an error message but didn't find one. I looked around to fix this myself but didn't find the right spot in reasonable time as I'm concentrating on other stuff right now. I'm posting it here so it doesn't get lost. FOP should notify the user that it has found a value it cannot deal with, especially if this is an enum value. -- 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
Re: OTF CFF Implementation
Hi Pascal, FontBox is a small library within the PDFBox project. PDFBox is an active Apache project, so getting patches committed there shouldn't be a problem. Jeremias is a committer on PDFBox too. FontBox is no longer hosted on Source Forge, as it was moved to Apache a few years back; which is probably why there hasn't been a recent commit to the SourceForge version. Last commit to the Apache version was still 2 years ago, see: http://svn.apache.org/viewvc/pdfbox/ I think it makes sense to reuse code wherever possible, especially when we are talking about fellow Apache projects. So I'm +1 to this proposal. Thanks, Chris On 10/01/2013 09:12, Pascal Sancho wrote: Hi, unless I'm missing something, fontbox dev activity is quite slow (latest commit was on 2007-10-01, 6 years ago, see [1]). IMHO, introducing a dependency on such project witch will need some improvement is not a good thing, unless we can ensure that submitting patches to it will be applied on demand. [1] http://sourceforge.net/projects/fontbox/stats/scm?repo=CVSRepositorydates=2007-01-10+to+2013-01-10 2013/1/9 Robert Meyer rme...@hotmail.co.uk: Hi All, Unless someone else has been developing this in secret, I am planning to make a start on adding support for OTF CFF (Open Type - Compact Font Format). There are two choices I can see which are available and would like to ask for your opinion. These are: 1) Using the implementation from fontbox and write adapter classes to allow it to work with FOP. 2) Write a dedicated FOP implementation. There are pro's and con's to each. Firstly, using fontbox will create another dependency to FOP which is generally never a good thing. It will also means if there is a problem with their implementation, we have to rely upon them to commit the patch (either written by us or by themselves). I don't know what their uptake is on committing patches, but unlike FOP the control would be taken out of our hands. Saying this however, using their implementation will cut the development time as the majority of work will already have been done. There is also the advantage that their implementation will have been around for a while and will have benefited from subsequent use and have ironed out any bugs. If you have any other comments for or against each option please post them. Regards, Robert Meyer
Re: OTF CFF Implementation
Hi, Ok, I've missed that. I did found only the sourceforge repos, I'm sorry. So i'm +1 too. 2013/1/10 Chris Bowditch bowditch_ch...@hotmail.com: Hi Pascal, FontBox is a small library within the PDFBox project. PDFBox is an active Apache project, so getting patches committed there shouldn't be a problem. Jeremias is a committer on PDFBox too. FontBox is no longer hosted on Source Forge, as it was moved to Apache a few years back; which is probably why there hasn't been a recent commit to the SourceForge version. Last commit to the Apache version was still 2 years ago, see: http://svn.apache.org/viewvc/pdfbox/ I think it makes sense to reuse code wherever possible, especially when we are talking about fellow Apache projects. So I'm +1 to this proposal. Thanks, Chris On 10/01/2013 09:12, Pascal Sancho wrote: Hi, unless I'm missing something, fontbox dev activity is quite slow (latest commit was on 2007-10-01, 6 years ago, see [1]). IMHO, introducing a dependency on such project witch will need some improvement is not a good thing, unless we can ensure that submitting patches to it will be applied on demand. [1] http://sourceforge.net/projects/fontbox/stats/scm?repo=CVSRepositorydates=2007-01-10+to+2013-01-10 2013/1/9 Robert Meyer rme...@hotmail.co.uk: Hi All, Unless someone else has been developing this in secret, I am planning to make a start on adding support for OTF CFF (Open Type - Compact Font Format). There are two choices I can see which are available and would like to ask for your opinion. These are: 1) Using the implementation from fontbox and write adapter classes to allow it to work with FOP. 2) Write a dedicated FOP implementation. There are pro's and con's to each. Firstly, using fontbox will create another dependency to FOP which is generally never a good thing. It will also means if there is a problem with their implementation, we have to rely upon them to commit the patch (either written by us or by themselves). I don't know what their uptake is on committing patches, but unlike FOP the control would be taken out of our hands. Saying this however, using their implementation will cut the development time as the majority of work will already have been done. There is also the advantage that their implementation will have been around for a while and will have benefited from subsequent use and have ironed out any bugs. If you have any other comments for or against each option please post them. Regards, Robert Meyer -- pascal
RE: OTF CFF Implementation
Hi Pascal, My apologies as I should have provided the link [1]. I am guessing that the sourceforge project you linked to is the original version before it was merged with pdfbox. The project is quite active and had its last patch submitted yesterday. There is also a PMC member on the project who is also a FOP committer (Jeremias), but I am sure the other committers are fairly active. Regards, Robert [1] http://pdfbox.apache.org/dependencies.html Date: Thu, 10 Jan 2013 10:12:43 +0100 Subject: Re: OTF CFF Implementation From: psancho@gmail.com To: fop-dev@xmlgraphics.apache.org Hi, unless I'm missing something, fontbox dev activity is quite slow (latest commit was on 2007-10-01, 6 years ago, see [1]). IMHO, introducing a dependency on such project witch will need some improvement is not a good thing, unless we can ensure that submitting patches to it will be applied on demand. [1] http://sourceforge.net/projects/fontbox/stats/scm?repo=CVSRepositorydates=2007-01-10+to+2013-01-10 2013/1/9 Robert Meyer rme...@hotmail.co.uk: Hi All, Unless someone else has been developing this in secret, I am planning to make a start on adding support for OTF CFF (Open Type - Compact Font Format). There are two choices I can see which are available and would like to ask for your opinion. These are: 1) Using the implementation from fontbox and write adapter classes to allow it to work with FOP. 2) Write a dedicated FOP implementation. There are pro's and con's to each. Firstly, using fontbox will create another dependency to FOP which is generally never a good thing. It will also means if there is a problem with their implementation, we have to rely upon them to commit the patch (either written by us or by themselves). I don't know what their uptake is on committing patches, but unlike FOP the control would be taken out of our hands. Saying this however, using their implementation will cut the development time as the majority of work will already have been done. There is also the advantage that their implementation will have been around for a while and will have benefited from subsequent use and have ironed out any bugs. If you have any other comments for or against each option please post them. Regards, Robert Meyer -- pascal
RE: OTF CFF Implementation
Ignore my last message. Chris got there first. From: rme...@hotmail.co.uk To: fop-dev@xmlgraphics.apache.org Subject: RE: OTF CFF Implementation Date: Thu, 10 Jan 2013 11:01:00 + Hi Pascal, My apologies as I should have provided the link [1]. I am guessing that the sourceforge project you linked to is the original version before it was merged with pdfbox. The project is quite active and had its last patch submitted yesterday. There is also a PMC member on the project who is also a FOP committer (Jeremias), but I am sure the other committers are fairly active. Regards, Robert [1] http://pdfbox.apache.org/dependencies.html Date: Thu, 10 Jan 2013 10:12:43 +0100 Subject: Re: OTF CFF Implementation From: psancho@gmail.com To: fop-dev@xmlgraphics.apache.org Hi, unless I'm missing something, fontbox dev activity is quite slow (latest commit was on 2007-10-01, 6 years ago, see [1]). IMHO, introducing a dependency on such project witch will need some improvement is not a good thing, unless we can ensure that submitting patches to it will be applied on demand. [1] http://sourceforge.net/projects/fontbox/stats/scm?repo=CVSRepositorydates=2007-01-10+to+2013-01-10 2013/1/9 Robert Meyer rme...@hotmail.co.uk: Hi All, Unless someone else has been developing this in secret, I am planning to make a start on adding support for OTF CFF (Open Type - Compact Font Format). There are two choices I can see which are available and would like to ask for your opinion. These are: 1) Using the implementation from fontbox and write adapter classes to allow it to work with FOP. 2) Write a dedicated FOP implementation. There are pro's and con's to each. Firstly, using fontbox will create another dependency to FOP which is generally never a good thing. It will also means if there is a problem with their implementation, we have to rely upon them to commit the patch (either written by us or by themselves). I don't know what their uptake is on committing patches, but unlike FOP the control would be taken out of our hands. Saying this however, using their implementation will cut the development time as the majority of work will already have been done. There is also the advantage that their implementation will have been around for a while and will have benefited from subsequent use and have ironed out any bugs. If you have any other comments for or against each option please post them. Regards, Robert Meyer -- pascal
[Vote] Add dependency to fontbox for OTF CFF
Hi all, I posted a message yesterday about getting opinions on either adding a dependency to fontbox to use their implementation or write our own for OTF CFF support. I personally think that using fontbox would be the better option due to: 1) Re-use of code rather than re-writing 2) Stability and subsequent bugfixes since the time it was released. 3) Will cut development time for implementing this feature. There is room for discussion about making the new dependency optional i.e. FOP working without the jar and only being called if a CFF font is used. At this stage though the dependency issue needs to be voted on. I would therefore like to start a vote. As a contributor, my vote will not count toward the result, therefore the decision is left up to the rest of you. Regards, Robert Meyer
Re: [Vote] Add dependency to fontbox for OTF CFF
Hi Rob, On 10/01/2013 12:07, Robert Meyer wrote: Hi all, I posted a message yesterday about getting opinions on either adding a dependency to fontbox to use their implementation or write our own for OTF CFF support. I personally think that using fontbox would be the better option due to: 1) Re-use of code rather than re-writing 2) Stability and subsequent bugfixes since the time it was released. 3) Will cut development time for implementing this feature. There is room for discussion about making the new dependency optional i.e. FOP working without the jar and only being called if a CFF font is used. At this stage though the dependency issue needs to be voted on. I would therefore like to start a vote. My suggestion would be to make Fontbox an optional dependency and to output a warning message along the lines of: For OTF CFF support please add FontBox to the classpath in the event a user tries to use an OTF CFF Font and doesn't have FontBox in the classpath. For all other font types, FOP should work as normal. As a contributor, my vote will not count toward the result, therefore the decision is left up to the rest of you. +1 from me. Regards, Robert Meyer Thanks, Chris
Re: [Vote] Add dependency to fontbox for OTF CFF
+1 On Thu, Jan 10, 2013 at 5:07 AM, Robert Meyer rme...@hotmail.co.uk wrote: Hi all, I posted a message yesterday about getting opinions on either adding a dependency to fontbox to use their implementation or write our own for OTF CFF support. I personally think that using fontbox would be the better option due to: 1) Re-use of code rather than re-writing 2) Stability and subsequent bugfixes since the time it was released. 3) Will cut development time for implementing this feature. There is room for discussion about making the new dependency optional i.e. FOP working without the jar and only being called if a CFF font is used. At this stage though the dependency issue needs to be voted on. I would therefore like to start a vote. As a contributor, my vote will not count toward the result, therefore the decision is left up to the rest of you. Regards, Robert Meyer
Re: [Vote] Add dependency to fontbox for OTF CFF
+1 from me to adding FontBox support and making it optional as Chris recommends. FOP functionality should not change if OTF CFF Font is not requested. Of course, there may be other Font areas where FOP can use FontBox's help, and that'll come in the course of time. Clay Leeds ~ the.webmaes...@gmail.com On Jan 10, 2013, at 5:36 AM, Chris Bowditch bowditch_ch...@hotmail.com wrote: Hi Rob, On 10/01/2013 12:07, Robert Meyer wrote: Hi all, I posted a message yesterday about getting opinions on either adding a dependency to fontbox to use their implementation or write our own for OTF CFF support. I personally think that using fontbox would be the better option due to: 1) Re-use of code rather than re-writing 2) Stability and subsequent bugfixes since the time it was released. 3) Will cut development time for implementing this feature. There is room for discussion about making the new dependency optional i.e. FOP working without the jar and only being called if a CFF font is used. At this stage though the dependency issue needs to be voted on. I would therefore like to start a vote. My suggestion would be to make Fontbox an optional dependency and to output a warning message along the lines of: For OTF CFF support please add FontBox to the classpath in the event a user tries to use an OTF CFF Font and doesn't have FontBox in the classpath. For all other font types, FOP should work as normal. As a contributor, my vote will not count toward the result, therefore the decision is left up to the rest of you. +1 from me. Regards, Robert Meyer Thanks, Chris
Re: [Vote] Add dependency to fontbox for OTF CFF
+1 Vincent On 10/01/13 13:07, Robert Meyer wrote: Hi all, I posted a message yesterday about getting opinions on either adding a dependency to fontbox to use their implementation or write our own for OTF CFF support. I personally think that using fontbox would be the better option due to: 1) Re-use of code rather than re-writing 2) Stability and subsequent bugfixes since the time it was released. 3) Will cut development time for implementing this feature. There is room for discussion about making the new dependency optional i.e. FOP working without the jar and only being called if a CFF font is used. At this stage though the dependency issue needs to be voted on. I would therefore like to start a vote. As a contributor, my vote will not count toward the result, therefore the decision is left up to the rest of you. Regards, Robert Meyer
Re: [Vote] Add dependency to fontbox for OTF CFF
+1 2013/1/10 Robert Meyer rme...@hotmail.co.uk: Hi all, I posted a message yesterday about getting opinions on either adding a dependency to fontbox to use their implementation or write our own for OTF CFF support. I personally think that using fontbox would be the better option due to: 1) Re-use of code rather than re-writing 2) Stability and subsequent bugfixes since the time it was released. 3) Will cut development time for implementing this feature. There is room for discussion about making the new dependency optional i.e. FOP working without the jar and only being called if a CFF font is used. At this stage though the dependency issue needs to be voted on. I would therefore like to start a vote. As a contributor, my vote will not count toward the result, therefore the decision is left up to the rest of you. Regards, Robert Meyer -- pascal
Re: [Vote] Add dependency to fontbox for OTF CFF
+1 if usage is restricted to OTF CFF fonts at first. On Thu, Jan 10, 2013 at 2:20 PM, Vincent Hennebert vhenneb...@gmail.comwrote: +1 Vincent On 10/01/13 13:07, Robert Meyer wrote: Hi all, I posted a message yesterday about getting opinions on either adding a dependency to fontbox to use their implementation or write our own for OTF CFF support. I personally think that using fontbox would be the better option due to: 1) Re-use of code rather than re-writing 2) Stability and subsequent bugfixes since the time it was released. 3) Will cut development time for implementing this feature. There is room for discussion about making the new dependency optional i.e. FOP working without the jar and only being called if a CFF font is used. At this stage though the dependency issue needs to be voted on. I would therefore like to start a vote. As a contributor, my vote will not count toward the result, therefore the decision is left up to the rest of you. Regards, Robert Meyer
Re: [Vote] Add dependency to fontbox for OTF CFF
+1 for it being an optional dependency. On Jan 10, 2013 2:45 PM, Peter Hancock peter.hanc...@gmail.com wrote: +1 if usage is restricted to OTF CFF fonts at first. On Thu, Jan 10, 2013 at 2:20 PM, Vincent Hennebert vhenneb...@gmail.comwrote: +1 Vincent On 10/01/13 13:07, Robert Meyer wrote: Hi all, I posted a message yesterday about getting opinions on either adding a dependency to fontbox to use their implementation or write our own for OTF CFF support. I personally think that using fontbox would be the better option due to: 1) Re-use of code rather than re-writing 2) Stability and subsequent bugfixes since the time it was released. 3) Will cut development time for implementing this feature. There is room for discussion about making the new dependency optional i.e. FOP working without the jar and only being called if a CFF font is used. At this stage though the dependency issue needs to be voted on. I would therefore like to start a vote. As a contributor, my vote will not count toward the result, therefore the decision is left up to the rest of you. Regards, Robert Meyer
RE: OTF CFF Implementation
From my limited experience posting to PDFBox, they process patches pretty quickly and post feedback where appropriate promptly too. Dunno if that eases your concerns Pascal, but that's my 2 cents worth On Jan 10, 2013 11:02 AM, Robert Meyer rme...@hotmail.co.uk wrote: Ignore my last message. Chris got there first. -- From: rme...@hotmail.co.uk To: fop-dev@xmlgraphics.apache.org Subject: RE: OTF CFF Implementation Date: Thu, 10 Jan 2013 11:01:00 + Hi Pascal, My apologies as I should have provided the link [1]. I am guessing that the sourceforge project you linked to is the original version before it was merged with pdfbox. The project is quite active and had its last patch submitted yesterday. There is also a PMC member on the project who is also a FOP committer (Jeremias), but I am sure the other committers are fairly active. Regards, Robert [1] http://pdfbox.apache.org/dependencies.html Date: Thu, 10 Jan 2013 10:12:43 +0100 Subject: Re: OTF CFF Implementation From: psancho@gmail.com To: fop-dev@xmlgraphics.apache.org Hi, unless I'm missing something, fontbox dev activity is quite slow (latest commit was on 2007-10-01, 6 years ago, see [1]). IMHO, introducing a dependency on such project witch will need some improvement is not a good thing, unless we can ensure that submitting patches to it will be applied on demand. [1] http://sourceforge.net/projects/fontbox/stats/scm?repo=CVSRepositorydates=2007-01-10+to+2013-01-10 2013/1/9 Robert Meyer rme...@hotmail.co.uk: Hi All, Unless someone else has been developing this in secret, I am planning to make a start on adding support for OTF CFF (Open Type - Compact Font Format). There are two choices I can see which are available and would like to ask for your opinion. These are: 1) Using the implementation from fontbox and write adapter classes to allow it to work with FOP. 2) Write a dedicated FOP implementation. There are pro's and con's to each. Firstly, using fontbox will create another dependency to FOP which is generally never a good thing. It will also means if there is a problem with their implementation, we have to rely upon them to commit the patch (either written by us or by themselves). I don't know what their uptake is on committing patches, but unlike FOP the control would be taken out of our hands. Saying this however, using their implementation will cut the development time as the majority of work will already have been done. There is also the advantage that their implementation will have been around for a while and will have benefited from subsequent use and have ironed out any bugs. If you have any other comments for or against each option please post them. Regards, Robert Meyer -- pascal
[jira] [Commented] (FOP-2180) [PATCH] TTFReader: Output bounding box information for glyphs
[ https://issues.apache.org/jira/browse/FOP-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13549977#comment-13549977 ] Alexey Neyman commented on FOP-2180: Thanks Peter! Only thing is status.xml: action context=Fonts dev=PH type=add fixes-bug=FOP-1069 due-to=Alexey Neyman It fixes FOP-2180, not FOP-1069. And, I don't know the policy about 'due-to' field - but the credit for the patch should probably go to pMML2SVG developers: Jérôme Joslet, Justus H Piater. [PATCH] TTFReader: Output bounding box information for glyphs - Key: FOP-2180 URL: https://issues.apache.org/jira/browse/FOP-2180 Project: Fop Issue Type: Wish Components: fonts Affects Versions: 1.1 Reporter: Alexey Neyman Assignee: Peter Hancock Priority: Minor Attachments: ttfreader.diff As I mentioned in another email, I am trying to constrain FOP to use only local fonts (i.e. ones described in fop.cfg). For SVGs, I have a workaround: - Generate fonts in SVG format using ttf2svg utility from Batik; - Use an XSL stylesheet to embed all the fonts used by an SVG image into the image itself; - Use such preprocessed SVG image as the input to FOP. This does not work well with JEuclid, though. When JEuclid generates SVG from MathML, it performs font rendering - that is, replaces characters by actual paths. And again, it uses system fonts, not the fonts available in FOP - even if running as FOP plugin. To work around this issue for MathML, I am currently switching from JEuclid to pMML2SVG (http://pmml2svg.sourceforge.net). It generates SVGs with text characters, not paths. But in order to do so, it needs font metrics. Unfortunately, font metrics produced by stock FOP TTFReader are not sufficient - this stylesheet also needs bounding box for each glyph. To obtain these, pMML2SVG currently packages an augmented TTFReader Java sources which are to be compiled and used in lieu of the stock one. Given that the patch is very small and as far as I can tell, compatible with current users of font metrics (it just adds 4 attributes to glyph description), is it possible to integrate this support into stock FOP? Patch from pMML2SVG, slightly modified to apply to FOP 1.1 sources, attached. -- 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] [Assigned] (FOP-1738) break-before=page in table-row
[ https://issues.apache.org/jira/browse/FOP-1738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo reassigned FOP-1738: -- Assignee: Luis Bernardo break-before=page in table-row Key: FOP-1738 URL: https://issues.apache.org/jira/browse/FOP-1738 Project: Fop Issue Type: Bug Components: page-master/layout Affects Versions: trunk Environment: Operating System: Windows XP Platform: PC Reporter: guillaume Assignee: Luis Bernardo Attachments: break.fo, break_new.pdf, break_old.pdf Updating my fop version to fop trunk, I found a difference using break-before=page in a table-row. The break is not done (in my old version -svn 712095- this break was done). -- 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-1738) break-before=page in table-row
[ https://issues.apache.org/jira/browse/FOP-1738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-1738. Resolution: Fixed Fix Version/s: trunk this is not reproducible in trunk anymore. the current output matches the break_old.pdf. I don't know what commit fixed this... break-before=page in table-row Key: FOP-1738 URL: https://issues.apache.org/jira/browse/FOP-1738 Project: Fop Issue Type: Bug Components: page-master/layout Affects Versions: trunk Environment: Operating System: Windows XP Platform: PC Reporter: guillaume Assignee: Luis Bernardo Fix For: trunk Attachments: break.fo, break_new.pdf, break_old.pdf Updating my fop version to fop trunk, I found a difference using break-before=page in a table-row. The break is not done (in my old version -svn 712095- this break was done). -- 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-1597) break-after not honored
[ https://issues.apache.org/jira/browse/FOP-1597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-1597. Resolution: Fixed Fix Version/s: trunk this is not reproducible in trunk anymore. the output for the example is as described, with a second empty page and the second block in the third page break-after not honored --- Key: FOP-1597 URL: https://issues.apache.org/jira/browse/FOP-1597 Project: Fop Issue Type: Bug Components: page-master/layout Affects Versions: 0.95 Environment: Operating System: Windows Server 2003 Platform: PC Reporter: Georg Datterl Fix For: trunk Attachments: publication.fo With break-after=odd-page there should be one empty page and the second block should start on page 3. FOP 0.94 gets it wrong since it creates one empty page when break-after is set to even-page, and indeed two empty pages with odd-page, instead of respectively 0 and 1. FOP 0.95 doesn’t seem to honor the break at all. -- 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-1714) Image processing makes FOP really slow
[ https://issues.apache.org/jira/browse/FOP-1714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-1714. Resolution: Fixed Fix Version/s: trunk this has been fixed in trunk for a long time; as such marking as resolved Image processing makes FOP really slow -- Key: FOP-1714 URL: https://issues.apache.org/jira/browse/FOP-1714 Project: Fop Issue Type: Bug Components: general Affects Versions: 0.95 Environment: Operating System: Windows XP Platform: PC Reporter: Jonathan Levinson Fix For: trunk Attachments: test.fo, test-image.png In investigating a problem in the display of PNG images in FOP, I discovered that image processing was really slow. Examining the code in a debugger the surprise is that the source of slowness is not the rendering of the image (which is done through Java’s JAI) but in the steps leading up to the rendering of the image. For a simple FO page, with a single PNG image FOP takes 90 seconds. Remove the image and FOP takes 1 second. RenderX takes a second as well with our without the image. So the addition of a single image to an FO page results in extreme slowness – two orders of magnitude slower than RenderX XEP. -- 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
