[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-tabpanel&focusedCommentId=13634937#comment-13634937 ] Seifeddine Dridi commented on FOP-2230: --- Thanks for your comment Vincent. I think I agree with you. However, what made me a little bit skeptical about this bug (if it really is) is that the RTF output looks fine, and I don't think it's part of FOP philosophy to make different renderers output different results. Regards > 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-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-tabpanel&focusedCommentId=13634998#comment-13634998 ] Seifeddine Dridi commented on FOP-2230: --- That's weird, with Microsoft Word the result is fine. > 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-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-tabpanel&focusedCommentId=13635043#comment-13635043 ] Seifeddine Dridi commented on FOP-2230: --- Indeed Vincent. Thanks everyone for your feedbacks so far. I'm now more inclined towards thinking that this might not be a bug after all. I tested the same FO file (table_error.fo) with renderx and got the same output as FOP... > 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-2239) Soft hyphens appear in mid line in PDF output
[ https://issues.apache.org/jira/browse/FOP-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13638034#comment-13638034 ] Seifeddine Dridi commented on FOP-2239: --- Try using x002D instead of 0xAD > Soft hyphens appear in mid line in PDF output > - > > Key: FOP-2239 > URL: https://issues.apache.org/jira/browse/FOP-2239 > Project: Fop > Issue Type: Bug > Components: pdf >Affects Versions: 1.1, trunk > Environment: $ java -version > java version "1.7.0_17" > Java(TM) SE Runtime Environment (build 1.7.0_17-b02) > Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode) >Reporter: Mark Craig > Attachments: simple.fo, simple.pdf > > > When producing PDF, soft hyphens show up in mid line when followed by > punctuation characters such as ., ], and ". > In the test case that I will attach to this issue: > .. > . . > . > .] > .\ > ." > .a > .Z > looks like this in the PDF: > .-. > . . > . > .-] > .\ > .-" > .a > .Z > The generation does not display any errors: > $ fop simple.fo simple.pdf > Rendered page #1. -- 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-2239) Soft hyphens appear in mid line in PDF output
[ https://issues.apache.org/jira/browse/FOP-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13638047#comment-13638047 ] Seifeddine Dridi commented on FOP-2239: --- Well x002D is not the unicode value of the soft hyphen character...There is actually a file charlist.xml in "src/codegen/fonts" which contains a big list of unicode characters. After searching for the word "hyphen" I can only find this line > Soft hyphens appear in mid line in PDF output > - > > Key: FOP-2239 > URL: https://issues.apache.org/jira/browse/FOP-2239 > Project: Fop > Issue Type: Bug > Components: pdf >Affects Versions: 1.1, trunk > Environment: $ java -version > java version "1.7.0_17" > Java(TM) SE Runtime Environment (build 1.7.0_17-b02) > Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode) >Reporter: Mark Craig > Attachments: simple.fo, simple.pdf > > > When producing PDF, soft hyphens show up in mid line when followed by > punctuation characters such as ., ], and ". > In the test case that I will attach to this issue: > .. > . . > . > .] > .\ > ." > .a > .Z > looks like this in the PDF: > .-. > . . > . > .-] > .\ > .-" > .a > .Z > The generation does not display any errors: > $ fop simple.fo simple.pdf > Rendered page #1. -- 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-2232) too much bullets, if several fo:blocks inside a list-item-body
[ https://issues.apache.org/jira/browse/FOP-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13641622#comment-13641622 ] Seifeddine Dridi commented on FOP-2232: --- I've been investigating this issue for the last couple of days. Actually, FOP handles each block independently through SAX calls, and it seems that there is no special treatment for fo:blocks nested inside a list, hence they're rendered as normal paragraphs which is why they appear as list items. > too much bullets, if several fo:blocks inside a list-item-body > -- > > Key: FOP-2232 > URL: https://issues.apache.org/jira/browse/FOP-2232 > Project: Fop > Issue Type: Bug > Components: rtf >Affects Versions: trunk >Reporter: Markus Sticker > Attachments: ListItem_error.fo, ListItem_error.fo.pdf, > ListItem_error.fo.rtf > > > If more than one block is inside a list-item-body for each block a bullet > will be shown. -- 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-2232) too much bullets, if several fo:blocks inside a list-item-body
[ https://issues.apache.org/jira/browse/FOP-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13642648#comment-13642648 ] Seifeddine Dridi commented on FOP-2232: --- A bullet per each fo:block inside an fo:list-item-body > too much bullets, if several fo:blocks inside a list-item-body > -- > > Key: FOP-2232 > URL: https://issues.apache.org/jira/browse/FOP-2232 > Project: Fop > Issue Type: Bug > Components: rtf >Affects Versions: trunk >Reporter: Markus Sticker > Attachments: ListItem_error.fo, ListItem_error.fo.pdf, > ListItem_error.fo.rtf > > > If more than one block is inside a list-item-body for each block a bullet > will be shown. -- 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-2232) too much bullets, if several fo:blocks inside a list-item-body
[ https://issues.apache.org/jira/browse/FOP-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seifeddine Dridi updated FOP-2232: -- Attachment: patch bug 2232.patch patch bug 2232.patch A dirty hack to get around the problem of displaying multiple fo blocks as list items. > too much bullets, if several fo:blocks inside a list-item-body > -- > > Key: FOP-2232 > URL: https://issues.apache.org/jira/browse/FOP-2232 > Project: Fop > Issue Type: Bug > Components: rtf >Affects Versions: trunk >Reporter: Markus Sticker > Attachments: ListItem_error.fo, ListItem_error.fo.pdf, > ListItem_error.fo.rtf, patch bug 2232.patch > > > If more than one block is inside a list-item-body for each block a bullet > will be shown. -- 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-2232) too much bullets, if several fo:blocks inside a list-item-body
[ https://issues.apache.org/jira/browse/FOP-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seifeddine Dridi updated FOP-2232: -- Attachment: (was: patch bug 2232.patch) > too much bullets, if several fo:blocks inside a list-item-body > -- > > Key: FOP-2232 > URL: https://issues.apache.org/jira/browse/FOP-2232 > Project: Fop > Issue Type: Bug > Components: rtf >Affects Versions: trunk >Reporter: Markus Sticker > Attachments: ListItem_error.fo, ListItem_error.fo.pdf, > ListItem_error.fo.rtf, patch bug 2232.patch > > > If more than one block is inside a list-item-body for each block a bullet > will be shown. -- 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-2242) PDF generation is very slow when document contains svg:text
[ https://issues.apache.org/jira/browse/FOP-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644345#comment-13644345 ] Seifeddine Dridi commented on FOP-2242: --- I don't see a any performance issue either. I tested the attached files using the latest FOP version from trunk, and PDF generation is very fast (~3s) > PDF generation is very slow when document contains svg:text > --- > > Key: FOP-2242 > URL: https://issues.apache.org/jira/browse/FOP-2242 > Project: Fop > Issue Type: Bug > Components: fonts, pdf, svg >Affects Versions: 1.1 > Environment: linux x86_64 (OpenSUSE 12.2) >Reporter: Thomas Mitterfellner > Labels: fonts, pdf, svg, text > Attachments: fo_style.xsl, test.xml > > > PDF generation is very slow when the document contains svg:text elements. > When I remove the svg:text elements, the pdf generation is very fast. > I attached the xml and xsl files to test the behavior. When lines 314-343 are > commented out (svg:text elements), pdf generation is quick. > Note: a single svg:text element is sufficient to slow down the generation > process. > If there is any further information I should provide in order to tackle this > problem, I'll try to provide 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] [Commented] (FOP-2239) Soft hyphens appear in mid line in PDF output
[ https://issues.apache.org/jira/browse/FOP-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644657#comment-13644657 ] Seifeddine Dridi commented on FOP-2239: --- The culprit code is in file TextLayoutManager.java lines [1174-1176], comment the while loop and you should be fine :). However, that change might bring regressions so we need some clarifications from a FOP developer before we can call it a fix. > Soft hyphens appear in mid line in PDF output > - > > Key: FOP-2239 > URL: https://issues.apache.org/jira/browse/FOP-2239 > Project: Fop > Issue Type: Bug > Components: pdf >Affects Versions: 1.1, trunk > Environment: $ java -version > java version "1.7.0_17" > Java(TM) SE Runtime Environment (build 1.7.0_17-b02) > Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode) >Reporter: Mark Craig > Attachments: simple.fo, simple.pdf > > > When producing PDF, soft hyphens show up in mid line when followed by > punctuation characters such as ., ], and ". > In the test case that I will attach to this issue: > .. > . . > . > .] > .\ > ." > .a > .Z > looks like this in the PDF: > .-. > . . > . > .-] > .\ > .-" > .a > .Z > The generation does not display any errors: > $ fop simple.fo simple.pdf > Rendered page #1. -- 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-2225) Inline background-color will be inherit to next cell
[ https://issues.apache.org/jira/browse/FOP-2225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13645672#comment-13645672 ] Seifeddine Dridi commented on FOP-2225: --- If you comment line 462 in RtfTextrun.writeRtfContent(), RTF generation will be correct. I'm guessing that elements inside a table cell inherit style attributes of their parent, which is fine but the problem might be that FOP is reusing objects without reinitializing them properly. For instance, when we switch the so that the one with background-color comes last, the output RTF document is correct. > Inline background-color will be inherit to next cell > > > Key: FOP-2225 > URL: https://issues.apache.org/jira/browse/FOP-2225 > Project: Fop > Issue Type: Bug > Components: rtf >Affects Versions: trunk >Reporter: Markus Sticker >Priority: Minor > Attachments: table_error_inline.fo, table_error_inline.rtf > > > Table-cells: > The inline background-color will be taken to the next cell. -- 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-2225) Inline background-color will be inherit to next cell
[ https://issues.apache.org/jira/browse/FOP-2225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13645672#comment-13645672 ] Seifeddine Dridi edited comment on FOP-2225 at 4/30/13 3:40 PM: If you comment line 462 in RtfTextrun.writeRtfContent(), RTF generation will be correct. I'm guessing that elements inside a table cell inherit style attributes of their parent, which is fine but the problem might be that FOP is reusing objects without reinitializing them properly... was (Author: sdridi): If you comment line 462 in RtfTextrun.writeRtfContent(), RTF generation will be correct. I'm guessing that elements inside a table cell inherit style attributes of their parent, which is fine but the problem might be that FOP is reusing objects without reinitializing them properly. For instance, when we switch the so that the one with background-color comes last, the output RTF document is correct. > Inline background-color will be inherit to next cell > > > Key: FOP-2225 > URL: https://issues.apache.org/jira/browse/FOP-2225 > Project: Fop > Issue Type: Bug > Components: rtf >Affects Versions: trunk >Reporter: Markus Sticker >Priority: Minor > Attachments: table_error_inline.fo, table_error_inline.rtf > > > Table-cells: > The inline background-color will be taken to the next cell. -- 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-2193) Intermediate format introduces white space in SVG while it should not
[ https://issues.apache.org/jira/browse/FOP-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13647522#comment-13647522 ] Seifeddine Dridi commented on FOP-2193: --- I cannot reproduce this issue with the latest version from trunk. Is it fixed? > Intermediate format introduces white space in SVG while it should not > - > > Key: FOP-2193 > URL: https://issues.apache.org/jira/browse/FOP-2193 > Project: Fop > Issue Type: Bug > Components: general >Affects Versions: trunk >Reporter: Vincent Hennebert > Attachments: actual.pdf, expected.pdf, fop.xconf, if.xml, > svg-if-space.fo > > > An xml:space="preserve" directive in an SVG image stored as an > instream-foreign-object is not honoured. If an svg:text has an svg:tspan as a > first child, that tspan will be put on the next line in the IF output no > matter what, resulting into a space being added (coming from the newline > between the text and the tspan) when rendering the IF into e.g., PDF. -- 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-2193) Intermediate format introduces white space in SVG while it should not
[ https://issues.apache.org/jira/browse/FOP-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13651684#comment-13651684 ] Seifeddine Dridi commented on FOP-2193: --- My output file is the same as expected.pdf. I used a fresh build to generate the PDF and I passed the attached fop.xconf to FOP like this: fop -c fop.xconf svg-if-space.fo svg-if-space.pdf > Intermediate format introduces white space in SVG while it should not > - > > Key: FOP-2193 > URL: https://issues.apache.org/jira/browse/FOP-2193 > Project: Fop > Issue Type: Bug > Components: general >Affects Versions: trunk >Reporter: Vincent Hennebert > Attachments: actual.pdf, expected.pdf, fop.xconf, if.xml, > svg-if-space.fo > > > An xml:space="preserve" directive in an SVG image stored as an > instream-foreign-object is not honoured. If an svg:text has an svg:tspan as a > first child, that tspan will be put on the next line in the IF output no > matter what, resulting into a space being added (coming from the newline > between the text and the tspan) when rendering the IF into e.g., PDF. -- 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-2193) Intermediate format introduces white space in SVG while it should not
[ https://issues.apache.org/jira/browse/FOP-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13651684#comment-13651684 ] Seifeddine Dridi commented on FOP-2193: --- My output file is the same as expected.pdf. I used a fresh build to generate the PDF and I passed the attached fop.xconf to FOP like this: fop -c fop.xconf svg-if-space.fo svg-if-space.pdf > Intermediate format introduces white space in SVG while it should not > - > > Key: FOP-2193 > URL: https://issues.apache.org/jira/browse/FOP-2193 > Project: Fop > Issue Type: Bug > Components: general >Affects Versions: trunk >Reporter: Vincent Hennebert > Attachments: actual.pdf, expected.pdf, fop.xconf, if.xml, > svg-if-space.fo > > > An xml:space="preserve" directive in an SVG image stored as an > instream-foreign-object is not honoured. If an svg:text has an svg:tspan as a > first child, that tspan will be put on the next line in the IF output no > matter what, resulting into a space being added (coming from the newline > between the text and the tspan) when rendering the IF into e.g., PDF. -- 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-2193) Intermediate format introduces white space in SVG while it should not
[ https://issues.apache.org/jira/browse/FOP-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13651709#comment-13651709 ] Seifeddine Dridi commented on FOP-2193: --- I can see the problem now > Intermediate format introduces white space in SVG while it should not > - > > Key: FOP-2193 > URL: https://issues.apache.org/jira/browse/FOP-2193 > Project: Fop > Issue Type: Bug > Components: general >Affects Versions: trunk >Reporter: Vincent Hennebert > Attachments: actual.pdf, expected.pdf, fop.xconf, if.xml, > svg-if-space.fo > > > An xml:space="preserve" directive in an SVG image stored as an > instream-foreign-object is not honoured. If an svg:text has an svg:tspan as a > first child, that tspan will be put on the next line in the IF output no > matter what, resulting into a space being added (coming from the newline > between the text and the tspan) when rendering the IF into e.g., PDF. -- 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-2220) fop does ignore the savepath for the pdf file
[
https://issues.apache.org/jira/browse/FOP-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13652840#comment-13652840
]
Seifeddine Dridi edited comment on FOP-2220 at 5/9/13 9:42 AM:
---
URLs are resolved relatively to FOP base URL (see FOP configuration). Try this
echo shell_exec('fop -xml books.xml -xsl books.xsl -pdf ' .
'./var/www//web/pdf/' . $rechnungsnummer . '.pdf');
was (Author: sdridi):
URL are resolved relatively to FOP base URL (see FOP configuration). Try
this echo shell_exec('fop -xml books.xml -xsl books.xsl -pdf ' .
'./var/www//web/pdf/' . $rechnungsnummer . '.pdf');
> fop does ignore the savepath for the pdf file
> -
>
> Key: FOP-2220
> URL: https://issues.apache.org/jira/browse/FOP-2220
> Project: Fop
> Issue Type: Bug
> Components: pdf
>Affects Versions: 1.1
> Environment: Kubuntu 12.0.4 (Kernel 3.2.0-37-generic); Apache2; FOP
> 1.1; PHP; XML; XSL
>Reporter: Ralph Dittrich
>Priority: Minor
> Labels: fop1.1, newbie, pdf, php, savepath
>
> Hi,
> I'm using php to generate the xml, xsl and trigger the fop to generate the
> pdf file. Actually fop saves the file within my web folder
> (/var/www/project/web/) but I want to save the files to the folder
> '/var/www/project/web/pdf/'.
> So my command looks (like I read on some tutorials) like this: echo
> shell_exec('fop -xml books.xml -xsl books.xsl -pdf ' .
> '/var/www//web/pdf/' . $rechnungsnummer . '.pdf');
> The Content is right and the name of the file is right but the save path is
> wrong. I also tried to use "/web/pdf/" and only "/pdf/" instead of the full
> path but everytime it saves the files to the web folder. And it throws no
> failure exception.
> Do you have any Idea why this could happen? Is this my fault or a bug in the
> fop? I couldn't figure it out.
> At least: My folders project/ web/ and pdf/ got owner: www-data:www-data and
> mod 777 for my tests. So the rights can't be the problem, right?
> Best regards
--
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-2220) fop does ignore the savepath for the pdf file
[
https://issues.apache.org/jira/browse/FOP-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13652840#comment-13652840
]
Seifeddine Dridi commented on FOP-2220:
---
URL are resolved relatively to FOP base URL (see FOP configuration). Try this
echo shell_exec('fop -xml books.xml -xsl books.xsl -pdf ' .
'./var/www//web/pdf/' . $rechnungsnummer . '.pdf');
> fop does ignore the savepath for the pdf file
> -
>
> Key: FOP-2220
> URL: https://issues.apache.org/jira/browse/FOP-2220
> Project: Fop
> Issue Type: Bug
> Components: pdf
>Affects Versions: 1.1
> Environment: Kubuntu 12.0.4 (Kernel 3.2.0-37-generic); Apache2; FOP
> 1.1; PHP; XML; XSL
>Reporter: Ralph Dittrich
>Priority: Minor
> Labels: fop1.1, newbie, pdf, php, savepath
>
> Hi,
> I'm using php to generate the xml, xsl and trigger the fop to generate the
> pdf file. Actually fop saves the file within my web folder
> (/var/www/project/web/) but I want to save the files to the folder
> '/var/www/project/web/pdf/'.
> So my command looks (like I read on some tutorials) like this: echo
> shell_exec('fop -xml books.xml -xsl books.xsl -pdf ' .
> '/var/www//web/pdf/' . $rechnungsnummer . '.pdf');
> The Content is right and the name of the file is right but the save path is
> wrong. I also tried to use "/web/pdf/" and only "/pdf/" instead of the full
> path but everytime it saves the files to the web folder. And it throws no
> failure exception.
> Do you have any Idea why this could happen? Is this my fault or a bug in the
> fop? I couldn't figure it out.
> At least: My folders project/ web/ and pdf/ got owner: www-data:www-data and
> mod 777 for my tests. So the rights can't be the problem, right?
> Best regards
--
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-2246) SEVERE: Exception java.lang.IllegalArgumentException: min (1650) > opt (0)
[ https://issues.apache.org/jira/browse/FOP-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13654470#comment-13654470 ] Seifeddine Dridi commented on FOP-2246: --- Maybe specifying the limits of word-space is implementation-dependent, I'm not sure. Considering the error message generated by FOP, it seems that the minimum value should not be greater than optimum, which is set to 0 by default. > SEVERE: Exception java.lang.IllegalArgumentException: min (1650) > opt (0) > -- > > Key: FOP-2246 > URL: https://issues.apache.org/jira/browse/FOP-2246 > Project: Fop > Issue Type: Bug > Components: pdf >Affects Versions: 1.1 >Reporter: Yevgeniy Vostokov > Attachments: ExpereResponse.fo, expereresponse.pdf, fop-log.txt, > xep-log.txt > > > I am getting an Exception java.lang.IllegalArgumentException: min (1650) > > opt (0) > and PDF is not getting created. > I can generate PDF from the same FO file using XEP. > If I remove the attribute word-spacing.minimum from the fo file it fixes it. > Apparently the code expects the optimum and maximum to be also specified if > the minimum is and in this case they are not. If I add optimum and maximim > attributes it works too. -- 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-2246) SEVERE: Exception java.lang.IllegalArgumentException: min (1650) > opt (0)
[ https://issues.apache.org/jira/browse/FOP-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13654475#comment-13654475 ] Seifeddine Dridi commented on FOP-2246: --- If you have access to FOP repository, there is a sample file (inline_word-spacing.xml) in (test\layoutengine\standard-testcases) which showcases word-spacing. > SEVERE: Exception java.lang.IllegalArgumentException: min (1650) > opt (0) > -- > > Key: FOP-2246 > URL: https://issues.apache.org/jira/browse/FOP-2246 > Project: Fop > Issue Type: Bug > Components: pdf >Affects Versions: 1.1 >Reporter: Yevgeniy Vostokov > Attachments: ExpereResponse.fo, expereresponse.pdf, fop-log.txt, > xep-log.txt > > > I am getting an Exception java.lang.IllegalArgumentException: min (1650) > > opt (0) > and PDF is not getting created. > I can generate PDF from the same FO file using XEP. > If I remove the attribute word-spacing.minimum from the fo file it fixes it. > Apparently the code expects the optimum and maximum to be also specified if > the minimum is and in this case they are not. If I add optimum and maximim > attributes it works too. -- 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-tabpanel&focusedCommentId=13668196#comment-13668196 ] Seifeddine Dridi commented on FOP-2230: --- I found a workaround, it isn't an elegant solution but I think it works just fine. Basically, I retrieve the number of spanned rows for the current cell then check if the cell height is as expected (rows-spanned x default-cell-height). I have assumed that default-cell-height is 18900 (bpd?) because I couldn't find a way to get the cell height before row spanning is applied. Any feedback is of course welcome. P.S. Check attached patch > 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: rowspanning.patch, 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] [Updated] (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:all-tabpanel ] Seifeddine Dridi updated FOP-2230: -- Attachment: rowspanning.patch > 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: rowspanning.patch, 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-2212) o.a.f.fonts.Font.getKernValue should take glyph indices and not characters as parameters
[ https://issues.apache.org/jira/browse/FOP-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13679365#comment-13679365 ] Seifeddine Dridi commented on FOP-2212: --- It seems that the whole class (Font) is using char to represent characters. Replacing char by Glyph would be more appropriate perhaps but there will be some heavy refactoring to do. Just saying... > o.a.f.fonts.Font.getKernValue should take glyph indices and not characters as > parameters > > > Key: FOP-2212 > URL: https://issues.apache.org/jira/browse/FOP-2212 > Project: Fop > Issue Type: Bug > Components: fonts >Reporter: Vincent Hennebert > > Kerning is intrinsic to glyphs and not characters. One character may be > mapped to several different glyphs. -- 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] [Created] (FOP-2292) NullPointerException after page IPD change
Seifeddine Dridi created FOP-2292: - Summary: 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 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) NullPointerException after page IPD change
[ https://issues.apache.org/jira/browse/FOP-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seifeddine Dridi updated FOP-2292: -- Attachment: (was: thelem.rar) > 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: thelem.rar > > > 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) NullPointerException after page IPD change
[ https://issues.apache.org/jira/browse/FOP-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seifeddine Dridi updated FOP-2292: -- Attachment: thelem.rar > 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: thelem.rar > > > 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) NullPointerException after page IPD change
[ https://issues.apache.org/jira/browse/FOP-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seifeddine Dridi updated FOP-2292: -- Attachment: thelem.rar > 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: thelem.rar > > > 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) NullPointerException after page IPD change
[ https://issues.apache.org/jira/browse/FOP-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seifeddine Dridi updated FOP-2292: -- Attachment: (was: thelem.rar) > 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: thelem.rar > > > 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) NullPointerException after page IPD change
[ https://issues.apache.org/jira/browse/FOP-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seifeddine Dridi updated FOP-2292: -- Attachment: thelem.rar > 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: thelem.rar > > > 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) NullPointerException after page IPD change
[ https://issues.apache.org/jira/browse/FOP-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seifeddine Dridi updated FOP-2292: -- Attachment: idea.patch This is a rough implementation of a patch. It is working for the attached FO, but I need your feedback to improve it. > 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, thelem.rar > > > 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] [Comment Edited] (FOP-2292) NullPointerException after page IPD change
[ https://issues.apache.org/jira/browse/FOP-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13747526#comment-13747526 ] Seifeddine Dridi edited comment on FOP-2292 at 8/22/13 1:40 PM: I've attached a rough implementation of a patch. It is working for the attached FO, but I need your feedback to improve it. was (Author: sdridi): This is a rough implementation of a patch. It is working for the attached FO, but I need your feedback to improve it. > 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, thelem.rar > > > 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 ] Seifeddine Dridi updated FOP-2292: -- Attachment: (was: thelem.rar) > [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] [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-tabpanel&focusedCommentId=13749885#comment-13749885 ] Seifeddine Dridi commented on FOP-2292: --- I deleted the original attached files because they contain company informations that I'm not allowed to disclose. I'm going to upload new test files. > [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] [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 ] Seifeddine Dridi updated FOP-2292: -- Attachment: test.fo expected.pdf the pdf file was generated after I applied the attached patch to FOP > [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] [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 ] Seifeddine Dridi updated FOP-2292: -- Attachment: test.fo > [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] [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 ] Seifeddine Dridi updated FOP-2292: -- Attachment: (was: test.fo) > [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] [Created] (FOP-2293) Whitespace management extension
Seifeddine Dridi created FOP-2293: - Summary: 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 Fix For: trunk 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-2293) Whitespace management extension
[ https://issues.apache.org/jira/browse/FOP-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seifeddine Dridi updated FOP-2293: -- Attachment: bestfit.fo > 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 > Fix For: trunk > > Attachments: bestfit.fo, patch.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-2293) Whitespace management extension
[ https://issues.apache.org/jira/browse/FOP-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seifeddine Dridi updated FOP-2293: -- Attachment: patch.patch It contains a junit test case in KnuthAlgorithmTestCase.java > 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 > Fix For: trunk > > Attachments: bestfit.fo, patch.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-2293) Whitespace management extension
[ https://issues.apache.org/jira/browse/FOP-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seifeddine Dridi updated FOP-2293: -- Attachment: doc.pdf It's an outdated document but it describes my requirement a little bit > 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 > Fix For: trunk > > Attachments: bestfit.fo, doc.pdf, patch.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-2292) [PATCH] NullPointerException after page IPD change
[ https://issues.apache.org/jira/browse/FOP-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750076#comment-13750076 ] Seifeddine Dridi commented on FOP-2292: --- >Both latest FOP release (v1.1) and development version do not throw any >Exception. Are you sure? I just tested it again with the latest revision of FOP and it doesn't work. Can you attach the generated PDF? >Looking at the expected.pdf, it appears to be generated with FOP v1.0a, witch >is quite old. That's right! The attached PDF was generated with an older version of FOP (the version we actually use in production), just to demonstrate how the document would look like. > [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] [Updated] (FOP-2293) Whitespace management extension
[ https://issues.apache.org/jira/browse/FOP-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seifeddine Dridi updated FOP-2293: -- Labels: XSL-FO (was: ) > 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, patch.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-tabpanel&focusedCommentId=13749947#comment-13749947 ] Seifeddine Dridi edited comment on FOP-2293 at 8/26/13 2:25 PM: doc.pdf is an outdated document but it describes my requirements a little bit was (Author: sdridi): It's an outdated document but it describes my requirement a little bit > 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, patch.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-tabpanel&focusedCommentId=13749946#comment-13749946 ] Seifeddine Dridi edited comment on FOP-2293 at 8/26/13 2:26 PM: the attached patch contains a junit test case inside KnuthAlgorithmTestCase.java was (Author: sdridi): It contains a junit test case in KnuthAlgorithmTestCase.java > 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, patch.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-2292) [PATCH] NullPointerException after page IPD change
[ https://issues.apache.org/jira/browse/FOP-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13751060#comment-13751060 ] Seifeddine Dridi commented on FOP-2292: --- I've just realized that I'm using FOP 1.0beta2. Weird, it's the version I pulled out from trunk http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk. Why it's not the latest 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: 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-tabpanel&focusedCommentId=13751063#comment-13751063 ] Seifeddine Dridi commented on FOP-2292: --- Even with FOP v1.1 (http://apache.mirrors.hoobly.com/xmlgraphics/fop/binaries/), I still get an NPE. This doesn't make sense :/ > [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-tabpanel&focusedCommentId=13751104#comment-13751104 ] Seifeddine Dridi commented on FOP-2292: --- Great remark Vincent! The problem is with the usage of the Helvetica font. I replaced it with Arial and now everything works (FOP v1.1 and trunk) > [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-tabpanel&focusedCommentId=13751146#comment-13751146 ] Seifeddine Dridi commented on FOP-2292: --- >Could you post an updated example that uses only standard fonts and no images? I can do that but what's the point? However, I'm not sure yet if this is a FOP bug or maybe the Helvetica font on my system is corrupted. > [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-tabpanel&focusedCommentId=13751175#comment-13751175 ] Seifeddine Dridi commented on FOP-2292: --- >That's why it would be good if it could be reproduced with Helvetica, so that >it can be investigated. What do you mean exactly? It is already reproducible with Helvetica. > [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] [Reopened] (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 ] Seifeddine Dridi reopened FOP-2292: --- Just to clarify. It seems that this bug is platform-dependent, so I'll try to attach an FO that reproduces the issue on all platforms. > [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] [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 ] Seifeddine Dridi updated FOP-2292: -- Environment: Windows 7 64 bit > [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 > Environment: Windows 7 64 bit >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-tabpanel&focusedCommentId=13753700#comment-13753700 ] Seifeddine Dridi commented on FOP-2292: --- The cause of this bug is still unknown to me. But after a couple of tests, the NullPointerException seems to be also related to having different margins across pages, which triggers an IPD-change. Setting the left/right margins equally in all fo:simple-page-master fixes the error...Any suggestions? > [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 > Environment: Windows 7 64 bit >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-2293) Whitespace management extension
[ https://issues.apache.org/jira/browse/FOP-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13754507#comment-13754507 ] Seifeddine Dridi commented on FOP-2293: --- Thanks for your thorough review Vincent. I suppose it took you some time to write it. I'll try to address the issues you mentioned in my next commits and we'll see where this is going to lead us. As for the documentation, I'll see if I can update the Wiki page on whitespace management (do I need writing access rights?), post any ideas/concerns and hopefully it will spark a positive discussion. > 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 > > > 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-tabpanel&focusedCommentId=13754790#comment-13754790
]
Seifeddine Dridi edited comment on FOP-2293 at 8/30/13 3:32 PM:
> Why should the test for difference be > 0 only? A negative difference is ok
> as long as the adjustment ratio is >= -1.
Good point! Thanks for pointing it out
> Creating a new KnuthPenalty for every alternative is not ideal. It should be
> created once and stored in the alternative.
Why do you say that? I don't create a KnuthPenalty for every alternative.
> alternativeManager will work only if there is only one extension in the
> document. If there are more, they will be mixed up in the same instance (see
> multiple-feasible-nodes.fo).
Where can I find multiple-feasible-nodes.fo? I couldn't find it the examples
directory.
> The calcFullContentLength shouldn’t be necessary: you can probably call
> SpaceResolver.resolveElementList first and then use the standard
> calcContentLength method.
I tried it before but it didn't work.
> if there’s no room on the page, the content will be unconditionally put on
> the next page. Is that what you want? I suppose this aspect is still work in
> progress.
If there 0 space left on the current page, then the content will be put on the
next page. I'm going to leave it like that for now.
> validateChildNode: I don’t think you want to check elements in the fox
> namespace. If you start like this you might as well check for elements in the
> SVG namespace, and the MathML namespace, etc. Some generic, all-purpose
> solution would have to be devised to check foreign elements, but this is
> getting off-topic.
-> Well, I did it because I don't want nested alternative-block or best-fit. I
understand your point but what else can I do to prevent the user from messing
it up? Maybe the best way would be something like this:
{code:java}
if (FOX_URI.equals(nsURI)) {
if ("best-fit".equals(localName) ||
"alternative-block".equals(localName)) {
invalidChildError(loc, FOX_URI, localName);
}
} else {
invalidChildError(loc, nsURI, localName);
}
{code}
> addChildArea: not sure if the test curBlockArea != null is necessary, since
> it is initialized in getParentArea. Also, IIUC you are going to deal with
> block areas only, as per the definition of fox:alternative-block
For now yes, but later I would like alternative-block to have all sort of
formatting objects as childs, not just FO blocks.
> there is code duplicated from other LMs. This is fine for now, but eventually
> it would be good to remove that duplication from all the LMs. We can get back
> to that later.
You have no idea how much I resent code duplication, but I just couldn't help
it there :)
Thanks again Vincent. I'll attach the new patch ASAP
Best Regards,
Seifeddine
was (Author: sdridi):
> Why should the test for difference be > 0 only? A negative difference is
ok as long as the adjustment ratio is >= -1.
Good point! Thanks for pointing it out
> Creating a new KnuthPenalty for every alternative is not ideal. It should be
> created once and stored in the alternative.
Why do you say that? I don't create a KnuthPenalty for every alternative.
> alternativeManager will work only if there is only one extension in the
> document. If there are more, they will be mixed up in the same instance (see
> multiple-feasible-nodes.fo).
Where can I find multiple-feasible-nodes.fo? I couldn't find it the examples
directory.
> The calcFullContentLength shouldn’t be necessary: you can probably call
> SpaceResolver.resolveElementList first and then use the standard
> calcContentLength method.
I tried it before but it didn't work.
> if there’s no room on the page, the content will be unconditionally put on
> the next page. Is that what you want? I suppose this aspect is still work in
> progress.
If there 0 space left on the current page, then the content will be put on the
next page. I'm going to leave it like that for now.
> validateChildNode: I don’t think you want to check elements in the fox
> namespace. If you start like this you might as well check for elements in the
> SVG namespace, and the MathML namespace, etc. Some generic, all-purpose
> solution would have to be devised to check foreign elements, but this is
> getting off-topic.
-> Well, I did it because I don't want nested alternative-block or best-fit. I
understand your point but what else can I do to prevent the user from messing
it up? Maybe the best way would be something like this:
if (FOX_URI.equals(nsURI)) {
if ("best-fit".equals(localName) ||
"alternative-block".equals(localName)) {
invalidChildError(loc, FOX_URI, localName);
}
} else {
invalidC
[jira] [Commented] (FOP-2293) Whitespace management extension
[
https://issues.apache.org/jira/browse/FOP-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13754790#comment-13754790
]
Seifeddine Dridi commented on FOP-2293:
---
> Why should the test for difference be > 0 only? A negative difference is ok
> as long as the adjustment ratio is >= -1.
Good point! Thanks for pointing it out
> Creating a new KnuthPenalty for every alternative is not ideal. It should be
> created once and stored in the alternative.
Why do you say that? I don't create a KnuthPenalty for every alternative.
> alternativeManager will work only if there is only one extension in the
> document. If there are more, they will be mixed up in the same instance (see
> multiple-feasible-nodes.fo).
Where can I find multiple-feasible-nodes.fo? I couldn't find it the examples
directory.
> The calcFullContentLength shouldn’t be necessary: you can probably call
> SpaceResolver.resolveElementList first and then use the standard
> calcContentLength method.
I tried it before but it didn't work.
> if there’s no room on the page, the content will be unconditionally put on
> the next page. Is that what you want? I suppose this aspect is still work in
> progress.
If there 0 space left on the current page, then the content will be put on the
next page. I'm going to leave it like that for now.
> validateChildNode: I don’t think you want to check elements in the fox
> namespace. If you start like this you might as well check for elements in the
> SVG namespace, and the MathML namespace, etc. Some generic, all-purpose
> solution would have to be devised to check foreign elements, but this is
> getting off-topic.
-> Well, I did it because I don't want nested alternative-block or best-fit. I
understand your point but what else can I do to prevent the user from messing
it up? Maybe the best way would be something like this:
if (FOX_URI.equals(nsURI)) {
if ("best-fit".equals(localName) ||
"alternative-block".equals(localName)) {
invalidChildError(loc, FOX_URI, localName);
}
} else {
invalidChildError(loc, nsURI, localName);
}
> addChildArea: not sure if the test curBlockArea != null is necessary, since
> it is initialized in getParentArea. Also, IIUC you are going to deal with
> block areas only, as per the definition of fox:alternative-block
-> For now yes, but later I would like alternative-block to have all sort of
formatting objects as childs, not just FO blocks.
there is code duplicated from other LMs. This is fine for now, but eventually
it would be good to remove that duplication from all the LMs. We can get back
to that later.
-> You have no idea how much I resent code duplication, but I just couldn't
help it there :)
Thanks again Vincent. I'll attach the new patch ASAP
Best Regards,
Seifeddine
> 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
>
>
> 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-tabpanel&focusedCommentId=13756136#comment-13756136
]
Seifeddine Dridi commented on FOP-2293:
---
{quote}
totalWidth should not be updated if an alternative is found, since you’re
dealing with a penalty element.
{quote}
That broke the JUnit test. It no longer gives the expected result.
> 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
>
>
> 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-2293) Whitespace management extension
[ https://issues.apache.org/jira/browse/FOP-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seifeddine Dridi updated FOP-2293: -- Attachment: patch-rev1.patch *Changelog (revision 1):* * Code refactoring: ** Improved FittingStrategy as suggested by Vincent ** Removed some unnecessary code from BestFitPenalty ** Deleted AlternativeManager and moved its logic to BestFitPenalty. The "best" alternative is now stored inside BestFitPenalty and BestFitLayoutManager has a reference to it. ** Removed the fox namespace from fitting-strategy ** Fixed some checkstyle warnings * Fixed a bug when fox:best-fit is the last element in the document flow And many other minor changes. > 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.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-tabpanel&focusedCommentId=13756597#comment-13756597 ] Seifeddine Dridi commented on FOP-2293: --- I couldn't find a way to edit the Wiki page on whitespace management. It seems to be immutable. Can anyone handle that issue? I'd like to add some new content to 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, multiple-feasible-nodes.fo, > patch.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-tabpanel&focusedCommentId=13756608#comment-13756608 ] Seifeddine Dridi commented on FOP-2293: --- It is only meant to be used in FO instance files. Needless to say, the "fitting-strategy" property is only relevant to fox:best-fit. Should I restore the fox prefix? > 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.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-2293) Whitespace management extension
[ https://issues.apache.org/jira/browse/FOP-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seifeddine Dridi updated FOP-2293: -- Attachment: patch-rev1.1.patch Added the fox namespace to the "fitting-strategy" attribute > 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-tabpanel&focusedCommentId=13756669#comment-13756669 ] Seifeddine Dridi commented on FOP-2293: --- Interesting read! The proposal is indirectly related to what I'm doing and it would useful to add such features to FOP. However, I'm not sure if the current design of FOP allows such flexibility in the choice of the text-breaking algorithm since the layout engine seems to be mainly tied around the Knuth & Plass implementation. > 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-tabpanel&focusedCommentId=13756699#comment-13756699 ] Seifeddine Dridi 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). > 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-tabpanel&focusedCommentId=13756781#comment-13756781
]
Seifeddine Dridi commented on FOP-2293:
---
{quote}
However, this raises (in my mind) the question of why fox:best-fit is an
element, as opposed to being treated like a normal FO property for which
inheritance may apply as well as other FO property semantics.
{quote}
Because the type of content a fox:best-fit element should represent is very
specific, I think. The purpose of the extension is to help managing the
whitespace at the end of a page, and any content that can be put there is
usually not very "important". It may be a signature or some advertisements...
> 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-tabpanel&focusedCommentId=13757526#comment-13757526 ] Seifeddine Dridi commented on FOP-2293: --- We shouldn't rush into making conclusions. This is still work in progress, and it is in very early stage of development. What I had previously said is just speculation, nothing more. I don't have very specific goals right now, that's why I want the community to determine the evolution of this work, for the benefit of us all. > 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-tabpanel&focusedCommentId=13757829#comment-13757829 ] Seifeddine Dridi commented on FOP-2293: --- Thanks for your clarifications concerning the proper usage of XML namespace in FOP. 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. > 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-tabpanel&focusedCommentId=13759075#comment-13759075
]
Seifeddine Dridi commented on FOP-2293:
---
{quote}
It would still be better though to move the creation of the penalty inside the
alternative.
{quote}
I didn't understand what you wanted to say. The best fit penalty is supposed to
act as a container for the whole set of alternatives, it can't be the other way
around.
{quote}
That would be better encapsulation, and that would avoid you to create another
one in the else part at the end of the method.
{quote}
Which method are you referring to?
> 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-tabpanel&focusedCommentId=13759084#comment-13759084 ] Seifeddine Dridi commented on FOP-2293: --- Thanks Chris for your encouraging comment. Feel free to post your critics as well. I'm sure, given the good constructive feedback, we can take this little extension very far ahead. > 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-tabpanel&focusedCommentId=13761853#comment-13761853 ] Seifeddine Dridi commented on FOP-2293: --- I wasn't aware of fo:multi-switch when I started doing my work. I agree with what you've said, it seems that fo:multi-switch is designed to statically activate/deactivate certain parts of an FO put together inside fo:multi-case elements. We can make it more "dynamic" by defining fox properties to alternatively select content in a smart way (e.g. using fitting strategies), but I'm afraid that will be like defying its very purpose, don't you think? > 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-tabpanel&focusedCommentId=13764310#comment-13764310 ] Seifeddine Dridi commented on FOP-2293: --- You made your point very clear Glenn, but at this point I don't want to throw everything away and start over from scratch. Plus I don't have enough time either. So for now, I want to make this little extension ready for production work, then if things went straight I'll reconsider implementing fo:multi-switch. All the best, Seifeddine > 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-2293) Whitespace management extension
[ https://issues.apache.org/jira/browse/FOP-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seifeddine Dridi updated FOP-2293: -- Attachment: patch-rev2.patch I attached a second revision which improves the overall structure of the code, and adds some comments here and there. > 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-2298) [PATCH] Enable support for PDF page transitions.
[
https://issues.apache.org/jira/browse/FOP-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13769365#comment-13769365
]
Seifeddine Dridi commented on FOP-2298:
---
Build is still broken on my side. I receive the following error when I build
FOP from the command line:
{code}
[javac] C:\Java Programming\FOP_SVN\src\java\org\apache\fop\rend
er\pdf\extensions\PDFDictionaryAttachment.java:45: method does not override a me
thod from its superclass
[javac] @Override
[javac] ^
[javac] 1 error
{code}
> [PATCH] Enable support for PDF page transitions.
>
>
> Key: FOP-2298
> URL: https://issues.apache.org/jira/browse/FOP-2298
> Project: Fop
> Issue Type: New Feature
>Affects Versions: trunk
>Reporter: Glenn Adams
>Assignee: Glenn Adams
> Fix For: trunk
>
> Attachments: patch.diff
>
>
> See http://marc.info/?l=fop-user&m=130017885816296&w=2.
--
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-tabpanel&focusedCommentId=13770640#comment-13770640 ] Seifeddine Dridi commented on FOP-2293: --- Hello, Given the suggestion of Glenn and the fact that no XSL-FO renderer out there fully supports fo multi-switch, I decided to give it a go. Currently, things are going smoothly -- I have a very primitive implementation already working -- and the XSL-FO spec has been really helpful and mostly clear on the subject. However, I'm having some concerns towards the correct interpretation of fo multi-toggle. The spec suggests that it should be implemented as a click-able area, or at least that's what I understood, so I wonder if someone can shed some light on this and help clear the confusion. Regards Seifeddine > 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] [Updated] (FOP-2293) Whitespace management extension
[ https://issues.apache.org/jira/browse/FOP-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seifeddine Dridi updated FOP-2293: -- Attachment: FO_multi-switch.patch Hello again, So I'm currently working on an implementation of FO multi-switch which should allow the support for arbitrary extension elements (e.g. best-fit) to act on the list of FO multi-case and define how they should be treated. The attached patch contains a rather "sketchy" implementation which demonstrates the architecture that I have in mind -- everything is working right now, more or less (there might be bugs, who knows?) -- and I would like to know if someone could review the code and point out any errors/improvements, before I move on into implementing the best-fit extension. Thank you for your support Seifeddine > 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, > 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] [Updated] (FOP-2293) Whitespace management extension
[ https://issues.apache.org/jira/browse/FOP-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seifeddine Dridi updated FOP-2293: -- Attachment: FO_multi-switch_test.fo FO test case > 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, 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-tabpanel&focusedCommentId=13781716#comment-13781716
]
Seifeddine Dridi commented on FOP-2293:
---
{quote}
Regarding your latest test.fo case, I don't understand how you plan to add the
whitespace management extension.
{quote}
It was already added. The basic structure is already there in the code, the
only thing missing is the core logic of the extension which isn't too hard to
implement once I find a good solution. I can still reintegrate the old
extension code and call it done, but I want something better.
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.
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.
> 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-tabpanel&focusedCommentId=13781820#comment-13781820
]
Seifeddine Dridi commented on FOP-2293:
---
{quote}
I disagree with Vincent on this point. We need to come to consensus in a public
discussion. Otherwise, there may be vetoes when it comes time to process a
request to integrate a patch. I had thought we had reached a degree of
consensus previously, so I'm surprised that you haven't followed it.
{quote}
My FOP experience is still new, so I try to listen to as many opinions as
possible before making the final decision. Like I said, I'm still open to
suggestions/advices. I'm just experimenting after all and there is nothing
definite yet. Maybe Vincent can express himself on this matter.
{quote}
There is nothing in the spec of multi-switch that suggests whether its cases
are all processed (for layout) at once (eagerly) or upon toggling (lazily). You
appear to be reading into the spec when you suggest this is not the case.
{quote}
Correct. There are details in the spec that I had probably overlooked or maybe
I went too far with my own interpretation...In your opinion, what's the best
way to integrate best-fit into FO multi-switch, while still adhering to the
XSL-FO standards?
> 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-tabpanel&focusedCommentId=13781835#comment-13781835
]
Seifeddine Dridi commented on FOP-2293:
---
{quote}
I'm not convinced on why new fox element is better than new fox attribute.
{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.
> 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-tabpanel&focusedCommentId=13781858#comment-13781858 ] Seifeddine Dridi commented on FOP-2293: --- I think one extension property on FO multi-switch is enough. There is no need for fox:auto-switch on fo:multi-toggle. > 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-tabpanel&focusedCommentId=13781869#comment-13781869 ] Seifeddine Dridi commented on FOP-2293: --- I like the name auto-toggle, but what about the fitting strategy? > 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-tabpanel&focusedCommentId=13783741#comment-13783741
]
Seifeddine Dridi commented on FOP-2293:
---
{code}
Case 1
Case 2
{code}
A dangling fox:dynamic-content? I don't think it's a good idea, even
implementation wise it would be quite cumbersome to deal with. I'm afraid I'm
more biased toward Glenn proposition. The best-fit extension is more like a
generalisation of what FO multi-toggle is doing, it can select one or multiple
FO multi-case depending on the user's fitting strategy. That's why I think it
must be put inside FO multi-switch, as a property or as a new element we can
still discuss that if there are more objections.
{quote}
I have conflicts when I try to apply your patch against the HEAD of the
Temp_WhitespaceManagement branch. Also, your patch contains many tab characters
and doesn't compile against Java 1.5 (@Override on methods that implement an
interface).
{quote}
Sorry about that. I worked on that patch using the latest trunk revision of FOP
which isn't configured to use Java 1.5.
{quote}
Would you mind re-creating it against the latest version of the branch and
fixing those issues?
{quote}
Never mind, the patch is not supposed to be committed anyway. I shared it
because I thought maybe we can discuss my initial implementation of FO
multi-switch, before I move on to adding the best-fit extension.
> 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-tabpanel&focusedCommentId=13784899#comment-13784899 ] Seifeddine Dridi commented on FOP-2293: --- The easiest way is not always the best option. For now, I'll go with what Glenn and Pascal had suggested and see where this is going to lead. We can go back later and refine things if necessary. And yes, you can commit that patch. Thanks everyone. > 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] [Created] (FOP-2300) NullPointerException when removing a child node
Seifeddine Dridi created FOP-2300: - Summary: NullPointerException when removing a child node Key: FOP-2300 URL: https://issues.apache.org/jira/browse/FOP-2300 Project: Fop Issue Type: Bug Affects Versions: trunk Reporter: Seifeddine Dridi Fix For: trunk A call to FObj.removeChild() when the actual FO object has only one child and no sibling results in a NullPointerException. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (FOP-2300) NullPointerException when removing a child node
[ https://issues.apache.org/jira/browse/FOP-2300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seifeddine Dridi updated FOP-2300: -- Attachment: patch.patch > NullPointerException when removing a child node > --- > > Key: FOP-2300 > URL: https://issues.apache.org/jira/browse/FOP-2300 > Project: Fop > Issue Type: Bug >Affects Versions: trunk >Reporter: Seifeddine Dridi > Fix For: trunk > > Attachments: patch.patch > > > A call to FObj.removeChild() when the actual FO object has only one child and > no sibling results in a NullPointerException. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (FOP-2300) [Patch] NullPointerException when removing a child node
[ https://issues.apache.org/jira/browse/FOP-2300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seifeddine Dridi updated FOP-2300: -- Summary: [Patch] NullPointerException when removing a child node (was: NullPointerException when removing a child node) > [Patch] NullPointerException when removing a child node > --- > > Key: FOP-2300 > URL: https://issues.apache.org/jira/browse/FOP-2300 > Project: Fop > Issue Type: Bug >Affects Versions: trunk >Reporter: Seifeddine Dridi > Fix For: trunk > > Attachments: patch.patch > > > A call to FObj.removeChild() when the actual FO object has only one child and > no sibling results in a NullPointerException. -- 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 ] Seifeddine Dridi updated FOP-2293: -- Attachment: (was: FO_multi-switch.patch) > 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_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 ] Seifeddine Dridi updated FOP-2293: -- Attachment: FO_multi-switch_with_best-fit_extension.patch _Changelog_ * Added a basic implementation of FO multi-switch. * Added new extension properties (fox:auto-toggle and fox:fitting-strategy) to FO multi-switch, which enable different handling of the set of mutli-case(s). * New fitting strategy (any) added to best-fit; it loops over the mutli-case(s) and inserts any alternative that can be fitted inside the current page. * Moved the core logic of the best-fit extension to PageBreakingAlgorithm, as suggested by Vincent. _Current issues_ * Inserting inline content inside an FO multi-case makes FOP crash. This is because any inline tag should be wrapped inside a block-level container. The solution that I found so far, is that once the currently visible multi-case is known, we can insert it as a child of the parent of the FO multi-switch and remove the multi-switch altogether. But this doesn't work in case the best-fit extension is enabled. * The extension does not yet support changing page IPD. > 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_test.fo, > FO_multi-switch_with_best-fit_extension.patch, 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] [Closed] (FOP-2300) [Patch] NullPointerException when removing a child node
[ https://issues.apache.org/jira/browse/FOP-2300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seifeddine Dridi closed FOP-2300. - Resolution: Fixed > [Patch] NullPointerException when removing a child node > --- > > Key: FOP-2300 > URL: https://issues.apache.org/jira/browse/FOP-2300 > Project: Fop > Issue Type: Bug >Affects Versions: trunk >Reporter: Seifeddine Dridi > Fix For: trunk > > Attachments: patch.patch > > > A call to FObj.removeChild() when the actual FO object has only one child and > no sibling results in a NullPointerException. -- 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-tabpanel&focusedCommentId=13789260#comment-13789260
]
Seifeddine Dridi commented on FOP-2293:
---
{quote}
Could you explain more of what you mean by "insert it as a child of the parent
of the FO multi-switch"? What is "it" here?
{quote}
"it" refers to the currently selected multi-case. What I meant is that once we
know the multi-case element that will be rendered, we take all of its child and
add them to the parent of the multi-switch.
For example:
{code}
Case 1
{code}
Will be transformed as if it was written like this:
{code}
Case 1
{code}
So we effectively remove the 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, FO_multi-switch_test.fo,
> FO_multi-switch_with_best-fit_extension.patch, 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-tabpanel&focusedCommentId=13789282#comment-13789282
]
Seifeddine Dridi commented on FOP-2293:
---
{quote}
I don't see a need to remove it, but rather to have it simply pass the areas
generated by the selected case along to its parent.
{quote}
The problem occurs exactly at the layout stage, when *_getNextKnuthElements()_*
is called for the inline content. I did a quick debugging session and it seems
that the *_InlineLayoutManager_* expects the parent alignment context to be set
in *_LayoutContext_*. And setting that requires some low level knowledge (line
height, font, bpd, etc...) that cannot be retrieved easily.
> 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_test.fo,
> FO_multi-switch_with_best-fit_extension.patch, 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-tabpanel&focusedCommentId=13789305#comment-13789305 ] Seifeddine Dridi commented on FOP-2293: --- ok, thanks. Could you please review my implementation of 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, FO_multi-switch_test.fo, > FO_multi-switch_with_best-fit_extension.patch, 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-tabpanel&focusedCommentId=13789333#comment-13789333 ] Seifeddine Dridi commented on FOP-2293: --- I just remembered that setting the alignment context is only possible by inline-level LMs, because the constructors of AlignmentContext are either private or protected so the accessibility is limited to the org.apache.fop.layoutmgr.inline package. Anyway, I don't want to delve too much over technical details. But the only way to properly render an FO inline right now, is by enclosing it inside a LineLayoutManager. However, the latter requires an object of type FO block to be passed as its parent. I hope you understand the dilemma :) > 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_test.fo, > FO_multi-switch_with_best-fit_extension.patch, 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-tabpanel&focusedCommentId=13790353#comment-13790353
]
Seifeddine Dridi commented on FOP-2293:
---
I think I found a workaround, and it seems to be working seamlessly. In
_AbstractLayoutManager.createChildLMs()_ I added a new test:
{code}
...
if (foNode instanceof MultiSwitch) {
foNode = ((MultiSwitch) foNode).getCurrentlyVisibleNode();
}
if (foNode != null) {
getPSLM().getLayoutManagerMaker().makeLayoutManagers(foNode, newLMs);
}
{code}
then in _MultiCaseLayoutManagerMaker_, I simply return the list of LMs of the
children of the multi-case, presumably they are valid children of the parent of
the multi-switch. However, this doesn't solve the case where the best-fit
extension is enabled, since the set of multi-case(s) have to be evaluated by
_BestFitLayoutManager_. Any ideas?
Thanks,
Seifeddine
> 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_test.fo,
> FO_multi-switch_with_best-fit_extension.patch, 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-tabpanel&focusedCommentId=13791302#comment-13791302
]
Seifeddine Dridi commented on FOP-2293:
---
Sorry about the inconvenience. Didn't know the patch was missing files...
{quote}
BestFit.filter: why would you want to remove children FO nodes? Seems to me
like you just want to somehow select the right one.
{quote}
That is going to change, since modifying the FO tree is not recommended after
all (see Glenn's comment). I'm still searching for other solutions to
incorporate the best-fit extension. Maybe I'll integrate the code of
_BestFitLayoutManager_ directly inside _MultiSwitchLayoutManager_.
{quote}
MultiCase.isActuated: are you sure about the test? Do you want to implement
this method at all? In the case of your extension there will be no actuation.
{quote}
The purpose of that method is to check whether the multi-case in question has
been actuated by a multi-toggle or not. It has nothing to do with the
_best-fit_ extension...
{quote}
MultiSwitch.finalizeNode: the selection of the best node cannot be done here?
You have to wait for the results of layout?
{quote}
Right, but without the extension we can find out the currently visible
multi-case early on.
{quote}
MultiToggle: why do you implement a filter method in this class? From what I
understood you're not going to use that element in your extension. Therefore
you don't have to implement it. Otherwise you have to test it...
{quote}
the multi-toggle is responsible for actuating its parent multi-case. It works
based on the currently visible multi-case and the switch-to property. Please
have a look at the newly attached patch.
In case you didn't notice, I removed the old test case in
_KnuthAlgorithmTestCase_ because it doesn't work anymore and so many things
have changed. I'm planning to add new test cases, but right now I want to focus
on improving the core logic of my extension, because the current implementation
has many limitations (no support for stretching/shrinking of glues, no support
for IPD size, etc..) and it doesn't fit very well with the rest of the layout
engine.
Thank for your review
> 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_test.fo,
> FO_multi-switch_with_best-fit_extension.patch, 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-tabpanel&focusedCommentId=13791302#comment-13791302
]
Seifeddine Dridi edited comment on FOP-2293 at 10/10/13 8:17 AM:
-
Sorry about the inconvenience. Didn't know the patch was missing files...
{quote}
BestFit.filter: why would you want to remove children FO nodes? Seems to me
like you just want to somehow select the right one.
{quote}
That is going to change, since modifying the FO tree is not recommended after
all (see Glenn's comment). I'm still searching for other solutions to
incorporate the best-fit extension. Maybe I'll integrate the code of
_BestFitLayoutManager_ directly inside _MultiSwitchLayoutManager_.
{quote}
MultiCase.isActuated: are you sure about the test? Do you want to implement
this method at all? In the case of your extension there will be no actuation.
{quote}
The purpose of that method is to check whether the multi-case in question has
been actuated by a multi-toggle or not. It has nothing to do with the
_best-fit_ extension...
{quote}
MultiSwitch.finalizeNode: the selection of the best node cannot be done here?
You have to wait for the results of layout?
{quote}
Right, but without the extension we can find out the currently visible
multi-case early on.
{quote}
MultiToggle: why do you implement a filter method in this class? From what I
understood you're not going to use that element in your extension. Therefore
you don't have to implement it. Otherwise you have to test it...
{quote}
the multi-toggle is responsible for actuating its parent multi-case. It works
based on the currently visible multi-case and the switch-to property. Please
have a look at the newly attached patch.
In case you didn't notice, I removed the old test case in
_KnuthAlgorithmTestCase_ because it doesn't work anymore and so many things
have changed. I'm planning to add new test cases, but right now I want to focus
on improving the core logic of my extension, because the current implementation
has many limitations (no support for stretching/shrinking of glues, no support
for IPD size, etc..) and it doesn't fit very well with the rest of the layout
engine.
Thanks for your review
was (Author: sdridi):
Sorry about the inconvenience. Didn't know the patch was missing files...
{quote}
BestFit.filter: why would you want to remove children FO nodes? Seems to me
like you just want to somehow select the right one.
{quote}
That is going to change, since modifying the FO tree is not recommended after
all (see Glenn's comment). I'm still searching for other solutions to
incorporate the best-fit extension. Maybe I'll integrate the code of
_BestFitLayoutManager_ directly inside _MultiSwitchLayoutManager_.
{quote}
MultiCase.isActuated: are you sure about the test? Do you want to implement
this method at all? In the case of your extension there will be no actuation.
{quote}
The purpose of that method is to check whether the multi-case in question has
been actuated by a multi-toggle or not. It has nothing to do with the
_best-fit_ extension...
{quote}
MultiSwitch.finalizeNode: the selection of the best node cannot be done here?
You have to wait for the results of layout?
{quote}
Right, but without the extension we can find out the currently visible
multi-case early on.
{quote}
MultiToggle: why do you implement a filter method in this class? From what I
understood you're not going to use that element in your extension. Therefore
you don't have to implement it. Otherwise you have to test it...
{quote}
the multi-toggle is responsible for actuating its parent multi-case. It works
based on the currently visible multi-case and the switch-to property. Please
have a look at the newly attached patch.
In case you didn't notice, I removed the old test case in
_KnuthAlgorithmTestCase_ because it doesn't work anymore and so many things
have changed. I'm planning to add new test cases, but right now I want to focus
on improving the core logic of my extension, because the current implementation
has many limitations (no support for stretching/shrinking of glues, no support
for IPD size, etc..) and it doesn't fit very well with the rest of the layout
engine.
Thank for your review
> 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_test.fo,
> FO_multi-switch_with_best-fit_extension.patch, multiple-feasible-nodes.fo,
> multi-switch_bestfit.fo, patch.patch, patch-rev1.1.patch,
[jira] [Updated] (FOP-2293) Whitespace management extension
[ https://issues.apache.org/jira/browse/FOP-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seifeddine Dridi updated FOP-2293: -- Attachment: FO_multi-switch_with_best-fit_extension.patch > 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_test.fo, > FO_multi-switch_with_best-fit_extension.patch, 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 ] Seifeddine Dridi updated FOP-2293: -- Attachment: (was: FO_multi-switch_with_best-fit_extension.patch) > 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_test.fo, > FO_multi-switch_with_best-fit_extension.patch, 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 ] Seifeddine Dridi updated FOP-2293: -- Attachment: FO_multi-switch_best-fit_ext_rev2.patch Hello again, I reimplemented the best-fit extension from scratch. Now it integrates quite well with the Knuth-Plass algorithm, but I had to remove the smallest-fit and biggest-fit strategies, leaving only first-fit. The code for the best-fit layout manager is now inside a separate helper class, since the best-fit extension is completely handled by its parent FO multi-switch and it cannot be used on its own. I tried to stick with the convention that the FO tree should not be modified to handle constraints on other levels. Remember my earlier example of FO inline inside a multi-case? I couldn't find a reasonable solution for that one yet, which works well even when the best-fit property is set. My latest patch contains a layout-engine test (_multi-switch_best-fit.xml_) which can be found in _test/layoutengine/standard-testcases_ once you apply the patch. The code for the best-fit extension is actually quite simple for anyone who understands how the Knuth-Plass algorithm works. But if you have questions or suggestions, feel free to ask. Please let me know if you spot a bug. Thanks, Seifeddine > 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_best-fit_ext_rev2.patch, FO_multi-switch_test.fo, > FO_multi-switch_with_best-fit_extension.patch, 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
]
Seifeddine Dridi updated FOP-2293:
--
Attachment: FO_multi-switch_best-fit_ext_rev3.patch
Thanks Vincent for you review,
I left some old code there because I felt like I might need it later, but with
the changes I've doing lately I guess none of it will be useful to me anymore.
{quote}
MultiCase.isActuated: not sure what you have in mind here? A multi-case cannot
be actuated? Only a multi-toggle can. This method is used in
MultiSwitch.finalizeNode, but I don’t get the point of that latter method?
{quote}
The name is misleading, I changed it to _hasToggle()_ . It returns _true_ if
the multi-case has a multi-toggle and _false_ otherwise. As for the
_finalizeNode()_ function, that's where I determine which multi-case to select.
In case my extension is enabled, I add them all.
I admit that this part of code still needs some polishing, but it's working
fine for now that's why I'm going to leave it like that until I finish
implementing the extension itself.
As for the changes in this patch:
I implemented a new class _WhiteSpaceManager_ which handles the remaining
whitespace at each page. It's better this way because the code is more
centralized now, and it becomes easier to add new features without messing up
the breaking algorithm. However, it remains challenging to add support for
multiple alternatives because of the dynamic nature of the Knuth algorithm --
we can't immediately know if the current alternative will be accepted without
peeking through the next elements -- so I left that case aside and focused on
making the extension work flawlessly with a single multi-case. And it is
working perfectly, as far as I have tested.
Until next time,
Seifeddine
> 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: FO_multi-switch_best-fit_ext_rev2.patch,
> FO_multi-switch_best-fit_ext_rev3.patch, FO_multi-switch_test.fo,
> FO_multi-switch_with_best-fit_extension.patch, bestfit.fo, doc.pdf,
> multi-switch_bestfit.fo, multiple-feasible-nodes.fo, patch-rev1.1.patch,
> patch-rev1.patch, patch-rev2.patch, patch.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-tabpanel&focusedCommentId=13823533#comment-13823533
]
Seifeddine Dridi commented on FOP-2293:
---
{quote}
And it is working perfectly, as far as I have tested.
{quote}
I guess not. There are still bugs hanging around. I have already fixed them in
my local version. I'll upload another patch ASAP with improved design.
Vincent, could you validate my new approach? Do you think it is viable in
complex scenarios?
Thanks
> 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: FO_multi-switch_best-fit_ext_rev2.patch,
> FO_multi-switch_best-fit_ext_rev3.patch, FO_multi-switch_test.fo,
> FO_multi-switch_with_best-fit_extension.patch, bestfit.fo, doc.pdf,
> multi-switch_bestfit.fo, multiple-feasible-nodes.fo, patch-rev1.1.patch,
> patch-rev1.patch, patch-rev2.patch, patch.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)
