[jira] [Resolved] (FOP-2394) [PATCH] Remove non-standard layout extensions
[ https://issues.apache.org/jira/browse/FOP-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert resolved FOP-2394. Resolution: Fixed Patch applied in rev. [1614306|http://svn.apache.org/r1614306]. > [PATCH] Remove non-standard layout extensions > - > > Key: FOP-2394 > URL: https://issues.apache.org/jira/browse/FOP-2394 > Project: Fop > Issue Type: Improvement > Components: layout/unqualified >Reporter: Vincent Hennebert > Attachments: remove-non-standard-layout-extensions.patch > > > This patch removes support for the 'distribute' and 'fill' extension values > for the display-align property, and the fox:block-progression-unit extension > property. > Those extensions have never been publicized, are not working, are untested > and get in the way every time some refactoring is done on the layout engine. > Removing them allows to remove quite a bit of code. > If nobody objects within the next few days, I'll apply the patch to trunk. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (FOP-2297) Degraded output from SVG external graphic on upgrade from fop-1.0 to fop-1.1
[ https://issues.apache.org/jira/browse/FOP-2297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert resolved FOP-2297. Resolution: Not a Problem AFAICT, the code is working as expected. In fact, before the change from rev. 987423 there were two bugs: * the target-resolution was having an effect on the image size, while it shouldn't (this is source-resolution's purpose); * the target-resolution was not being taken into account when generating raster images to represent constructs like filter effects. That means that raster images were being generated according to the SVG's original size rather than the target resolution. If the SVG ended up being scaled down in the FO document, the result was fine since the raster image was also scaled down. However, if the SVG had to be scaled up, the pixellisation was showing up. This is what prompted the change from rev. 987423. The consequence of that change is that, with default settings, images from scaled-down SVGs are now generated at a lower resolution (smaller number of pixels) than before. Which may make them look more pixellated, like for the attached Google.svg image. The good news is that it is now possible to control the resolution of raster images generated from SVG, thanks to the target-resolution config parameter being effective. The default value of 72dpi is probably a bit low for a printed output, and it wouldn't be unreasonable to set it at 300dpi. The current behaviour is better than before since the size of raster images can now be controlled, potentially saving a lot of memory and CPU if the SVG's original size is huge. > Degraded output from SVG external graphic on upgrade from fop-1.0 to fop-1.1 > > > Key: FOP-2297 > URL: https://issues.apache.org/jira/browse/FOP-2297 > Project: Fop > Issue Type: Bug > Components: renderer/svg >Affects Versions: 1.1, trunk > Environment: Verified on both MacOSX and Win32. >Reporter: Glenn Adams > Attachments: Google.svg, svg-flattening-1.0.pdf, > svg-flattening-1.1.pdf, svg-flattening.fo, test.bad.pdf, test.fo.xml, > test.good.pdf, test987422.pdf, test987423.pdf > > > When updating from JDK 1.7.0_21 to 1.7.0_25, PDF output of SVG external > graphics appears to switch to low resolution, poor rendering quality. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (FOP-2393) Gradient not properly rendered to PDF & PS
[ https://issues.apache.org/jira/browse/FOP-2393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert resolved FOP-2393. Resolution: Fixed Fixed in rev. [1611783|http://svn.apache.org/r1611783]. > Gradient not properly rendered to PDF & PS > -- > > Key: FOP-2393 > URL: https://issues.apache.org/jira/browse/FOP-2393 > Project: Fop > Issue Type: Bug > Components: renderer/pdf, renderer/ps >Reporter: Vincent Hennebert > Attachments: gradient.fo, gradient.pdf, gradient.ps, gradient.svg > > > The attached SVG file containing a gradient is not properly rendered. > In PDF the shading doesn't match the SVG. > In PostScript the orientation is wrong: the gradient doesn't go through the > rectangle's diagonal. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FOP-2394) [PATCH] Remove non-standard layout extensions
[ https://issues.apache.org/jira/browse/FOP-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert updated FOP-2394: --- Attachment: remove-non-standard-layout-extensions.patch > [PATCH] Remove non-standard layout extensions > - > > Key: FOP-2394 > URL: https://issues.apache.org/jira/browse/FOP-2394 > Project: Fop > Issue Type: Improvement > Components: layout/unqualified >Reporter: Vincent Hennebert > Attachments: remove-non-standard-layout-extensions.patch > > > This patch removes support for the 'distribute' and 'fill' extension values > for the display-align property, and the fox:block-progression-unit extension > property. > Those extensions have never been publicized, are not working, are untested > and get in the way every time some refactoring is done on the layout engine. > Removing them allows to remove quite a bit of code. > If nobody objects within the next few days, I'll apply the patch to trunk. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (FOP-2394) [PATCH] Remove non-standard layout extensions
Vincent Hennebert created FOP-2394: -- Summary: [PATCH] Remove non-standard layout extensions Key: FOP-2394 URL: https://issues.apache.org/jira/browse/FOP-2394 Project: Fop Issue Type: Improvement Components: layout/unqualified Reporter: Vincent Hennebert This patch removes support for the 'distribute' and 'fill' extension values for the display-align property, and the fox:block-progression-unit extension property. Those extensions have never been publicized, are not working, are untested and get in the way every time some refactoring is done on the layout engine. Removing them allows to remove quite a bit of code. If nobody objects within the next few days, I'll apply the patch to trunk. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FOP-2393) Gradient not properly rendered to PDF & PS
[ https://issues.apache.org/jira/browse/FOP-2393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert updated FOP-2393: --- Attachment: gradient.svg gradient.ps gradient.pdf gradient.fo > Gradient not properly rendered to PDF & PS > -- > > Key: FOP-2393 > URL: https://issues.apache.org/jira/browse/FOP-2393 > Project: Fop > Issue Type: Bug > Components: renderer/pdf, renderer/ps >Reporter: Vincent Hennebert > Attachments: gradient.fo, gradient.pdf, gradient.ps, gradient.svg > > > The attached SVG file containing a gradient is not properly rendered. > In PDF the shading doesn't match the SVG. > In PostScript the orientation is wrong: the gradient doesn't go through the > rectangle's diagonal. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (FOP-2393) Gradient not properly rendered to PDF & PS
Vincent Hennebert created FOP-2393: -- Summary: Gradient not properly rendered to PDF & PS Key: FOP-2393 URL: https://issues.apache.org/jira/browse/FOP-2393 Project: Fop Issue Type: Bug Components: renderer/pdf, renderer/ps Reporter: Vincent Hennebert The attached SVG file containing a gradient is not properly rendered. In PDF the shading doesn't match the SVG. In PostScript the orientation is wrong: the gradient doesn't go through the rectangle's diagonal. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (FOP-2385) [PATCH] Add ability to specify custom properties in the Document Information Dictionary
[
https://issues.apache.org/jira/browse/FOP-2385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Hennebert resolved FOP-2385.
Resolution: Fixed
Thanks for the review. Patch applied in
[rev.1603596|http://svn.apache.org/r1603596].
> [PATCH] Add ability to specify custom properties in the Document Information
> Dictionary
> ---
>
> Key: FOP-2385
> URL: https://issues.apache.org/jira/browse/FOP-2385
> Project: Fop
> Issue Type: Improvement
> Components: renderer/pdf
>Reporter: Vincent Hennebert
>Assignee: Vincent Hennebert
> Labels: patch
> Attachments: pdf-custom-properties.patch
>
>
> It is possible to add custom key/value pairs in the Info dictionary of a PDF
> document. Those custom properties will appear in the ‘Custom’ tab of Adobe
> Reader’s ‘Document Properties’ window (not sure about other viewers though).
> This patch adds the possibility to do that. A pdf:info element can be added
> as a child of fo:declarations and contain the custom properties. For example:
> {code:xml}
>
> http://xmlgraphics.apache.org/fop/extensions/pdf";>
> MyValue
> MyOtherValue
>
>
> {code}
> Since it’s small, I thought that would be overkill to create a branch just
> for that. So I’m putting it here for peer review.
> If nobody objects by 2014/06/12, I’m going to commit this patch to trunk.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (FOP-1099) [PATCH] footnotes within tables and lists get lost
[ https://issues.apache.org/jira/browse/FOP-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert resolved FOP-1099. Resolution: Fixed Patch committed in [rev. 1603386|http://svn.apache.org/r1603386]. > [PATCH] footnotes within tables and lists get lost > -- > > Key: FOP-1099 > URL: https://issues.apache.org/jira/browse/FOP-1099 > Project: Fop > Issue Type: Bug > Components: layout/unqualified >Affects Versions: trunk > Environment: Operating System: other > Platform: Other >Reporter: gerhard oettl > Attachments: 1044-tab-header-footnote-no-repeat.patch, > 1044-tab-header-footnote-no-repeat.xml, b37579.diff, b37579.diff, > b37579_2.patch, bugzilla37579.patch, dorfchronik.fo, dorfchronik.fo.list3, > dorfchronik.fo.table3, duplicated-footnote.fo, duplicated-footnote.pdf, > footnote-end-page-sequence.fo, footnote-end-page-sequence.pdf, > footnote-missing_page2.fo, footnote-missing_page2.pdf, footnote.fo, > footnote_repeated-table-heading.patch, footnoteintable.patch, > footnotes.080502.diff, footnotespatch, fussnote.fo, inverted-footnotes.fo, > inverted-footnotes.pdf, table_list_footnotes.diff, vtest.fo > > > Footnote outside of tables works, inside table-cell not. > The compliance page only speaks about restrictions within multicolumn > documents. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (FOP-2358) Soft hyphen is not retained on copy/paste
[ https://issues.apache.org/jira/browse/FOP-2358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14032727#comment-14032727 ] Vincent Hennebert commented on FOP-2358: If you [enable accessibility|http://xmlgraphics.apache.org/fop/1.1/accessibility.html], then the actual text (without any hyphenation character) will be stored in the output using special PDF constructs. I realise that this is not what you're asking, but it might be an acceptable work-around. To actually get the soft hyphen copy-pasted, we would have to replace the hyphen-minus (U+002D) that is currently used with a soft hyphen (U+00AD), but it's more easily said than done. We would have to put in place a custom encoding of some sort that targets the font's hyphen glyph to display on the screen (more precisely, the hyphenation character set in the FO file by the hyphenation-character property), but returns the soft hyphen on copy-paste (thanks to an appropriate entry in the ToUnicode CMap). But distinction would also have to be made between a soft hyphen that was manually added to the input text, and a hyphen that was automatically generated by the hyphenation process. And that distinction is not there at the moment. Not impossible to achieve, but a bit of work. > Soft hyphen is not retained on copy/paste > - > > Key: FOP-2358 > URL: https://issues.apache.org/jira/browse/FOP-2358 > Project: Fop > Issue Type: Bug >Affects Versions: 1.1 > Environment: $ fop -v > FOP Version 1.1 > $ java -version > java version "1.7.0_51" > Java(TM) SE Runtime Environment (build 1.7.0_51-b13) > Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode) >Reporter: Mark Craig >Priority: Minor > Attachments: render-shy.fo, render-shy.pdf > > > Soft hyphen is rendered as hyphen + space. > As a result, when the text that originally contained a soft hyphen is copied > and pasted to an editor capable of ignoring soft hyphens or recalculating the > hyphenation, the "hard" hyphen remains. > This is particularly unhelpful in hyphenated literals such as URLs or OIDs, > where adding a hyphen + space means that the copy is broken. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FOP-1099) [PATCH] footnotes within tables and lists get lost
[ https://issues.apache.org/jira/browse/FOP-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert updated FOP-1099: --- Attachment: footnote_repeated-table-heading.patch I had another go at this problem and came up with the attached patch. It leverages the patch from Matthias and adds support for repeated table headers/footers. For the first header/last footer, footnotes are treated the usual way. That means that if the table is not broken over pages then footnotes coming from its header/footer will be handled just like any other footnote. For repeated headers/footers, I added a mechanism that registers footnotes separately and inserts them at the right place at area creation time. That is, footnotes from repeated headers first, then other footnotes, then footnotes from repeated footers. The size of the footnote is accounted for in the penalty that represents the header/footer. As a consequence, the footnote will always be on the same page as the header/footer and will never be deferred to later pages. The regular footnote-handling mechanism is essentially by-passed here. This works well except in the case of nested tables, when the outer table has a repeated table-footer. Gaps will be visible between that footer and the inner table, and the outer footer may even be mixed with the footnotes. I guess we’ll have to leave with this limitation. Footnotes in repeated table headers/footers already is a degenerate case IMO, so I would say footnotes in repeated headers/footers in nested tables is pushing too far... If people could try out this patch and give feedback, that would be great. I’ll leave a few days for peer review and then, if nobody has objected, I'll commit it to trunk. > [PATCH] footnotes within tables and lists get lost > -- > > Key: FOP-1099 > URL: https://issues.apache.org/jira/browse/FOP-1099 > Project: Fop > Issue Type: Bug > Components: layout/unqualified >Affects Versions: trunk > Environment: Operating System: other > Platform: Other >Reporter: gerhard oettl > Attachments: 1044-tab-header-footnote-no-repeat.patch, > 1044-tab-header-footnote-no-repeat.xml, b37579.diff, b37579.diff, > b37579_2.patch, bugzilla37579.patch, dorfchronik.fo, dorfchronik.fo.list3, > dorfchronik.fo.table3, duplicated-footnote.fo, duplicated-footnote.pdf, > footnote-end-page-sequence.fo, footnote-end-page-sequence.pdf, > footnote-missing_page2.fo, footnote-missing_page2.pdf, footnote.fo, > footnote_repeated-table-heading.patch, footnoteintable.patch, > footnotes.080502.diff, footnotespatch, fussnote.fo, inverted-footnotes.fo, > inverted-footnotes.pdf, table_list_footnotes.diff, vtest.fo > > > Footnote outside of tables works, inside table-cell not. > The compliance page only speaks about restrictions within multicolumn > documents. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FOP-2385) [PATCH] Add ability to specify custom properties in the Document Information Dictionary
[
https://issues.apache.org/jira/browse/FOP-2385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Hennebert updated FOP-2385:
---
Attachment: pdf-custom-properties.patch
> [PATCH] Add ability to specify custom properties in the Document Information
> Dictionary
> ---
>
> Key: FOP-2385
> URL: https://issues.apache.org/jira/browse/FOP-2385
> Project: Fop
> Issue Type: Improvement
> Components: renderer/pdf
>Reporter: Vincent Hennebert
>Assignee: Vincent Hennebert
> Labels: patch
> Attachments: pdf-custom-properties.patch
>
>
> It is possible to add custom key/value pairs in the Info dictionary of a PDF
> document. Those custom properties will appear in the ‘Custom’ tab of Adobe
> Reader’s ‘Document Properties’ window (not sure about other viewers though).
> This patch adds the possibility to do that. A pdf:info element can be added
> as a child of fo:declarations and contain the custom properties. For example:
> {code:xml}
>
> http://xmlgraphics.apache.org/fop/extensions/pdf";>
> MyValue
> MyOtherValue
>
>
> {code}
> Since it’s small, I thought that would be overkill to create a branch just
> for that. So I’m putting it here for peer review.
> If nobody objects by 2014/06/12, I’m going to commit this patch to trunk.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (FOP-2385) [PATCH] Add ability to specify custom properties in the Document Information Dictionary
Vincent Hennebert created FOP-2385:
--
Summary: [PATCH] Add ability to specify custom properties in the
Document Information Dictionary
Key: FOP-2385
URL: https://issues.apache.org/jira/browse/FOP-2385
Project: Fop
Issue Type: Improvement
Components: renderer/pdf
Reporter: Vincent Hennebert
Assignee: Vincent Hennebert
It is possible to add custom key/value pairs in the Info dictionary of a PDF
document. Those custom properties will appear in the ‘Custom’ tab of Adobe
Reader’s ‘Document Properties’ window (not sure about other viewers though).
This patch adds the possibility to do that. A pdf:info element can be added as
a child of fo:declarations and contain the custom properties. For example:
{code:xml}
http://xmlgraphics.apache.org/fop/extensions/pdf";>
MyValue
MyOtherValue
{code}
Since it’s small, I thought that would be overkill to create a branch just for
that. So I’m putting it here for peer review.
If nobody objects by 2014/06/12, I’m going to commit this patch to trunk.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (FOP-1099) [PATCH] footnotes within tables and lists get lost
[ https://issues.apache.org/jira/browse/FOP-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert updated FOP-1099: --- Attachment: inverted-footnotes.pdf inverted-footnotes.fo footnote-missing_page2.pdf footnote-missing_page2.fo footnote-end-page-sequence.pdf footnote-end-page-sequence.fo duplicated-footnote.pdf duplicated-footnote.fo Hi Matthias, Thanks for your patch! I've applied it in [rev. 1599344|http://svn.apache.org/r1599344]. I've made some modifications, essentially clean-up and javadoc, plus I added a test case and fixed one mistake: the KnuthBlockBox to add to the list when the header is repeated at page breaks should be of height 0, since the header height is already taken into account in headerAsSecondToLast. I didn't apply Simon's patch as it has several faults. See attached files. For example the footnote from the header will be added after any footnote from the body (inverted-footnotes.fo). Or the footnote will be found at the very end of the page sequence instead of being on the same page as the table. Those test cases are relatively simple, so I don't think we can proceed in this state. Basically the code that deals with footnotes in repeated table headers/footers doesn't integrate in the general footnote code, which can only cause issues. The fact that repeated headers/footers are handled by using a penalty whose height corresponds to the additional heights of the header and footer will inevitably be a problem for obtaining the correct order of footnotes between the table header and the rest of the document. So more work is needed, and the fact that the footnote code is extremely complex will make it... interesting :-) Vincent > [PATCH] footnotes within tables and lists get lost > -- > > Key: FOP-1099 > URL: https://issues.apache.org/jira/browse/FOP-1099 > Project: Fop > Issue Type: Bug > Components: layout/unqualified >Affects Versions: trunk > Environment: Operating System: other > Platform: Other >Reporter: gerhard oettl > Attachments: 1044-tab-header-footnote-no-repeat.patch, > 1044-tab-header-footnote-no-repeat.xml, b37579.diff, b37579.diff, > b37579_2.patch, bugzilla37579.patch, dorfchronik.fo, dorfchronik.fo.list3, > dorfchronik.fo.table3, duplicated-footnote.fo, duplicated-footnote.pdf, > footnote-end-page-sequence.fo, footnote-end-page-sequence.pdf, > footnote-missing_page2.fo, footnote-missing_page2.pdf, footnote.fo, > footnoteintable.patch, footnotes.080502.diff, footnotespatch, fussnote.fo, > inverted-footnotes.fo, inverted-footnotes.pdf, table_list_footnotes.diff, > vtest.fo > > > Footnote outside of tables works, inside table-cell not. > The compliance page only speaks about restrictions within multicolumn > documents. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (FOP-2354) [PATCH] Subset support for Type 1 fonts
[ https://issues.apache.org/jira/browse/FOP-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13998873#comment-13998873 ] Vincent Hennebert commented on FOP-2354: bq. Why did you change the default not to subset? This isn't consistent with True Type fonts which are subset by default. The difference is that TrueType subsetting has always been available for as far as I can remember. Subsetting Type 1 fonts by default will have an impact on performance that users might no expect, and not be happy with. I'd leave Type 1 subsetting disabled for now and flag it as experimental. Once we have gathered enough experience with it and are confident that it's stable and efficient, we can always switch it on. > [PATCH] Subset support for Type 1 fonts > --- > > Key: FOP-2354 > URL: https://issues.apache.org/jira/browse/FOP-2354 > Project: Fop > Issue Type: New Feature > Components: fonts >Affects Versions: trunk >Reporter: Robert Meyer >Assignee: Robert Meyer > Fix For: trunk > > Attachments: c0419bt_.pfb, fop.xconf, patch.diff, patch.diff, test.fo > > > This patch adds subsetting support to Type 1 fonts. Currently the only two > supported output formats for this are PDF and Postscript. -- This message was sent by Atlassian JIRA (v6.2#6252)
[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=13974407#comment-13974407 ] Vincent Hennebert commented on FOP-2293: Hi Seifeddine, Thanks for your patch. I've applied it in rev. [1588548|http://svn.apache.org/r1588548]. The test cases look really good, simple and to the point. I think that apart from small details (the value of the auto-toggle property, among others), this work is ready to be merged to trunk. Is there anything you would like to add or shall I launch the vote? Ideally the documentation would be made a bit more detailed, with a slightly more complex example and illustrations of the cases where no variant is selected, or another than the first one, etc. But I don't see this as a blocker for the vote. Thanks, Vincent > 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_rev10.patch, > FO_multi-switch_best-fit_ext_rev11.patch, > FO_multi-switch_best-fit_ext_rev12.patch, > FO_multi-switch_best-fit_ext_rev13.patch, > FO_multi-switch_best-fit_ext_rev2.patch, > FO_multi-switch_best-fit_ext_rev3.patch, > FO_multi-switch_best-fit_ext_rev4.patch, > FO_multi-switch_best-fit_ext_rev5.patch, > FO_multi-switch_best-fit_ext_rev6.patch, > FO_multi-switch_best-fit_ext_rev7.patch, > FO_multi-switch_best-fit_ext_rev8.patch, > FO_multi-switch_best-fit_ext_rev9.patch, FO_multi-switch_test.fo, > FO_multi-switch_with_best-fit_extension.patch, bestfit.fo, > bug_page_ipd_change.fo, doc.pdf, empty-last-page.fo, > multi-switch-testcases.zip, multi-switch_bestfit.fo, > multiple-feasible-nodes.fo, patch-rev1.1.patch, patch-rev1.patch, > patch-rev2.patch, patch.patch, rev11_bug.fo, two-valid-variants.fo > > > 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.2#6252)
[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=13964590#comment-13964590 ] Vincent Hennebert commented on FOP-2293: Hmmm. I suspect it works because then the algorithm breaks at the 'normal' penalty that follows the WhitespaceManagementPenalty, and it knows how to restart at such a penalty. Given the way the implementation has evolved (storing on the active node the selected variant), I guess it will always be possible to break at this penalty that follows the WMPenalty. In fact, you could probably turn the WMPenalty into an infinite penalty and always break at the penalty that would follow it. It might make easier to implement keeps and breaks (which BTW don't work properly on the example you uploaded since it shouldn't break at the WMPenalty). And if not, at least you have a cheap way to support changing IPD. Note that in order to have changing IPD properly working, you also need to make the MultiSwitchLM restartable and implement the 5-parameter getNextKnuthElements method. If having this extension work with changing IPD is not a priority for you, I suggest you leave the code as is. HTH, Vincent > 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_rev10.patch, > FO_multi-switch_best-fit_ext_rev11.patch, > FO_multi-switch_best-fit_ext_rev12.patch, > FO_multi-switch_best-fit_ext_rev2.patch, > FO_multi-switch_best-fit_ext_rev3.patch, > FO_multi-switch_best-fit_ext_rev4.patch, > FO_multi-switch_best-fit_ext_rev5.patch, > FO_multi-switch_best-fit_ext_rev6.patch, > FO_multi-switch_best-fit_ext_rev7.patch, > FO_multi-switch_best-fit_ext_rev8.patch, > FO_multi-switch_best-fit_ext_rev9.patch, FO_multi-switch_test.fo, > FO_multi-switch_with_best-fit_extension.patch, bestfit.fo, > bug_page_ipd_change.fo, doc.pdf, empty-last-page.fo, > multi-switch-testcases.zip, multi-switch_bestfit.fo, > multiple-feasible-nodes.fo, patch-rev1.1.patch, patch-rev1.patch, > patch-rev2.patch, patch.patch, rev11_bug.fo, two-valid-variants.fo > > > 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.2#6252)
[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=13963351#comment-13963351 ] Vincent Hennebert commented on FOP-2293: Hi Seifeddine, I’ve just [applied|http://svn.apache.org/r1585822] your rev12 patch. Thanks! I made the following modifications: * Test case: I removed the third page-sequence as I wasn’t sure of the interest of it. The first variant will always be selected and the second never since there is no room left on the page. Instead I changed the line-height of the MS 3 on the previous page-sequence to 50pt, to show that the space taken up by previous multi-switch is taken into account. * MultiSwitchLM: I renamed DynamicContentPosition into WhitespaceManagementPosition for consistency. * Plus other minor improvements. In PageBreakingAlgorithm.updateData2: it would be good to avoid iterating through the list of elements to find out the index of the penalty and compare it against the pageNode’s position. The index should probably be stored along with the variant. I made a mistake in my previous comment I’m afraid. Only one multi-case child of an fo:multi-switch element may be visible at a time. So the default behaviour of MultiSwitchLM should be to return the elements of its first child. It shouldn’t be too hard to modify your default generator to do that? Maybe it would be good to add slightly more complex tests with keeps and breaks, border and padding, etc. And also test the standard behaviour of multi-switch. bq. I guess everything is working fine now, but I have a concern regarding the case where the algorithm restarts at a MSLM position. If that happens, I think an exception will be thrown. Do you think that we should add a BreakElement at the end of the Knuth list? What do you mean by this? When it restarts at a too short/long node because no feasible break has been found, or when it restarts the whole page layout because changing IPD has been detected? Vincent > 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_rev10.patch, > FO_multi-switch_best-fit_ext_rev11.patch, > FO_multi-switch_best-fit_ext_rev12.patch, > FO_multi-switch_best-fit_ext_rev2.patch, > FO_multi-switch_best-fit_ext_rev3.patch, > FO_multi-switch_best-fit_ext_rev4.patch, > FO_multi-switch_best-fit_ext_rev5.patch, > FO_multi-switch_best-fit_ext_rev6.patch, > FO_multi-switch_best-fit_ext_rev7.patch, > FO_multi-switch_best-fit_ext_rev8.patch, > FO_multi-switch_best-fit_ext_rev9.patch, FO_multi-switch_test.fo, > FO_multi-switch_with_best-fit_extension.patch, bestfit.fo, doc.pdf, > empty-last-page.fo, multi-switch-testcases.zip, multi-switch_bestfit.fo, > multiple-feasible-nodes.fo, patch-rev1.1.patch, patch-rev1.patch, > patch-rev2.patch, patch.patch, rev11_bug.fo, two-valid-variants.fo > > > 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.2#6252)
[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=13960325#comment-13960325 ] Vincent Hennebert commented on FOP-2293: bq. I think I have to filter out variants when updateData2() is called in such a way that a penalty can only be activated if its position is less than the current node position. Indeed, something like this might work. bq. Regarding the name of the extension, I agree with you that the name "best-fit" is a bit misleading and does not accurately describe what the extension is doing. I suggest "first-fit" or "first-fit-within-active-page". Are you talking about the value for auto-toggle here? "first-fit" makes sense but again, it might too easily be mistaken for one of the various layout methods (first fit, best fit, total fit). Maybe just "first-fitting"? bq. About the name of the penalty, what about MultiSwitchPenalty? The BFP is supposed to be only used by MSLM anyway... But a standard implementation of multi-switch wouldn't use such a penalty. Maybe rather WhitespaceManagementPenalty or something like that. bq. Yes. If auto-toggle was not set, all FO multi-case will be rendered. In such a case, maybe it would be better to fire an exception and tell the user that FO multi-switch is not yet supported? How easy would that be to simply show all of the multi-case children? It this is doable in a reasonable amount of time it should be done this way. What bothers me a bit right now is that the auto-toggle property is not used at all, so we have the extension behaviour by default. It would be better to trigger it only when auto-toggle is present. > 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_rev10.patch, > FO_multi-switch_best-fit_ext_rev11.patch, > FO_multi-switch_best-fit_ext_rev2.patch, > FO_multi-switch_best-fit_ext_rev3.patch, > FO_multi-switch_best-fit_ext_rev4.patch, > FO_multi-switch_best-fit_ext_rev5.patch, > FO_multi-switch_best-fit_ext_rev6.patch, > FO_multi-switch_best-fit_ext_rev7.patch, > FO_multi-switch_best-fit_ext_rev8.patch, > FO_multi-switch_best-fit_ext_rev9.patch, FO_multi-switch_test.fo, > FO_multi-switch_with_best-fit_extension.patch, bestfit.fo, doc.pdf, > empty-last-page.fo, multi-switch-testcases.zip, multi-switch_bestfit.fo, > multiple-feasible-nodes.fo, patch-rev1.1.patch, patch-rev1.patch, > patch-rev2.patch, patch.patch, rev11_bug.fo, two-valid-variants.fo > > > 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.2#6252)
[jira] [Resolved] (FOP-2363) Better error message when PDF/A enabled and SVG contains bitmap with transparency
[ https://issues.apache.org/jira/browse/FOP-2363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert resolved FOP-2363. Resolution: Fixed Fixed in rev. [1584765| http://svn.apache.org/r1584765]. > Better error message when PDF/A enabled and SVG contains bitmap with > transparency > - > > Key: FOP-2363 > URL: https://issues.apache.org/jira/browse/FOP-2363 > Project: Fop > Issue Type: Improvement > Components: pdf >Reporter: Vincent Hennebert > > At the moment, when PDF/A is enabled and an SVG image that contains a bitmap > with transparency is being rendered, an error occurs due to transparency. But > the error message may mislead the user into thinking that the transparency is > used by SVG operators rather than in a bitmap image referred to by it. It > would be better to be more explicit. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (FOP-2363) Better error message when PDF/A enabled and SVG contains bitmap with transparency
Vincent Hennebert created FOP-2363: -- Summary: Better error message when PDF/A enabled and SVG contains bitmap with transparency Key: FOP-2363 URL: https://issues.apache.org/jira/browse/FOP-2363 Project: Fop Issue Type: Improvement Components: pdf Reporter: Vincent Hennebert At the moment, when PDF/A is enabled and an SVG image that contains a bitmap with transparency is being rendered, an error occurs due to transparency. But the error message may mislead the user into thinking that the transparency is used by SVG operators rather than in a bitmap image referred to by it. It would be better to be more explicit. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FOP-2293) Whitespace management extension
[ https://issues.apache.org/jira/browse/FOP-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert updated FOP-2293: --- Attachment: rev11_bug.fo Hi Seifeddine, your modifications introduce a regression it seems. See attached rev11_bug.fo file. The second variant is shown on page 2 while it should be the first variant. I think you can't directly add variants to pendingVariants and that you have to keep the bestVariant mechanism. This should ideally have been caught by the layout tests. That shows that maybe more test cases are necessary. Among other things, a test case with several multi-switch elements would be great. Also, before merging to trunk it would be good to do some more clean-up: * The name BestFitPenalty is making little sense now. Also, that term has a very specific meaning in the context of page layout (first fit vs best fit vs total fit), so using it may actually be misleading about what we're trying to achieve. Something hinting at whitespace management would be better. * Likewise, the value "best-fit" for the auto-toggle option could have a better name. Although it seems that this option is not looked up at all in the code? Does MultiSwitchLM implement it by default? This makes it probably not compliant with the Recommendation. Remember that, even if partially implemented, the default behaviour of those dynamic elements must be compliant. * It seems that the fitting-strategy option is a left-over from the first implementations and is no longer used. * Possibly other things, that a diff between the branch and the trunk would reveal. It would be great if you could fix those issues before we merge this work to trunk. Thanks, Vincent > 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_rev10.patch, > FO_multi-switch_best-fit_ext_rev11.patch, > FO_multi-switch_best-fit_ext_rev2.patch, > FO_multi-switch_best-fit_ext_rev3.patch, > FO_multi-switch_best-fit_ext_rev4.patch, > FO_multi-switch_best-fit_ext_rev5.patch, > FO_multi-switch_best-fit_ext_rev6.patch, > FO_multi-switch_best-fit_ext_rev7.patch, > FO_multi-switch_best-fit_ext_rev8.patch, > FO_multi-switch_best-fit_ext_rev9.patch, FO_multi-switch_test.fo, > FO_multi-switch_with_best-fit_extension.patch, bestfit.fo, doc.pdf, > empty-last-page.fo, multi-switch-testcases.zip, multi-switch_bestfit.fo, > multiple-feasible-nodes.fo, patch-rev1.1.patch, patch-rev1.patch, > patch-rev2.patch, patch.patch, rev11_bug.fo, two-valid-variants.fo > > > 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.2#6252)
[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=13955050#comment-13955050
]
Vincent Hennebert commented on FOP-2293:
Hi Seifeddine,
at first I was doubtful that your approach would work, but after a more
in-depth study I think it should do the job. It’s actually quite clever and
we’re at the edge of what we can do with the Knuth algorithm; hopefully it
won’t cause conflicts with other features but as of now I can’t see any. Well
done anyway!
A few comments:
* In BestFitPenalty: this penaltyIndex field should ideally be removed as it
introduces unwelcome mutability. IIC all you need is a reference to the
BestFitPenalty instance? In which case you can probably just turn Variant into
an instance class (remove the static keyword) and add some getPenalty method
that return BestFitPenalty.this
* In PageBreakingAlgorithm:
* Isn’t the javadoc for pendingVariant misleading: is it all descendant nodes
or just the next one?
* BestPageRecords: there’s no need to override reset AFAIU?
* computeDifference: you should also add the size of the pending variant if
{{element}} is a glue (although I don’t believe it ever happens in page
breaking that we are breaking at a glue since they are always preceded by
penalties —but better safe than sorry).
It remains to make it work when there are several multi-switch on the same
page. IIC it doesn’t work at the moment. Maybe you can take advantage of the
fact that the first variant will be the one that will be selected by default.
So only when we break at a BestFitPenalty do you need to know what variant has
been selected if any. Then, on active nodes, instead of storing the pending
variant, you can just add the widths of the variants that are on the page.
Thanks for your patch!
Vincent
> 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_rev10.patch,
> FO_multi-switch_best-fit_ext_rev2.patch,
> FO_multi-switch_best-fit_ext_rev3.patch,
> FO_multi-switch_best-fit_ext_rev4.patch,
> FO_multi-switch_best-fit_ext_rev5.patch,
> FO_multi-switch_best-fit_ext_rev6.patch,
> FO_multi-switch_best-fit_ext_rev7.patch,
> FO_multi-switch_best-fit_ext_rev8.patch,
> FO_multi-switch_best-fit_ext_rev9.patch, FO_multi-switch_test.fo,
> FO_multi-switch_with_best-fit_extension.patch, bestfit.fo, doc.pdf,
> empty-last-page.fo, multi-switch-testcases.zip, multi-switch_bestfit.fo,
> multiple-feasible-nodes.fo, patch-rev1.1.patch, patch-rev1.patch,
> patch-rev2.patch, patch.patch, two-valid-variants.fo
>
>
> 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.2#6252)
[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=13940945#comment-13940945 ] Vincent Hennebert commented on FOP-2293: Hi Seifeddine, your patch breaks the tests I'm afraid. In PageBreakingAlgorithm.handlePenaltyAt, I'm not sure why you are adding the glue there. You are back to the old problem where different layouts will select different variants which will override each other. This is actually what seems to happen if you run it on the empty-last-page.fo file I attached to my previous comment (which, BTW, still finishes on an empty page...). Also, modifying the paragraph in the same time as the breaking algorithm is run is calling for trouble. The algorithm backtracks when it can't find a suitable set of page breaks (because of overfull or underfull pages), so you may end up adding the same element several times to the Knuth sequence. In handleBestFitPenalty, doing the space resolution there is a nice try but it still doesn't work. For example it won't merge the space after the element that precedes the multi-switch and the space before the first child of a multi-case. You will end up with too much white space. I think you are better off leaving space resolution as it is currently done... Vincent > 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_best-fit_ext_rev4.patch, > FO_multi-switch_best-fit_ext_rev5.patch, > FO_multi-switch_best-fit_ext_rev6.patch, > FO_multi-switch_best-fit_ext_rev7.patch, > FO_multi-switch_best-fit_ext_rev8.patch, > FO_multi-switch_best-fit_ext_rev9.patch, FO_multi-switch_test.fo, > FO_multi-switch_with_best-fit_extension.patch, bestfit.fo, doc.pdf, > empty-last-page.fo, multi-switch-testcases.zip, multi-switch_bestfit.fo, > multiple-feasible-nodes.fo, patch-rev1.1.patch, patch-rev1.patch, > patch-rev2.patch, patch.patch, two-valid-variants.fo > > > 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.2#6252)
[jira] [Updated] (FOP-2293) Whitespace management extension
[ https://issues.apache.org/jira/browse/FOP-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert updated FOP-2293: --- Attachment: empty-last-page.fo bq. All I'm saying is that I prefer not to see any empty space in my document which may force FOP to make an extra page for nothing, because this is what actually happens if a dynamic content didn't fit in a page. Do you have a test case that illustrates this behaviour? I found one but this doesn't happen because of the glue. See attached file: the first variant is bigger than the second one, and doesn't fit on the page. So the second variant is selected as a feasible break and the algorithm carries on as usual. Except that there is nothing to display on the next page. There is just the zero-width box that is there exactly because otherwise dynamic content would be ignored altogether when it's last on the page sequence. This is a tricky case. I don't really see any way of getting out of this without forcing the Knuth algorithm into following a path it's not designed for. The best solution probably is to introduce some constraints on the dynamic content: make sure that the first variant is always the smallest, and change the PageBreakingAlgorithm.handleBestFitPenalty method as I suggested in my previous comment to select the variant that leads to an adjustment ratio closest to 0. That way, there will be a feasible layout without an empty last page. The layout with a page break at the multi-switch and an empty page will still exist, but the version that doesn't break at the multi-switch, uses the glue instead and carries on to the end of the content will be preferred since it will use less pages. This can be illustrated by inverting the two variants in the attached file. The enforcement can be informal. That is, document it and warn the user that unexpected things may happen if the recommendation is not followed. Or it can be programmed: throw an error, or issue a warning and add an empty variant at the beginning of the list, etc. bq. I have a tricky problem regarding the treatment of space elements inside a dynamic content. Since each variant's Knuth list is stored separately inside the best-fit penalty, there is no way for the space resolver to have any information about surrounding elements and each variant is resolved independently. I don't think there is an easy way of solving this. The space resolver works on a whole sequence of Knuth elements and does all the resolution in one go. What you need is partial resolution: on the elements that precede the multi-switch, on the elements inside the multi-switch, on the elements after the multi-switch. Then you would finish the resolution in the breaking algorithm, once you know which variant is selected. This is the same problem as for footnotes, which I'm mentioning in my comment from 2013/11/20. Refactoring space resolution to achieve this is IMO not trivial, and should be left as is. If a space is needed at the beginning of a variant, this can be achieved by setting space-before.conditionality to 'retain' (in theory: I had an error when I tried it, which should be fixed). HTH Vincent > 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_best-fit_ext_rev4.patch, > FO_multi-switch_best-fit_ext_rev5.patch, > FO_multi-switch_best-fit_ext_rev6.patch, > FO_multi-switch_best-fit_ext_rev7.patch, > FO_multi-switch_best-fit_ext_rev8.patch, FO_multi-switch_test.fo, > FO_multi-switch_with_best-fit_extension.patch, bestfit.fo, doc.pdf, > empty-last-page.fo, multi-switch-testcases.zip, multi-switch_bestfit.fo, > multiple-feasible-nodes.fo, patch-rev1.1.patch, patch-rev1.patch, > patch-rev2.patch, patch.patch, two-valid-variants.fo > > > 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
[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=13938998#comment-13938998 ] Vincent Hennebert commented on FOP-2293: Well then you don't need a glue at all, but this is not my understanding of the requirements, and it seems to be in contradiction with your comment from the 24/02. Unless you consider the case 'beginning of the page' to be different to 'middle of the page'? By 'middle of the page' I mean 'not at the bottom of a page', which encompasses the 'top of the page' case. I admit the wording can be misleading. At any rate, if you don't want dynamic content to appear alone at the top of a page, you can always set keep-with-next.within-page to 'always' on the block before. It's probably going to be preferable anyway, in order to avoid unexpected behaviour. Indeed, the appearance of dynamic content at the top of the next page will depend on which break is selected on the previous page. It can be the break _before_ the multi-switch, in which case dynamic content will appear on the next page; or it can be the break _at_ the multi-switch that resolves to zero, in which case dynamic content will _not_ appear. Which break will be chosen depends on what follows on the document, but in both cases the content up to that page will look exactly the same. So, you can have one layout where the break before is selected and dynamic content appears; then you can add a single line at the end of the document such that the break selection changes to the break at the multi-switch, and all of a sudden the dynamic content disappears. Thinking about this brought another use case in my mind: you may want the first variant to be empty, such that dynamic content appears _only_ at the bottom of a page when there is some space, and never in the middle of it. At the moment this is not going to work since the variant that is selected is the first that fits. So it will always return the empty content. So you may want to change the PageBreakingAlgorithm.handleBestFitPenalty method to return the variant that makes the adjustment ratio closest to 0. Vincent > 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_best-fit_ext_rev4.patch, > FO_multi-switch_best-fit_ext_rev5.patch, > FO_multi-switch_best-fit_ext_rev6.patch, > FO_multi-switch_best-fit_ext_rev7.patch, > FO_multi-switch_best-fit_ext_rev8.patch, FO_multi-switch_test.fo, > FO_multi-switch_with_best-fit_extension.patch, bestfit.fo, doc.pdf, > multi-switch-testcases.zip, multi-switch_bestfit.fo, > multiple-feasible-nodes.fo, patch-rev1.1.patch, patch-rev1.patch, > patch-rev2.patch, patch.patch, two-valid-variants.fo > > > 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.2#6252)
[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=13937875#comment-13937875 ] Vincent Hennebert commented on FOP-2293: Hi Seifeddine, bq. Imagine for example, that a BFP was rejected, we would be adding the width of the glue to totalWidth while we shouldn't. And that creates an empty block in the final document. Hmm, no? The width of the penalty is taken into account only if the penalty is chosen as a break point. If it is, then the glue that follows it will be discarded so its width won't be added to totalWidth. On the other hand, if the penalty is not selected (because none of its variant would fit on the page), then the glue will correctly be taken into account on the following page. So, the dynamic content will appear at the beginning of the next page. This is illustrated in the 3rd page-sequence in the multi-switch_best-fit_multiple-variants.xml test case that was added to the patch. This is actually the same process as when the dynamic content is put in the middle of the page. In that case, all of the variants produce underfull pages instead of overfull ones. Does that make sense? Vincent > 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_best-fit_ext_rev4.patch, > FO_multi-switch_best-fit_ext_rev5.patch, > FO_multi-switch_best-fit_ext_rev6.patch, > FO_multi-switch_best-fit_ext_rev7.patch, > FO_multi-switch_best-fit_ext_rev8.patch, FO_multi-switch_test.fo, > FO_multi-switch_with_best-fit_extension.patch, bestfit.fo, doc.pdf, > multi-switch-testcases.zip, multi-switch_bestfit.fo, > multiple-feasible-nodes.fo, patch-rev1.1.patch, patch-rev1.patch, > patch-rev2.patch, patch.patch, two-valid-variants.fo > > > 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.2#6252)
[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=13937571#comment-13937571 ] Vincent Hennebert commented on FOP-2293: Hi Seifeddine, thanks for your patch. I've applied it in [rev. 1578270|http://svn.apache.org/r1578270]. I made the following adjustments: * The BestFitGlue class, and the special implementation of handleGlueAt in PageBreakingLM are not necessary. I'm actually not too sure how it was supposed to work: the method was iterating over all the nodes for the previous page and making a decision based on the state of one of them, without being sure that it's the one that would have ultimately been selected. Anyway, the code works with a normal glue whose width matches the width of the first variant. Or did I miss your intent? * Not sure why you set the penalty value of a BestFitPenaly to -1? I left it to 0. * I left the KnuthVariant class inside BestFitPenalty and left its name unchanged. The reason is that the layoutmgr package is already overcrowded and BestFitPenalty provides a nice encapsulation. Also, it's not really related to the Knuth algorithm so having Knuth in its name didn't seem all that relevant to me. * I integrated the test cases you provided. I made some modifications to simplify them and make them more complete. This is taking really good shape now. Here's a check list of things to be done before merging back the branch to trunk: * Documentation, in the form of a patch against the web site. The best place probably is the Extensions page under the trunk tab. See the [CMS Reference|https://www.apache.org/dev/cmsref.html] to find out how to modify the website, and especially the [process|https://www.apache.org/dev/cmsref.html#non-committer] for non-committers. * Improve test coverage: I think the layout tests we already have are pretty good, but one cannot be sure until test coverage has been checked. You can use your IDE's coverage tool or run JaCoCo on the command line: ant -f jacoco.xml coverage-report. * Code clean-up (this patch was already a good start): ** The recommendation says that fo:multi-switch and fo:multi-case do not generate any areas. The corresponding LayoutManager classes should be modified to not create instances of Block, but instead directly return their kids' areas. I did notice indeed that a lot of nested blocks were appearing in the area trees created out of the layout tests. ** The BestFitLayoutUtils class should probably be removed and its content moved into MultiSwitchLM, as IIC it's used only by that latter. ** It's getting time to sort out the remaining TODOs. ** Run Checkstyle, and possibly FindBugs. ** Finally, check the diff against trunk, which will allow you to easily spot spurious changes that can be cleaned up. Thanks for your efforts! Vincent > 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_best-fit_ext_rev4.patch, > FO_multi-switch_best-fit_ext_rev5.patch, > FO_multi-switch_best-fit_ext_rev6.patch, > FO_multi-switch_best-fit_ext_rev7.patch, > FO_multi-switch_best-fit_ext_rev8.patch, FO_multi-switch_test.fo, > FO_multi-switch_with_best-fit_extension.patch, bestfit.fo, doc.pdf, > multi-switch-testcases.zip, multi-switch_bestfit.fo, > multiple-feasible-nodes.fo, patch-rev1.1.patch, patch-rev1.patch, > patch-rev2.patch, patch.patch, two-valid-variants.fo > > > 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.2#6252)
[jira] [Resolved] (FOP-2357) When an SVG image has transparency and a PDF profile is used that disallows it, transparency should be ignored rather than throwing an error
[ https://issues.apache.org/jira/browse/FOP-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert resolved FOP-2357. Resolution: Fixed Fixed in [rev. 1577477|http://svn.apache.org/r1577477]. > When an SVG image has transparency and a PDF profile is used that disallows > it, transparency should be ignored rather than throwing an error > > > Key: FOP-2357 > URL: https://issues.apache.org/jira/browse/FOP-2357 > Project: Fop > Issue Type: Improvement > Components: pdf >Reporter: Vincent Hennebert > Attachments: svg-transparency.fo > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FOP-2357) When an SVG image has transparency and a PDF profile is used that disallows it, transparency should be ignored rather than throwing an error
[ https://issues.apache.org/jira/browse/FOP-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert updated FOP-2357: --- Attachment: svg-transparency.fo When FOP is run on this svg-transparency.fo file and the '-pdfprofile PDF/A-1b' switch is being used, a PDFConformanceException is being thrown. It would be better to simply disable transparency and warn the user about it. > When an SVG image has transparency and a PDF profile is used that disallows > it, transparency should be ignored rather than throwing an error > > > Key: FOP-2357 > URL: https://issues.apache.org/jira/browse/FOP-2357 > Project: Fop > Issue Type: Improvement > Components: pdf >Reporter: Vincent Hennebert > Attachments: svg-transparency.fo > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (FOP-2357) When an SVG image has transparency and a PDF profile is used that disallows it, transparency should be ignored rather than throwing an error
Vincent Hennebert created FOP-2357: -- Summary: When an SVG image has transparency and a PDF profile is used that disallows it, transparency should be ignored rather than throwing an error Key: FOP-2357 URL: https://issues.apache.org/jira/browse/FOP-2357 Project: Fop Issue Type: Improvement Components: pdf Reporter: Vincent Hennebert -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FOP-2354) [PATCH] Subset support for Type 1 fonts
[ https://issues.apache.org/jira/browse/FOP-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert updated FOP-2354: --- Attachment: test.fo fop.xconf > [PATCH] Subset support for Type 1 fonts > --- > > Key: FOP-2354 > URL: https://issues.apache.org/jira/browse/FOP-2354 > Project: Fop > Issue Type: New Feature > Components: fonts >Affects Versions: trunk >Reporter: Robert Meyer >Assignee: Robert Meyer > Fix For: trunk > > Attachments: c0419bt_.pfb, fop.xconf, patch.diff, test.fo > > > This patch adds subsetting support to Type 1 fonts. Currently the only two > supported output formats for this are PDF and Postscript. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (FOP-2354) [PATCH] Subset support for Type 1 fonts
[
https://issues.apache.org/jira/browse/FOP-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13930252#comment-13930252
]
Vincent Hennebert commented on FOP-2354:
I have an ArrayIndexOutOfBoundsException when I use an accented character:
{noformat}
java.lang.ArrayIndexOutOfBoundsException: 225
at org.apache.fop.pdf.PDFFactory.makeFont(PDFFactory.java:1394)
at org.apache.fop.pdf.PDFResources.addFonts(PDFResources.java:121)
at
org.apache.fop.render.pdf.PDFDocumentHandler.endDocument(PDFDocumentHandler.java:181)
at
org.apache.fop.render.intermediate.util.IFDocumentHandlerProxy.endDocument(IFDocumentHandlerProxy.java:187)
at
org.apache.fop.render.intermediate.IFRenderer.stopRenderer(IFRenderer.java:294)
at
org.apache.fop.area.RenderPagesModel.endDocument(RenderPagesModel.java:265)
at
org.apache.fop.area.AreaTreeHandler.endDocument(AreaTreeHandler.java:342)
at org.apache.fop.fo.FOTreeBuilder.endDocument(FOTreeBuilder.java:169)
at
org.apache.xalan.transformer.TransformerIdentityImpl.endDocument(TransformerIdentityImpl.java:962)
at org.apache.xerces.parsers.AbstractSAXParser.endDocument(Unknown
Source)
at org.apache.xerces.xinclude.XIncludeHandler.endDocument(Unknown
Source)
at org.apache.xerces.impl.XMLDocumentScannerImpl.endEntity(Unknown
Source)
at org.apache.xerces.impl.XMLEntityManager.endEntity(Unknown Source)
at org.apache.xerces.impl.XMLEntityScanner.load(Unknown Source)
at org.apache.xerces.impl.XMLEntityScanner.skipSpaces(Unknown Source)
at
org.apache.xerces.impl.XMLDocumentScannerImpl$TrailingMiscDispatcher.dispatch(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown
Source)
at
org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:484)
at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:285)
at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:115)
at org.apache.fop.cli.Main.startFOP(Main.java:177)
at org.apache.fop.cli.Main.main(Main.java:208)
{noformat}
> [PATCH] Subset support for Type 1 fonts
> ---
>
> Key: FOP-2354
> URL: https://issues.apache.org/jira/browse/FOP-2354
> Project: Fop
> Issue Type: New Feature
> Components: fonts
>Affects Versions: trunk
>Reporter: Robert Meyer
>Assignee: Robert Meyer
> Fix For: trunk
>
> Attachments: c0419bt_.pfb, fop.xconf, patch.diff, test.fo
>
>
> This patch adds subsetting support to Type 1 fonts. Currently the only two
> supported output formats for this are PDF and Postscript.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (FOP-2346) UnsupportedOperationException when handling an SVG containing a font-face
[ https://issues.apache.org/jira/browse/FOP-2346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert resolved FOP-2346. Resolution: Fixed Partial fix committed in [rev. 1570362|http://svn.apache.org/r1570362]. It doesn't crash any more, but it still won't load the font pointed to by the URI. There is disparity between Batik's and FOP's URI resolution mechanisms, and trouble with FOP's various font classes. Something that I must defer for later. > UnsupportedOperationException when handling an SVG containing a font-face > - > > Key: FOP-2346 > URL: https://issues.apache.org/jira/browse/FOP-2346 > Project: Fop > Issue Type: Bug >Reporter: Vincent Hennebert > Attachments: font-face.fo > > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (FOP-2346) UnsupportedOperationException when handling an SVG containing a font-face
[ https://issues.apache.org/jira/browse/FOP-2346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert updated FOP-2346: --- Attachment: font-face.fo > UnsupportedOperationException when handling an SVG containing a font-face > - > > Key: FOP-2346 > URL: https://issues.apache.org/jira/browse/FOP-2346 > Project: Fop > Issue Type: Bug >Reporter: Vincent Hennebert > Attachments: font-face.fo > > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (FOP-2346) UnsupportedOperationException when handling an SVG containing a font-face
Vincent Hennebert created FOP-2346: -- Summary: UnsupportedOperationException when handling an SVG containing a font-face Key: FOP-2346 URL: https://issues.apache.org/jira/browse/FOP-2346 Project: Fop Issue Type: Bug Reporter: Vincent Hennebert -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (FOP-1614) SVG graphics cannot use FOP custom fonts
[ https://issues.apache.org/jira/browse/FOP-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert resolved FOP-1614. Resolution: Fixed Fixed in [rev. 1564017|http://svn.apache.org/r1564017]. > SVG graphics cannot use FOP custom fonts > > > Key: FOP-1614 > URL: https://issues.apache.org/jira/browse/FOP-1614 > Project: Fop > Issue Type: Bug > Components: svg >Affects Versions: 0.95 > Environment: Operating System: Windows 2000 > Platform: PC >Reporter: M.H. > > I configured FOP to use custom fonts with their TTF files being in a custom > directory - and not C:\WINNT\Fonts (reason: license restrictions only allows > usage of some fonts in the FOP application and not in any other Windows > applications, like e.g. Word). This works flawlessly for FOP texts. > However, SVGs are also included (referenced/linked) in the XSLs. And for > texts in these SVGs, the fonts are only used/found if they are stored in > C:\WINNT\Fonts! It seems that FOP doesn't tell its SVG engine (Batik) where > to find the fonts, as FOP itself knows it from its configuration XML. Is > Batik using the font configuartion of FOP at all or is there some additional > configuration possible to tell FOP to set its font configuration also for > Batik? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (FOP-1614) SVG graphics cannot use FOP custom fonts
[ https://issues.apache.org/jira/browse/FOP-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert updated FOP-1614: --- Summary: SVG graphics cannot use FOP custom fonts (was: Fonts not found for SVG texts (when not in C:\WINNT\Fonts)) > SVG graphics cannot use FOP custom fonts > > > Key: FOP-1614 > URL: https://issues.apache.org/jira/browse/FOP-1614 > Project: Fop > Issue Type: Bug > Components: svg >Affects Versions: 0.95 > Environment: Operating System: Windows 2000 > Platform: PC >Reporter: M.H. > > I configured FOP to use custom fonts with their TTF files being in a custom > directory - and not C:\WINNT\Fonts (reason: license restrictions only allows > usage of some fonts in the FOP application and not in any other Windows > applications, like e.g. Word). This works flawlessly for FOP texts. > However, SVGs are also included (referenced/linked) in the XSLs. And for > texts in these SVGs, the fonts are only used/found if they are stored in > C:\WINNT\Fonts! It seems that FOP doesn't tell its SVG engine (Batik) where > to find the fonts, as FOP itself knows it from its configuration XML. Is > Batik using the font configuartion of FOP at all or is there some additional > configuration possible to tell FOP to set its font configuration also for > Batik? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (FOP-1524) [PATCH] fo:inline-container implementation
[ https://issues.apache.org/jira/browse/FOP-1524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert resolved FOP-1524. Resolution: Fixed A partial implementation has been committed in [rev. 1562429|http://svn.apache.org/r1562429]. The main properties that have been left unimplemented are: * borders and padding * keeps * reference-orientation * writing-mode Closing this issue, more specialized issues can be opened as necessary. > [PATCH] fo:inline-container implementation > -- > > Key: FOP-1524 > URL: https://issues.apache.org/jira/browse/FOP-1524 > Project: Fop > Issue Type: Improvement > Components: general >Affects Versions: trunk > Environment: Operating System: All > Platform: All >Reporter: Andreas L. Delmelle > Attachments: inline-container-prepatch.patch, > inline-container-prepatch.patch, inline-container.diff, > test_inline-container_basic.fo, test_inline-container_basic.fo, > test_inline-container_basic.fo, test_inline-container_basic.pdf, > test_inline-container_basic.pdf, test_inline-container_basic.pdf > > > This Bugzilla entry will be used for the moment to keep track of the progress > of an implementation for fo:inline-container. The related changes are > restricted to a handful of classes, so branching seemed like overkill. No > commits to the trunk yet, since I see some possible overlap with Simon's > branch. > Anyway, status so far. The rough patch in attachment models the > InlineContainerLayoutManager along the lines of BlockContainerLayoutManager. > It already aligns the content better than my last attempt (way back when). > Still some things remaining to check out, but the basics are there... -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (FOP-2328) Please delete old releases from mirroring system
[ https://issues.apache.org/jira/browse/FOP-2328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert resolved FOP-2328. Resolution: Fixed Done. > Please delete old releases from mirroring system > > > Key: FOP-2328 > URL: https://issues.apache.org/jira/browse/FOP-2328 > Project: Fop > Issue Type: Bug >Affects Versions: 1.0 > Environment: > https://dist.apache.org/repos/dist/release/xmlgraphics/fop/binaries/ > https://dist.apache.org/repos/dist/release/xmlgraphics/fop/source/ >Reporter: Sebb > > To reduce the load on the ASF mirrors, projects are required to delete old > releases [1] > Please can you remove all non-current releases? > Thanks! > [Note that older releases are always available from the ASF archive server] > [1] http://www.apache.org/dev/release.html#when-to-archive -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[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=13848039#comment-13848039
]
Vincent Hennebert commented on FOP-2293:
Hi Seifeddine,
I've just applied your patch. Among other things, I made the following
modifications:
* In PageBreakingAlgorithm, I reset the {{variant}} field in the
{{considerLegalBreak}} method, so that it doesn't propagate to the subsequent
active nodes.
* In BestFitPenalty, I removed the {{getBesFitPosition}} method and instead
store the position in a field so that it can be accessed directly. That'll do
for now but maybe the whole thing can be further simplified later.
It's maybe time to stress test this implementation with a good set of layout
tests. The two-valid-variants.fo file is a good start because you can easily
make one or the other variant appear in the final output by playing with the
.minimum and .maximum components of the elastic space.
Then you can address the case where the multi-switch ends up in the middle of a
page. A mere glue following the penalty, with the size of the first variant for
its width, should do.
Thanks,
Vincent
> 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_best-fit_ext_rev4.patch,
> FO_multi-switch_best-fit_ext_rev5.patch,
> FO_multi-switch_best-fit_ext_rev6.patch,
> FO_multi-switch_best-fit_ext_rev7.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, two-valid-variants.fo
>
>
> 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.4#6159)
[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=13837021#comment-13837021
]
Vincent Hennebert commented on FOP-2293:
Hi Seifeddine,
this is looking good. Just a few things:
{quote}
bq. This dynamicNode boolean doesn't seem necessary to me. Why would you prefer
a node to another just because it corresponds to a multi-switch? It's better to
rely on the progress made in the Knuth sequence like is done in the default
implementation.
That perplexed me for a while. For instance, if we have 2 possible layouts: one
where the 1st variant of the dynamic content doesn't fit and another case where
the 2nd variant fits perfectly. The first possibility should have fewer total
demerits than the second one. Which one should we choose?
{quote}
Not sure what you mean here. If the 1st variant doesn't fit... well it doesn't
fit :-) Did you mean, where the 1st variant _does_ fit?
I might see where you're going though: what if with one active node, it's the
1st variant that fits, and with another active node, it's the 2nd? I see two
possibilities: either select only one best node (per fitness class), that is
the one with the fewest total demerits. Or select a best node per fitness class
_and_ per selected variant. But that will increase the number of active nodes,
and in practice might have little use.
For now, I would remove that dynamicNode boolean and compute demerits as usual.
{quote}
bq. findBestFitPenalty: not sure why this method is necessary. If a node
contains a non-null variant, that necessarily means that the element pointed to
by the position field is the corresponding BestFitPenalty?
Not necessarily. First, because the par member variable is susceptible to
change, hence invalidating the position field in the Knuth node. Second, there
is an infinitely stretching glue at the end of the Knuth sequence which makes
the algorithm create a new finalizing node.
{quote}
I don't have any case in mind where the par variable is being modified _while_
the breaking algorithm is run? As to the second point, if the node doesn't
point to the special penalty, that means that the multi-switch doesn't end the
page. So it shouldn't be taken into account, not through the penalty at least.
We are in the "middle of the page" case that we can tackle later on by adding a
glue "at the right place" in the Knuth sequence.
And a couple other things:
* why this resetCurrentVariant? Can you not just reset it at the beginning of
computeDifference?
* multi-switch_best-fit.xml: I know that it's possible to check on the Knuth
sequence, but in practice it's rarely done, and not ideal. We've had cases in
the past where, after a slight alteration in the Knuth element generation, we
had to re-visit all those test cases and update the checks, a rather painful
process. A unit test would probably be better suited, where you can mock
anything you want (using Mockito) and have more targeted checks. That said,
this test case is definitely a good start to add checks on the area tree.
Thanks,
Vincent
> 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_best-fit_ext_rev4.patch,
> FO_multi-switch_best-fit_ext_rev5.patch,
> FO_multi-switch_best-fit_ext_rev6.patch,
> FO_multi-switch_best-fit_ext_rev7.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, two-valid-variants.fo
>
>
> 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=13834162#comment-13834162
]
Vincent Hennebert commented on FOP-2293:
Hi Seifeddine,
thanks for your patch. I'd have to look at it in more details before applying
it, but from a quick look I have the following comments:
* It would be better to store the selected variant on the BestPageRecords
instead of a separate map, the same way as footnotes are handled. You would
just have a {{variant}} field in PageBreakingAlgorithm that would be reset at
the beginning of computeDifference, and set to the proper value in
handleBestFitPenalty. Then you add a parameter to the KnuthPageNode constructor
for the variant, and you should be done.
* This dynamicNode boolean doesn't seem necessary to me. Why would you prefer a
node to another just because it corresponds to a multi-switch? It's better to
rely on the progress made in the Knuth sequence like is done in the default
implementation.
* in handleBestFitPenalty: the idea is there, but some adjustments will be
needed:
** you must use the computeDifference and computeAdjustmentRatio methods from
PageBreakingAlgorithm and not BreakingAlgorithm, because you must take
footnotes into account. You could move the content of computeDifference into a
new method that will be called by both computeDifference and
handleBestFitPenalty. computeDifference would then just contain the test
whether we are dealing with a special penalty or not.
** I thought the idea was to select the first variant that fits? In which case
you can break out of the loop as soon as you find an adjustmentRatio >= -1
* findBestFitPenalty: not sure why this method is necessary. If a node contains
a non-null variant, that necessarily means that the element pointed to by the
position field is the corresponding BestFitPenalty?
Thanks,
Vincent
> 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_best-fit_ext_rev4.patch,
> FO_multi-switch_best-fit_ext_rev5.patch,
> FO_multi-switch_best-fit_ext_rev6.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, two-valid-variants.fo
>
>
> 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 ] Vincent Hennebert updated FOP-2293: --- Attachment: two-valid-variants.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 > 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_best-fit_ext_rev4.patch, > FO_multi-switch_best-fit_ext_rev5.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, two-valid-variants.fo > > > 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=13827905#comment-13827905
]
Vincent Hennebert commented on FOP-2293:
Hi Seifeddine,
thanks for your patch. I’ve partially applied it in [rev.
1543891|http://svn.apache.org/r1543891].
The approach is taking shape. A few comments:
In BestFitLayoutUtils:
* calculateLength: there’s no need to add a dummy penalty at the beginning of
the list. Yes, there are issues with space resolution, but if you add the
penalty you will run into some bugs and if you remove it you will run into
other bugs. The real solution to the problem is to change space resolution to
perform partial resolution on a subset of the Knuth sequence, and refine it
later on. But this is out of the scope of this work and can be left as is for
now (for that matter, footnotes have been suffering from the same problem for
years).
* getKnuthList: there’s no need to add an empty box before the BestFitPenalty.
A penalty doesn’t need to be preceded by a box to be a legal break point, only
a glue does.
In PageBreakingAlgorithm:
* The WhiteSpaceManager class in PageBreakingAlgorithm looks problematic to me.
Information about a page break can now be found at two places: in this class,
and in KnuthPageNode. This will inevitably create inconsistencies and
difficulties to manage state that is distributed over several entities. This is
illustrated by the fact that you have to manage a list of alternatives that
(IIUC) will depend on the selected break point. That list is already there in
the form of KnuthPageNodes! The KnuthPageNode class should just be augmented to
contain the selected variant of the multi-switch, if any.
* in computeDifference: I’m not too sure of the meaning of the added {{if
(element instanceof BestFitPenalty)}} test. What do you have in mind? Also, the
second test {{if (diff > 0 && dynamicContentBPD > 0 && !(element instanceof
BestFitPenalty))}}: is it to handle the case where a multi-switch is in the
middle of a page? In that case, you can’t simply deactivate a variant. It’s
perfectly possible to have one layout where the multi-switch is at the bottom
of a page, and one where it’s in the middle of a page. Which layout will be
selected in the end depends on what follows. The middle-of-page case will be
handled by inserting a glue at the right place in the Knuth sequence, but you
can leave that for now and concentrate on page breaks.
* in handleBestFitPenalty: again, just because in one case there is no space
for a variant doesn’t mean that there won’t be space in any other cases. See
uploaded file two-valid-variants.fo. Comment out the multi-switch and play with
the space-before.minimum value: if left to 20pt, the variant with 2 lines on
the first page is selected, if set to 15pt, the variant with 3 lines on the
first page is selected. Once you re-enable the multi-switch, that will have an
impact on which variant will be selected: the one-line variant in the first
case, the two-line variant in the second case.
I really encourage you to create a simple layout test to check your
implementation. This two-valid-variants example could be a good start. Also,
you may want to run a test coverage tool to ensure that the code you write is
actually run and tested.
Thanks,
Vincent
> 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_best-fit_ext_rev4.patch,
> FO_multi-switch_best-fit_ext_rev5.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] [Resolved] (FOP-2312) font-base configuration setting not working as expected
[ https://issues.apache.org/jira/browse/FOP-2312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert resolved FOP-2312. Resolution: Fixed Hi Ivan, thanks for your bug report and your investigation. It turns out that my fix from rev. 1534704 uncovered deeper problems with relative URI resolution. This should now be fixed in [rev. 1542190|http://svn.apache.org/r1542190]. Thanks, Vincent > font-base configuration setting not working as expected > --- > > Key: FOP-2312 > URL: https://issues.apache.org/jira/browse/FOP-2312 > Project: Fop > Issue Type: Bug >Affects Versions: trunk > Environment: Tested on Windows, Linux >Reporter: Ivan Habunek > Attachments: error.txt, fop.xconf, in.fo > > > When converting FO to PDF, FOP looks for fonts in the directory where the > input FO file is located, not where specifies. > I use nightly builds since I need some new features. This problem did not > exist in build 20130918, but it does in current builds (tested on 20131107). > To reproduce (on windows, but the same procedure works on linux) > 1. Create a working directory (I used D:\Temp\fop) > 2. Take the attached config file (fop.xconf), and place it in the working > directory. It contains: "." so it should look for > fonts in the directory where the config file is located. > 3. Download takao fonts from https://launchpad.net/takao-fonts/ >Extract TakaoPGothic.ttf into the working directory. >Alternatively, use any other ttf font (just change config file). > 4. Download fop-20131107 nightly, and extract it to the working directory > 5. Take the attached FO file (in.fo) and place it another directory (i used > D:\Temp\input) - it's important it's not located directly in the working > directory. > 6. Open console, chdir to the working directory and run: > fop-20131107\fop -c fop.xconf -fo D:\temp\input\in.fo -pdf out.pdf > Expected: > Conversion works > Actual: > Conversion breaks with error: java.io.FileNotFoundException: > D:\temp\input\takao-pgothic.ttf (The system cannot find the file specified) > Full stack in attached file error.txt. > For some reason it's looking for fonts in the directory where the FO file is > located. > If you run the same scenario with v1.1 or an older nightly, this error does > not happen. -- 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=13816427#comment-13816427 ] Vincent Hennebert commented on FOP-2293: Hi Seifeddine, thanks for your patch. I’ve applied it in [rev. 1539809|http://svn.apache.org/r1539809]. I have the following questions and comments: * FOPropertyMapping: The fox:fitting-strategy property is no longer needed is it? Same for Alternative.FittingStrategy. * BestFit: same here? * 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? * MultiToggle: why bother implementing it? AFAIU you won’t need it in your extension. If you implement it you have to test it... I didn’t include the test case as I think it still needs a bit of work: * I wouldn’t qualify nested multi-switch elements as simple test. Maybe you want to concentrate on the basics first and handle advanced use cases later. * Instead of using space-after to artificially grow the size of a multi-case, you probably want to use a series of block elements. Space is subject to element resolution (See SpaceResolver.resolveElementList), and may disappear as the result of that. At any rate, it should in the present case since the space is conditional and would end a reference-area. All that to say: better use plain blocks and leave complex content for later, once the basics are working. * It would be good if the test case were reflecting the choice of a variant at the bottom of a page. In this test the multi-switch elements are found in the middle of the page, which AFAIU you haven’t implemented yet. * Please remove tabs from XML files and use a two-space indentation: tabs are as troublesome in XML as they are in Java. When running the test case I noticed that the following warning is still issued: “The following feature isn’t implemented by Apache FOP, yet: fo:multi-switch”. You may want to fix that. I noticed you tried a different approach at managing variants, by detecting page overflows and restarting the breaking algorithm at an earlier node after having discarded the current variant and moved on to the next one. That seems like a good idea, but the code is deceptively simple and I think you will get in trouble as you move foward in the implementation: * Imagine the following test case: let’s call E the element just before the multi-switch, and assume that there is a legal break after that element. But that legal break results into a tooShortNode. Also, the first variant of the multi-switch leads to a tooLongNode, but the second variant perfectly fits on the page. When you are at the multi-switch, you will have a tooLongNode, the number of active nodes will drop to zero, which triggers the node recovery mechanism. Since there is a tooShortNode available, the algorithm will pick it (it’s better to have not enough content on a page than overflowing content that may be clipped). So the final break will be at element E, and the user will wonder why FOP broke the page there while there was enough room on the page to fit the second variant. * Even if you find a fix for the preceding case, restarting at the node before every time a variant must be skipped is sub-optimal and creates unnecessary work for the breaking algorithm. * The node recovery mechanism is particularly tricky and hard to understand, so fiddling with it is not advised unless there is no other option... I suggest you carry on with the approach you had in your previous patches, which I think was integrating better with the algorithm, and in the end will lead to more robust and simpler code. You ‘just’ have to pass information to the KnuthPageNode about which variant of the multi-switch is associated to it, and all the way down the line until you are back in MultiSwitchLM. Feel free to ask if you have any questions. Thanks, Vincent > 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_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
[jira] [Closed] (FOP-2106) [PATCH] docbook footnote and body text overlap (example fo file included)
[ https://issues.apache.org/jira/browse/FOP-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert closed FOP-2106. -- Hi Alexey, at first I thought I wouldn't want to artificially grow the number of test cases, which is already quite high. But then, what you are saying makes sense, so I added it in [rev. 1538963|http://svn.apache.org/r1538963]. Thanks for your suggestion, Vincent > [PATCH] docbook footnote and body text overlap (example fo file included) > - > > Key: FOP-2106 > URL: https://issues.apache.org/jira/browse/FOP-2106 > Project: Fop > Issue Type: Bug > Components: page-master/layout >Affects Versions: 1.0 > Environment: Operating System: Linux > Platform: PC >Reporter: Petter Reinholdtsen >Priority: Blocker > Attachments: bad-footnote.fo, fop-2106.diff, fop-2106.diff, > totalFootnotesLength.fo > > > I discovered this problem with the fop backend of xmlto when using it > to create a PDF. The docbook document in question is rather large, > but I managed to extract an except demonstrating the problem. The > problem is that the footnote text and the body text overlap. I > initially reported it to Debian as > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683197 > but > thought it best to report it here too. The docbook source and the > generated PDF is attached to the Debian bug report. Notice in the > example how the text of the footnote on the second to last page is > overlapping with the body. > I generated the PDF using this command: > xmlto --noautosize -m xmlto-pdf.xsl --with-fop pdf bad-footnote.xml > The full document set is available from > https://github.com/petterreinholdtsen/free-culture-lessig >, if > you want to check it out. > When I investigated some more, I concluded that the problem is with > the fop processor, not xmlto. The problem exist in both fop versions > 1:0.95.dfsg-11 and 1:1.0.dfsg2-6 in Debian. The fo code generated by > xmlto include the footnote content as it should, and when I manually > process the .fo file using fop, the resulting PDF have the overlapping > text. > I am attaching the .fo file I used to test this, to allow you to > reproduce the problem and try to find a fix. :) > Could this be the same problem reported in > https://issues.apache.org/bugzilla/show_bug.cgi?id=51304 > > This issue make fop useless for making the PDF version of the Free > Culture book. :( -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (FOP-1749) [PATCH] infinite loop in footnotes (see also #47424)
[ https://issues.apache.org/jira/browse/FOP-1749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert resolved FOP-1749. Resolution: Fixed Patch applied in [rev. 1538961|http://svn.apache.org/r1538961]. Thanks! Vincent > [PATCH] infinite loop in footnotes (see also #47424) > > > Key: FOP-1749 > URL: https://issues.apache.org/jira/browse/FOP-1749 > Project: Fop > Issue Type: Bug > Components: page-master/layout >Affects Versions: trunk > Environment: Operating System: Windows XP > Platform: PC >Reporter: Heidi Vanparys > Attachments: bug47424.patch, c.fo, fop-1749-2106-combined.diff, > fop-1749-top-offset.diff, fop-1749.diff > > > This patch solves the problem of an infinite loop in footnotes as reported in > FOP-1678. > The infinite loop occurred in > org.apache.fop.layoutmgr.PageBreakingAlgorithm.getFootnoteSplit(int, int, > int, int, boolean). > This patch does not solve the problem of another infinite loop in footnotes > as reported in bugs 48063 and 48162. This infinite loop occurs in > org.apache.fop.layoutmgr.PageBreakingAlgorithm.createFootnotePages(KnuthPageNode). > The test attached to 48063 is converted to a testcase and added to the list > of disabled testcases. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (FOP-2306) Base URI is taken from config file instead of FO file
[ https://issues.apache.org/jira/browse/FOP-2306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert resolved FOP-2306. Resolution: Fixed Fixed in [rev. 1534704|http://svn.apache.org/r1534704]. > Base URI is taken from config file instead of FO file > - > > Key: FOP-2306 > URL: https://issues.apache.org/jira/browse/FOP-2306 > Project: Fop > Issue Type: Bug >Reporter: Vincent Hennebert > > When the config file doesn't specify a base URI, that latter should default > to the URI of the source FO document. Among other things, this is necessary > to properly handle images that have been specified with a relative URI. > ATM the URI of the config file is being used, which is counter-intuitive and > doesn't work if the config file is in a different directory to the FO file. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (FOP-2306) Base URI is taken from config file instead of FO file
Vincent Hennebert created FOP-2306: -- Summary: Base URI is taken from config file instead of FO file Key: FOP-2306 URL: https://issues.apache.org/jira/browse/FOP-2306 Project: Fop Issue Type: Bug Reporter: Vincent Hennebert When the config file doesn't specify a base URI, that latter should default to the URI of the source FO document. Among other things, this is necessary to properly handle images that have been specified with a relative URI. ATM the URI of the config file is being used, which is counter-intuitive and doesn't work if the config file is in a different directory to the FO file. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (FOP-1749) [PATCH] infinite loop in footnotes (see also #47424)
[ https://issues.apache.org/jira/browse/FOP-1749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13801773#comment-13801773 ] Vincent Hennebert commented on FOP-1749: Hi Alexey, thanks for your patch. It's looking good, so as soon as we have received your ICLA I'll commit it to the trunk. Vincent > [PATCH] infinite loop in footnotes (see also #47424) > > > Key: FOP-1749 > URL: https://issues.apache.org/jira/browse/FOP-1749 > Project: Fop > Issue Type: Bug > Components: page-master/layout >Affects Versions: trunk > Environment: Operating System: Windows XP > Platform: PC >Reporter: Heidi Vanparys > Attachments: bug47424.patch, c.fo, fop-1749-2106-combined.diff, > fop-1749.diff, fop-1749-top-offset.diff > > > This patch solves the problem of an infinite loop in footnotes as reported in > FOP-1678. > The infinite loop occurred in > org.apache.fop.layoutmgr.PageBreakingAlgorithm.getFootnoteSplit(int, int, > int, int, boolean). > This patch does not solve the problem of another infinite loop in footnotes > as reported in bugs 48063 and 48162. This infinite loop occurs in > org.apache.fop.layoutmgr.PageBreakingAlgorithm.createFootnotePages(KnuthPageNode). > The test attached to 48063 is converted to a testcase and added to the list > of disabled testcases. -- 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=13790739#comment-13790739 ] Vincent Hennebert commented on FOP-2293: Hi Seifeddine, I can't apply your patch as it's missing new files (DynamicKnuthBox, MultiCaseHandler, MultiCaseLayoutManager, etc.). Remember to svn add them before creating the patch. A few comments, just from reading the patch since I couldn't run it: * BestFit.filter: why would you want to remove children FO nodes? Seems to me like you just want to somehow select the right one. * 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. * MultiSwitch.finalizeNode: the selection of the best node cannot be done here? You have to wait for the results of layout? * 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... * if you could run Checkstyle before submitting your patch, that would help more quickly apply it. I'd say, forget about inline content for now, and have it working and tested with just block content. At a next step you can concentrate on inline content. At this point it would be good to have a layout test accompanying your patch. That would serve two purposes: catch regressions, and document the implementation of your extension. That would give us a sample with which we can play and experiment. Have a look at the [developer wiki|http://wiki.apache.org/xmlgraphics-fop/HowToCreateLayoutEngineTests] for some information. Thanks, Vincent > 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-1749) [PATCH] infinite loop in footnotes (see also #47424)
[ https://issues.apache.org/jira/browse/FOP-1749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13789135#comment-13789135 ] Vincent Hennebert commented on FOP-1749: Hi Alexey, I applied the patch you submitted to FOP-2106, which fixes the infinite loop. But since there is still a problem with the footnote not showing up on the output, I'm going to leave this one open for now. Thanks, Vincent > [PATCH] infinite loop in footnotes (see also #47424) > > > Key: FOP-1749 > URL: https://issues.apache.org/jira/browse/FOP-1749 > Project: Fop > Issue Type: Bug > Components: page-master/layout >Affects Versions: trunk > Environment: Operating System: Windows XP > Platform: PC >Reporter: Heidi Vanparys > Attachments: bug47424.patch, c.fo, fop-1749-2106-combined.diff, > fop-1749.diff > > > This patch solves the problem of an infinite loop in footnotes as reported in > FOP-1678. > The infinite loop occurred in > org.apache.fop.layoutmgr.PageBreakingAlgorithm.getFootnoteSplit(int, int, > int, int, boolean). > This patch does not solve the problem of another infinite loop in footnotes > as reported in bugs 48063 and 48162. This infinite loop occurs in > org.apache.fop.layoutmgr.PageBreakingAlgorithm.createFootnotePages(KnuthPageNode). > The test attached to 48063 is converted to a testcase and added to the list > of disabled testcases. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (FOP-2106) [PATCH] docbook footnote and body text overlap (example fo file included)
[ https://issues.apache.org/jira/browse/FOP-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert resolved FOP-2106. Resolution: Fixed Hi Alexey, thanks for your patch, and sorry about the delay for processing it. I applied it in rev. 1530232. I made minor changes, mainly removed the change made in PageBreakingAlgorithm around line 645 (|| length < insertedFootnotesLength). I think we want to keep totalFootnotesLength here. Please let me know if you don't agree. I also anonymised the test case a bit, and removed the one I had created to show a regression in your previous patch. I don't think it was worth including it. Thanks! Vincent > [PATCH] docbook footnote and body text overlap (example fo file included) > - > > Key: FOP-2106 > URL: https://issues.apache.org/jira/browse/FOP-2106 > Project: Fop > Issue Type: Bug > Components: page-master/layout >Affects Versions: 1.0 > Environment: Operating System: Linux > Platform: PC >Reporter: Petter Reinholdtsen >Priority: Blocker > Attachments: bad-footnote.fo, fop-2106.diff, fop-2106.diff, > totalFootnotesLength.fo > > > I discovered this problem with the fop backend of xmlto when using it > to create a PDF. The docbook document in question is rather large, > but I managed to extract an except demonstrating the problem. The > problem is that the footnote text and the body text overlap. I > initially reported it to Debian as > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683197 > but > thought it best to report it here too. The docbook source and the > generated PDF is attached to the Debian bug report. Notice in the > example how the text of the footnote on the second to last page is > overlapping with the body. > I generated the PDF using this command: > xmlto --noautosize -m xmlto-pdf.xsl --with-fop pdf bad-footnote.xml > The full document set is available from > https://github.com/petterreinholdtsen/free-culture-lessig >, if > you want to check it out. > When I investigated some more, I concluded that the problem is with > the fop processor, not xmlto. The problem exist in both fop versions > 1:0.95.dfsg-11 and 1:1.0.dfsg2-6 in Debian. The fo code generated by > xmlto include the footnote content as it should, and when I manually > process the .fo file using fop, the resulting PDF have the overlapping > text. > I am attaching the .fo file I used to test this, to allow you to > reproduce the problem and try to find a fix. :) > Could this be the same problem reported in > https://issues.apache.org/bugzilla/show_bug.cgi?id=51304 > > This issue make fop useless for making the PDF version of the Free > Culture book. :( -- This message 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=13784390#comment-13784390
]
Vincent Hennebert commented on FOP-2293:
{quote}
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.
{quote}
Yes, that's why I prefer my second proposal that puts multi-switch inside the
extension element. But the majority seems to lean towards the use of an
extension property on multi-switch anyway, and as the one who's implementing it
you get to choose what's easiest for you.
{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}
Actually, FOP trunk must also be 1.5 compliant.
{quote}
Never mind, the patch is not supposed to be committed anyway.
{quote}
Ah ok. Shall I commit your patch rev2 from 11th of September then? Or wait for
the next one?
Thanks,
Vincent
> 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=13782960#comment-13782960
]
Vincent Hennebert commented on FOP-2293:
{quote}
(3) the suggested extension on multi-switch retains and precisely uses the
intended semantics of multi-switch: to select between alternatives;
{quote}
I understand the semantics of multi-switch to be listing alternatives; the
_selection_ of alternatives is left to fo:multi-toggle.
{quote}
(4) the specification does not preclude using a alternate selection mechanism
than multi-toggle or using such a mechanism to imply semantics similar to
multi-toggle;
{quote}
Exactly; which is why I propose this fox:dynamic-content element.
{quote}
(5) resorting to defining a new element which almost completely overlaps the
semantics of an existing element is architecturally unsound, and leads to
proliferation of variation rather than harmonization of use;
{quote}
I don't see what the overlap would be between fo:multi-switch and
fox:dynamic-content?
In fact, fo:multi-switch could be put as a child of fox:dynamic-content:
{code:xml}
Case 1
Case 2
{code}
That said, I don't care too much whether the functionality is implemented as an
extension element or property. The ease with which either possibility can be
implemented also counts.
Vincent
> 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=13782837#comment-13782837 ] Vincent Hennebert commented on FOP-2293: Hi Seifeddine, 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). Would you mind re-creating it against the latest version of the branch and fixing those issues? If you delete files from previous patches, be sure to 'svn rm' them before creating the patch, so that the information can be carried in the patch. Thanks! Vincent > 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=13782823#comment-13782823
]
Vincent Hennebert commented on FOP-2293:
fo:multi-switch's sole purpose is to define a set of possibilities. It doesn't
say anything about which possibility should be selected and how. This is left
to the fo:multi-toggle element.
By adding some fox:fitting-strategy property to fo:multi-switch, we are moving
away from its mere function of listing possibilities, and we are adding
selection semantics. I reckon this violates the (spirit of the) Recommendation,
that gives one function and only one to an element.
Since we can't use fo:multi-toggle because its semantics diverge too much from
our purpose, I think an extension element should be defined. So I would go for
Pascal's suggestion 1, amended:
{code:xml}
Case 1
Case 2
{code}
I'm open about the element and property names.
> 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-1749) [PATCH] infinite loop in footnotes (see also #47424)
[ https://issues.apache.org/jira/browse/FOP-1749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13777280#comment-13777280 ] Vincent Hennebert commented on FOP-1749: Leaving boxPreceding to false when the box has zero width would go against the principles of the algorithm, so will most probably cause bugs in other cases. The width of the glue should somehow be taken into account when another iteration of the outer loop (while (!(somethingAddedd && splitLength > availableLength))) is run. But this code that iterates through Knuth elements and computes total length/shrink/stretch is present in many places. Maybe there's an opportunity to factorise things and re-use one, proper, implementation. Vincent > [PATCH] infinite loop in footnotes (see also #47424) > > > Key: FOP-1749 > URL: https://issues.apache.org/jira/browse/FOP-1749 > Project: Fop > Issue Type: Bug > Components: page-master/layout >Affects Versions: trunk > Environment: Operating System: Windows XP > Platform: PC >Reporter: Heidi Vanparys > Attachments: bug47424.patch, c.fo, fop-1749.diff > > > This patch solves the problem of an infinite loop in footnotes as reported in > FOP-1678. > The infinite loop occurred in > org.apache.fop.layoutmgr.PageBreakingAlgorithm.getFootnoteSplit(int, int, > int, int, boolean). > This patch does not solve the problem of another infinite loop in footnotes > as reported in bugs 48063 and 48162. This infinite loop occurs in > org.apache.fop.layoutmgr.PageBreakingAlgorithm.createFootnotePages(KnuthPageNode). > The test attached to 48063 is converted to a testcase and added to the list > of disabled testcases. -- 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-2106) [PATCH] docbook footnote and body text overlap (example fo file included)
[ https://issues.apache.org/jira/browse/FOP-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert updated FOP-2106: --- Attachment: totalFootnotesLength.fo Hi Alexey, thanks for your patch. But why do you replace insertedFootnotesLength with totalFootnotesLength in createNode? This will result into the loss of footnote content like in the attached totalFootnotesLength example. Vincent > [PATCH] docbook footnote and body text overlap (example fo file included) > - > > Key: FOP-2106 > URL: https://issues.apache.org/jira/browse/FOP-2106 > Project: Fop > Issue Type: Bug > Components: page-master/layout >Affects Versions: 1.0 > Environment: Operating System: Linux > Platform: PC >Reporter: Petter Reinholdtsen >Priority: Blocker > Attachments: bad-footnote.fo, fop-2106.diff, fop-2106.diff, > totalFootnotesLength.fo > > > I discovered this problem with the fop backend of xmlto when using it > to create a PDF. The docbook document in question is rather large, > but I managed to extract an except demonstrating the problem. The > problem is that the footnote text and the body text overlap. I > initially reported it to Debian as > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683197 > but > thought it best to report it here too. The docbook source and the > generated PDF is attached to the Debian bug report. Notice in the > example how the text of the footnote on the second to last page is > overlapping with the body. > I generated the PDF using this command: > xmlto --noautosize -m xmlto-pdf.xsl --with-fop pdf bad-footnote.xml > The full document set is available from > https://github.com/petterreinholdtsen/free-culture-lessig >, if > you want to check it out. > When I investigated some more, I concluded that the problem is with > the fop processor, not xmlto. The problem exist in both fop versions > 1:0.95.dfsg-11 and 1:1.0.dfsg2-6 in Debian. The fo code generated by > xmlto include the footnote content as it should, and when I manually > process the .fo file using fop, the resulting PDF have the overlapping > text. > I am attaching the .fo file I used to test this, to allow you to > reproduce the problem and try to find a fix. :) > Could this be the same problem reported in > https://issues.apache.org/bugzilla/show_bug.cgi?id=51304 > > This issue make fop useless for making the PDF version of the Free > Culture book. :( -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-1749) [PATCH] infinite loop in footnotes (see also #47424)
[ https://issues.apache.org/jira/browse/FOP-1749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13776416#comment-13776416 ] Vincent Hennebert commented on FOP-1749: Hi Alexey, thanks for your patch. Although when I tried it on the test you attached, the content of the footnote-body doesn't appear on the output? Also, adding the length of the glue element before breaking out of the loop is problematic because the glue will then be taken into account while it shouldn't: When breaking at a glue, the glue itself is ignored. Thanks, Vincent > [PATCH] infinite loop in footnotes (see also #47424) > > > Key: FOP-1749 > URL: https://issues.apache.org/jira/browse/FOP-1749 > Project: Fop > Issue Type: Bug > Components: page-master/layout >Affects Versions: trunk > Environment: Operating System: Windows XP > Platform: PC >Reporter: Heidi Vanparys > Attachments: bug47424.patch, c.fo, fop-1749.diff > > > This patch solves the problem of an infinite loop in footnotes as reported in > FOP-1678. > The infinite loop occurred in > org.apache.fop.layoutmgr.PageBreakingAlgorithm.getFootnoteSplit(int, int, > int, int, boolean). > This patch does not solve the problem of another infinite loop in footnotes > as reported in bugs 48063 and 48162. This infinite loop occurs in > org.apache.fop.layoutmgr.PageBreakingAlgorithm.createFootnotePages(KnuthPageNode). > The test attached to 48063 is converted to a testcase and added to the list > of disabled testcases. -- 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=13758338#comment-13758338
]
Vincent Hennebert commented on FOP-2293:
Hi Seifeddine,
thanks for your second patch. Some comments and answers to your questions:
* BestFit.bind: the {{for}} loop for getting the fitting strategy is great;
just move it to the FittingStrategy class itself as it is of general use.
* BestFitLayoutManager.getNextKnuthElements: the comment at the end of the
method is great to indicate that this is temporary and that you are planning to
return to it later. The general practice in such a case is to add the TODO
keyword, that will be highlighted by the IDE and is easily searchable.
{quote}
bq. 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.
{quote}
My bad, every penalty element is actually considered only once by the breaking
algorithm. It would still be better though to move the creation of the penalty
inside the alternative. 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}
bq. 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:
{quote}
You make a good point. However, you will also have to consider more complex
cases like deep nesting: for example, a best-fit block inside a block inside an
alternative-block inside a best-fit block.
{quote}
bq. totalWidth should not be updated if an alternative is found, since you’re
dealing with a penalty element.
That broke the JUnit test. It no longer gives the expected result.
{quote}
The test still passes on my side?
The multiple-feasible-nodes.fo file is attached to this JIRA issue.
To conclude with the namespace issue: like Pascal said, since the
fitting-strategy property is meant to be used on a fox element only, it
shouldn’t be put in the fox namespace.
Regarding the FOP wiki: did you try to create an account?
Thanks,
Vincent
> 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=13758352#comment-13758352 ] Vincent Hennebert commented on FOP-2293: bq. In that case, I will have to oppose this change, since it is attempting to introduce a new semantic specific container type. We should not be introducing new FO element types as extensions. What do you mean by ‘new FO element type’? I don’t see anything wrong with creating extension layout elements, if the standard ones don’t allow you to achieve what you need. Why would a fox property be preferable? I think it would actually be harmful as it would change the semantics of the FO element it is used on. Could you clarify? Whether the extension elements in the present case are of general interest enough to be integrated in FOP is another discussion, that we can have before merging the branch. Thanks, Vincent > 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=13754537#comment-13754537 ] Vincent Hennebert commented on FOP-2293: Hi Seifeddine, to update the wiki you will have to create an account. As a guard against spam your account will have to be approved by one of the committers but that should be fairly straightforward. Thanks, Vincent > 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-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=13753919#comment-13753919 ] Vincent Hennebert commented on FOP-2292: I guess some LayoutManager doesn't handle changing IPD well in some cases. But, without being able to reproduce the issue, that's all I can say I'm afraid. > [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=13753909#comment-13753909 ] Vincent Hennebert commented on FOP-2293: Exactly. That's why we want to leave it in the per-element namespace since it will be used only on the fox:best-fit element. Vincent > 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 ] Vincent Hennebert updated FOP-2293: --- Attachment: multiple-feasible-nodes.fo How multiple feasible nodes per page can interfere with the extension code. > Whitespace management extension > --- > > Key: FOP-2293 > URL: https://issues.apache.org/jira/browse/FOP-2293 > Project: Fop > Issue Type: New Feature > Components: general >Affects Versions: trunk >Reporter: Seifeddine Dridi >Priority: Minor > Labels: XSL-FO > Fix For: trunk > > Attachments: bestfit.fo, doc.pdf, 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=13753851#comment-13753851
]
Vincent Hennebert commented on FOP-2293:
Hi Seifeddine,
thanks for your patch. I noticed you refer to the
[WhitespaceManagement|http://wiki.apache.org/xmlgraphics-fop/WhitespaceManagement]
page on the developer wiki. It would be good if you could put your doc into a
new section of that page, explaining what exactly you are planning to implement
and any divergence from what is already there.
Some high-level comments about your patch:
* Please set up Checkstyle using the checkstyle-5.5.xml file at the root of the
project and fix all the warnings. I already fixed some of them but not all.
Among other things, it’s important to always put statements in {{if}} or
{{else}} blocks into braces, even if there is only one statement, to prevent
mistakes in case statements are added later on.
* FOP aims to be Java 1.5 compliant. Please compile the code with a 1.5 JDK, to
make sure you are not using methods from the standard library that were added
in Java 1.6 or later.
* Use the @Override annotation whenever you override a method. You should be
able to set up your IDE to do that automatically for you.
* Try and use enhanced for loops rather than iterators whenever you can, as
this usually makes the code much more concise. I did it in the filter method of
FIRST_FIT as illustration
* The naming of extension elements will probably have to be revised to make
them more concise and explicit. But we can handle that later on.
* Similarly, we will have to clarify whether the extension elements generate
areas or simply return the areas from their child elements, whether that would
be reference areas, etc.
* The fitting-strategy property should not be in the fox namespace since it’s
not meant to be used on elements from other namespaces. Simply leave it without
any namespace.
* The code doesn’t seem to work if the extension element is the last element of
the flow.
* Eventually, support for changing IPD will have to be added. I don’t think
that would work as it is?
And here are some finer-grain comments in specific parts of the code:
h6. BreakingAlgorithm
* handleBestFitPenalty
** Move this method to after considerLegalBreak, to follow the reading order
(from the higher-level method to the lower-level method).
** totalWidth should not be updated if an alternative is found, since you’re
dealing with a penalty element.
** Why should the test for difference be > 0 only? A negative difference is ok
as long as the adjustment ratio is >= -1.
** Creating a new KnuthPenalty for every alternative is not ideal. It should be
created once and stored in the 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). Its logic should probably be moved to
BestFitPenalty, which should also allow to avoid passing it around through
LayoutContext.
* considerLegalBreak: the test ‘if element instanceof BestFitPenalty’ should
not be put there as this method is also used for inline content, where such
elements will never be present. It should be moved to a method that will be
overridden in PageBreakingAlgorithm.
* 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.
h6. AlternativeManager
getBestAlternative: don’t catch the NPE. Change the code so that it tolerates a
null value, or if you really can’t then add an ‘if != null’ test
h6. BestFitPenalty
instead of having a getAlternativeCount and a getAlternative(int) method,
simply define one getAlternatives method that returns the list (or the
collection if ordering is not important) of alternatives.
h6. ElementListUtils
* The calcFullContentLength shouldn’t be necessary: you can probably call
SpaceResolver.resolveElementList first and then use the standard
calcContentLength method.
* Eventually the creation of BestFitLayoutManagerMaker and
AlternativeBlocklayoutManagerMaker will have to be moved to somewhere else than
LayoutManagerMapping since they are extension elements. But we can address that
later on.
h6. KnuthAlgorithmTestCase
This is an excellent start. The BestFitPenaltyTestCase inner class probably is
unnecessary, the method can just be moved to the outer class. Eventually this
test case can be completed to handle more cases (different and more complex
situations), moved into their own class if necessary.
h6. AlternativeBlock
* I renamed FO_NAME into OBJECT_NAME as this is not a formatting object
* 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. So
[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=13751422#comment-13751422 ] Vincent Hennebert commented on FOP-2292: What I actually meant is to make it reproducible using the sans-serif font family. The FO you sent works fine with trunk. If you could make the bug reproducible with trunk, standard fonts and no images, we could find out what's wrong. > [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=13751166#comment-13751166 ] Vincent Hennebert commented on FOP-2292: The error seems to indicate a bug in FOP, I don't think the font is at cause. The slightly different metrics to Arial might be enough for the bug to show up with Helvetica and not Arial. That's why it would be good if it could be reproduced with Helvetica, so that it can be investigated. > [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=13751080#comment-13751080 ] Vincent Hennebert commented on FOP-2292: I can reproduce it with 1.1, but not with trunk. That might have to do with fonts and images not being available on our systems. Could you post an updated example that uses only standard fonts and no images? > [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] [Resolved] (FOP-2291) break-after="page" produces blank page but doesn't use blank page master
[ https://issues.apache.org/jira/browse/FOP-2291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert resolved FOP-2291. Resolution: Invalid Indeed the output is correct WRT the spec. See section 7.27.2, "blank-or-not-blank", of the XSL-FO 1.1 Recommendation. The master is eligible if there are no areas to be put on that page. However, on page 2 of your example, there is an (empty) area generated by the third fo:block. If you want a real blank page, you have to play with multiple page-sequences and the force-page-count property. HTH, Vincent > break-after="page" produces blank page but doesn't use blank page master > > > Key: FOP-2291 > URL: https://issues.apache.org/jira/browse/FOP-2291 > Project: Fop > Issue Type: Bug > Components: page-master/layout >Affects Versions: 1.1 > Environment: Window 7, Java 1.7.0_03 >Reporter: Clay Helberg > Attachments: blanktest.fo, blanktest.pdf > > > I'm trying to produce a blank page corresponding to some content, using an > empty fo:block with break-after="page". It does produce a blank page, but it > uses the standard odd or even not-blank page master instead of using the > blank page master. > I've verified that the blank page master triggers for auto-generated blank > pages, but not for the manually generated ones. -- 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-2275) Quadratic Bézier curves not properly rendered
[ https://issues.apache.org/jira/browse/FOP-2275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert updated FOP-2275: --- Attachment: quadratic-bezier.pdf quadratic-bezier.svg quadratic-bezier.fo Sample files. The curve should go all the way down to the bottom edge of the rectangle. > Quadratic Bézier curves not properly rendered > - > > Key: FOP-2275 > URL: https://issues.apache.org/jira/browse/FOP-2275 > Project: Fop > Issue Type: Bug > Components: pdf >Reporter: Vincent Hennebert > Attachments: quadratic-bezier.fo, quadratic-bezier.pdf, > quadratic-bezier.svg > > > Quadratic Bézier curves (q command in SVG) are rendered in PDF using cubic > Bézier operators (the y PDF operator). That gives a wrong result. -- 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-2275) Quadratic Bézier curves not properly rendered
Vincent Hennebert created FOP-2275: -- Summary: Quadratic Bézier curves not properly rendered Key: FOP-2275 URL: https://issues.apache.org/jira/browse/FOP-2275 Project: Fop Issue Type: Bug Components: pdf Reporter: Vincent Hennebert Quadratic Bézier curves (q command in SVG) are rendered in PDF using cubic Bézier operators (the y PDF operator). That gives a wrong result. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FOP-1333) External graphic doesnt size properly with height set at 100%
[ https://issues.apache.org/jira/browse/FOP-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert closed FOP-1333. -- Resolution: Not A Problem The two overflow messages can be explained: * Regarding the region-before: height doesn't apply on fo:block, so it is just ignored. A value of 100% on the external-graphics means that it takes its height from the parent element (the fo:block). But since the size of that latter depends on its content, the value is interpreted as "auto" (see Section 7.15.6, "height", from XSL-FO 1.1). On an external-graphic, a value of "auto" for height means that the intrinsic size of the graphic is used (see Section 6.6.5, "fo:external-graphic", from XSL-FO 1.1). Basically, you cannot use percentages to specify the height of an image. You have to put the size explicitly (from which you have subtracted the border widths). * Regarding region-body: The height of 100% set on the block-container specifies its /content/ height: just the content, without the padding nor the border. But since you specified a border of 0.25mm, that doesn't fit in the page. Set the height to "100% - 0.5mm" and the overflow error disappears. Vincent > External graphic doesnt size properly with height set at 100% > - > > Key: FOP-1333 > URL: https://issues.apache.org/jira/browse/FOP-1333 > Project: Fop > Issue Type: Bug > Components: general >Affects Versions: 0.93 > Environment: Operating System: other > Platform: PC >Reporter: Barry Pearce > Attachments: logo.jpg, test.pdf > > > The following XSL-FO causes a complaint about the graphics being out of limits > and DOES NOT render at the scaled size. The specification states that a height > of 100% should cause the area to be set at the same size of the parent (which > should be the size of extent in this case. > > http://www.w3.org/1999/XSL/Format";> > > page-width="210mm" page-height="297mm" > margin-top="10mm" margin-bottom="10mm" > margin-left="10mm" margin-right="10mm" > padding="0"> > margin="0" margin-top="32mm" padding="0"/> > margin="0" padding="0"/> > > > > > > height="100%" width="100%" > border-style="solid" > border-color="orange" border-width="0.25mm"> > border-style="solid" > border-color="black" border-width="0.25mm" > scaling="uniform" > scaling-method="resample-any-method" > height="100%" > content-height="scale-to-fit" > src="logo.jpg" > /> > > > > height="100%" width="100%" > border-style="solid" > border-color="blue" border-width="0.25mm"> >font-family="serif" > line-height="30pt"> > LOGO CHECK > > > > > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FOP-2272) The content of fo:table-cell was lost at the end of a page
[ https://issues.apache.org/jira/browse/FOP-2272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert closed FOP-2272. -- Resolution: Not A Problem You have a keep-together.within-column="always" on the block surrounding the content. Change that to "auto" and the content of the cell will be broken over pages. In the future, it's best to ask on the fop-users mailing list first, and open an issue only when you have confirmation that there's a bug. http://xmlgraphics.apache.org/fop/maillist.html#fop-user Thanks, Vincent > The content of fo:table-cell was lost at the end of a page > -- > > Key: FOP-2272 > URL: https://issues.apache.org/jira/browse/FOP-2272 > Project: Fop > Issue Type: Bug >Affects Versions: 0.95, 1.1 > Environment: Windows 7 >Reporter: Json > Attachments: data-was-lots-at-the-end-of-a-page.fo, > data-was-lots-at-the-end-of-a-page.png > > > In case the content of a cell in a row can't fit in a page, it's content will > be lost at the end of page. I would like to display the lost data in the next > page. How must i do ? Please help me . > Please see attach 'data-was-lots-at-the-end-of-a-page.png' and > 'data-was-lots-at-the-end-of-a-page.fo' -- 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=13651695#comment-13651695 ] Vincent Hennebert commented on FOP-2193: You have to generate the PDF from the IF: fop -c fop.xconf svg-if-space.fo -if application/pdf if.xml fop -c fop.xconf -ifin if.xml 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-2222) Incorrect page break in cell
[ https://issues.apache.org/jira/browse/FOP-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13651355#comment-13651355 ] Vincent Hennebert commented on FOP-: This issue indeed corresponds to what is described in that 'Known Problems' section; it has nothing to do with column balancing. Column balancing was about better taking into account the properties of boxes, glues and penalties: mainly, include the height of a penalty when breaking there, and discard glues and penalties that follow a break up to the next box. This problem has to do with Knuth elements not accurately representing the actual content. It is described into more details at the following page: http://wiki.apache.org/xmlgraphics-fop/TableLayout/KnownProblems Fixing it requires an intimate understanding of the box/glue/penalty model and the breaking algorithm. Departing from that algorithm would actually be necessary, as we would have to deal with different sequences of Knuth elements depending on where we break in the table. Given that the algorithm is all about considering several feasible breaks in the same time, those Knuth sequences would have to be dealt with simultaneously, in a compartmented way. Basically that issue shows that while the box/glue/penalty model is great to simulate a paragraph, it is not suited for more complex material like tables, that are made of loosely coupled columns of content. Between the synchronization points that row boundaries represent (more or less —you can also have row-spanning cells), the layouts of the different cells can vary widely. I think I'd rather try and find a way to work around this issue by designing the document differently... > Incorrect page break in cell > > > Key: FOP- > URL: https://issues.apache.org/jira/browse/FOP- > Project: Fop > Issue Type: Bug > Components: page-master/layout >Affects Versions: 1.1, trunk >Reporter: Nico > Attachments: test-two-cells.fo, test-two-cells.pdf > > > In a table with one row and two cells, spanning across multiple pages, the > pages break are not what should be expected. (I don't know if it's by design > or a bug). > Please see the attached .fo and .pdf. > Test case : the first cell has blocks with 120mm height. The second cell has > blocks with 100mm heights. The page height is 266mm > First page : each cell contains his two blocks on the page > second page : after the first page break, the fist cell show only the one > block where two is expected. The second block, which is on page 3, should fit > on page 2. > Is it standard behaviour ? Thanks. -- 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=13651252#comment-13651252 ] Vincent Hennebert commented on FOP-2193: I can still reproduce it with the latest trunk. There is white space between the left border and the 'A' glyph while there shouldn't be. How did you generate your IF? > 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-1099) footnotes within tables and listsl get lost
[ https://issues.apache.org/jira/browse/FOP-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13635441#comment-13635441 ] Vincent Hennebert commented on FOP-1099: Repeating the footnote on every page creates all sorts of problems: what do we do if a footnote doesn't fit on the current page and has to be deferred to the next one? The next page will end up having two identical footnotes. Also, how would footnote numbering work? The number would be duplicated? Putting the footnote into the first table-row after the table-header is well and good, but then the footnote mark will no longer appear in the header, which will probably not be what the user wants. It seems to me that this kind of requirement is better solved by using markers. > footnotes within tables and listsl get lost > --- > > Key: FOP-1099 > URL: https://issues.apache.org/jira/browse/FOP-1099 > Project: Fop > Issue Type: Bug > Components: page-master/layout >Affects Versions: trunk > Environment: Operating System: other > Platform: Other >Reporter: gerhard oettl > Attachments: b37579_2.patch, b37579.diff, b37579.diff, > bugzilla37579.patch, dorfchronik.fo, dorfchronik.fo.list3, > dorfchronik.fo.table3, footnote.fo, footnotes.080502.diff, footnotespatch, > fussnote.fo, table_list_footnotes.diff > > > Footnote outside of tables works, inside table-cell not. > The compliance page only speaks about restrictions within multicolumn > documents. -- 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=13635015#comment-13635015 ] Vincent Hennebert commented on FOP-2230: That confirms what I was going to say: the RTF output doesn't use FOP's layout engine, so we have little control over what it will look like. Different RTF processors are likely to produce different results, which is actually the case here. However, all of the outputs generated by the layout engine should look the same. > 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=13634321#comment-13634321 ] Vincent Hennebert commented on FOP-2230: After a closer look at this example, I'm tempted to say that the result is correct. Unexpected maybe, but correct. Cells 1.1 and 1.3 span 2 rows, but their content is only one line worth, so it all fits on the first row. As to cell 2.3, it's spanning rows 2 and 3, so it's ok if all its content is put on row 3. So row 2 is there, but it's basically empty. It has zero height. Requiring row 2 to have non-zero height means that we have to add some arbitrary whitespace. How much? That clashes with the page layout philosophy which is biased towards fitting as much content as possible on a page (for example, between two ways of laying out a paragraph, one on 9 lines, one or 10 lines, the 9-line version will be preferred). Besides, that layout with whitespace can be achieved by adding a block containing a non-breaking space after "1.1" (which is probably how you made the expected version). We could impose to put at least some content on every row, but it would be hard to define a way that would lead to satisfying results in every situation. For example, imagine that instead of the text "2.3" you have a big image. Do you really want to have row 3 starting all the way down after that big image? So we're facing a corner case here. All I can suggest is to re-work the layout of the table to avoid that situation... What do people think? > 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-2211) [PATCH] Fix & improve the handling of temporary files using the new URI resource resolvers
[
https://issues.apache.org/jira/browse/FOP-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633107#comment-13633107
]
Vincent Hennebert commented on FOP-2211:
To elaborate a bit, I think we now all agree that temporary files shouldn't be
handled by the URI framework. Those two issues are orthogonal.
The suggestion would be to scrape the tmp:// scheme from the URI framework and
to replace it with a system that manages temporary resources. A good use case
would be the PSDocumentHandler that, when optimize-resources is set to true,
stores the output in a temp file in order to re-arrange it in a second pass.
Instead of storing the whole output in one big temp file, it could be split
into several parts each stored in a different file, and then put together. A
new temporary resource manager should allow to easily do that.
Alexios, if you feel like exploring this idea further (you might have started
already?), then you would be most welcome, and I'll try and spare cycles to
review your work.
Thanks,
Vincent
> [PATCH] Fix & improve the handling of temporary files using the new URI
> resource resolvers
> --
>
> Key: FOP-2211
> URL: https://issues.apache.org/jira/browse/FOP-2211
> Project: Fop
> Issue Type: Bug
> Components: general
>Affects Versions: trunk
>Reporter: Alexios Giotis
>Assignee: Peter Hancock
> Fix For: trunk
>
> Attachments: fop.patch, fop.patch, tempurisimple.patch, xgc.patch
>
>
> As written in http://markmail.org/message/zelumstxxsdyvkcz , after the merge
> of the Temp_URI_Resolution branch (Sept 2012), the actual pattern of using
> temp files has changed from:
> {code}
> File tmpFile = File.createTempFile();
> // Write and read from the file
> tmpFile.delete();
> {code}
> to:
> {code}
> File tmpFile = new File(System.getProperty("java.io.tmpdir"),
> counterStartingFrom1AsString);
> tmpFile.deleteOnExit();
> // Write and read from the file
> {code}
> This is fine when FOP is executed from the command line (which I guess this
> is how most people use it) but it introduces a number of bad side effects for
> long running processes that use FOP embedded.
>
> 1. Different FOP processes can't be executed in parallel on the same system
> because creating the same temp file fails.
> 2. If the JVM is not normally terminated, the temp files are never deleted
> and the next invocation of the JVM fails to run.
> 3. deleteOnExit() keeps for the life of the JVM an unknown number of temp
> files both on disk and a reference in memory.
> There should not be a need to implement a custom resource resolver when using
> FOP embedded in order to fix those issues. The default implementation should
> work at least as good as it worked in FOP 1.1 or earlier.
> Attached are 2 patches, one for XGC and one for FOP that should fix and
> improve the handling of at least the temporary files.
> For reference, [1] lists some reasons for implementing the new URI resource
> resolvers.
> [1] http://wiki.apache.org/xmlgraphics-fop/URIResolution
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (FOP-2221) [PATCH] Make overflow messages easier to read and fix wrong/ missing messages
[ https://issues.apache.org/jira/browse/FOP-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633014#comment-13633014 ] Vincent Hennebert edited comment on FOP-2221 at 4/16/13 5:05 PM: - Not there yet I'm afraid. See attached file: error message wrongly indicates that the extent is overflowed. was (Author: vhennebert): Error message wrongly indicates that the extent is overflowed. > [PATCH] Make overflow messages easier to read and fix wrong/ missing messages > - > > Key: FOP-2221 > URL: https://issues.apache.org/jira/browse/FOP-2221 > Project: Fop > Issue Type: Bug >Reporter: simon steiner > Fix For: trunk > > Attachments: overflow-message.fo, overflowsmessage2.patch, > overflowsmessage5.patch > > > Users find it difficult to read over flow messages, patch shows element name > and easier to read message. -- 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-2221) [PATCH] Make overflow messages easier to read and fix wrong/ missing messages
[ https://issues.apache.org/jira/browse/FOP-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert updated FOP-2221: --- Attachment: overflow-message.fo Error message wrongly indicates that the extent is overflowed. > [PATCH] Make overflow messages easier to read and fix wrong/ missing messages > - > > Key: FOP-2221 > URL: https://issues.apache.org/jira/browse/FOP-2221 > Project: Fop > Issue Type: Bug >Reporter: simon steiner > Fix For: trunk > > Attachments: overflow-message.fo, overflowsmessage2.patch, > overflowsmessage5.patch > > > Users find it difficult to read over flow messages, patch shows element name > and easier to read message. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FOP-2234) NPE when rendering a document with markers and accessibility is enabled
[ https://issues.apache.org/jira/browse/FOP-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert resolved FOP-2234. Resolution: Fixed Fixed in rev. 1465599: http://svn.apache.org/r1465599 > NPE when rendering a document with markers and accessibility is enabled > --- > > Key: FOP-2234 > URL: https://issues.apache.org/jira/browse/FOP-2234 > Project: Fop > Issue Type: Bug >Reporter: Vincent Hennebert >Assignee: Vincent Hennebert > Attachments: markers.fo > > > See attached file. The accessibility code doesn't handle markers. -- 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-2234) NPE when rendering a document with markers and accessibility is enabled
[ https://issues.apache.org/jira/browse/FOP-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert updated FOP-2234: --- Attachment: markers.fo > NPE when rendering a document with markers and accessibility is enabled > --- > > Key: FOP-2234 > URL: https://issues.apache.org/jira/browse/FOP-2234 > Project: Fop > Issue Type: Bug >Reporter: Vincent Hennebert >Assignee: Vincent Hennebert > Attachments: markers.fo > > > See attached file. The accessibility code doesn't handle markers. -- 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-2234) NPE when rendering a document with markers and accessibility is enabled
Vincent Hennebert created FOP-2234: -- Summary: NPE when rendering a document with markers and accessibility is enabled Key: FOP-2234 URL: https://issues.apache.org/jira/browse/FOP-2234 Project: Fop Issue Type: Bug Reporter: Vincent Hennebert Assignee: Vincent Hennebert See attached file. The accessibility code doesn't handle markers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FOP-2231) typo
[ https://issues.apache.org/jira/browse/FOP-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert resolved FOP-2231. Resolution: Invalid FOP is to be pronounced as a word. See here for more details: http://comments.gmane.org/gmane.text.xml.fop.user/27365 Thanks for your attention to detail though. > typo > > > Key: FOP-2231 > URL: https://issues.apache.org/jira/browse/FOP-2231 > Project: Fop > Issue Type: Bug > Components: documentation >Affects Versions: 1.1 >Reporter: Sebul > Labels: documentation > > http://xmlgraphics.apache.org/fop/1.1/anttask.html > To call FOP tasks within Ant, first add a FOP task definition to your Ant > build file. One method of defining the task is as follows: > a FOP ? an FOP -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FOP-2226) Image resources are not closed when rendering into the Intermediate Format
[ https://issues.apache.org/jira/browse/FOP-2226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert resolved FOP-2226. Resolution: Fixed Fixed in rev. 1458382: http://svn.apache.org/r1458382 > Image resources are not closed when rendering into the Intermediate Format > -- > > Key: FOP-2226 > URL: https://issues.apache.org/jira/browse/FOP-2226 > Project: Fop > Issue Type: Bug >Reporter: Vincent Hennebert > > When rendering a file containing an external-graphic into the IF, the > resources associated to the image are not closed, leading to a leak of file > descriptors. -- 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-2226) Image resources are not closed when rendering into the Intermediate Format
Vincent Hennebert created FOP-2226: -- Summary: Image resources are not closed when rendering into the Intermediate Format Key: FOP-2226 URL: https://issues.apache.org/jira/browse/FOP-2226 Project: Fop Issue Type: Bug Reporter: Vincent Hennebert When rendering a file containing an external-graphic into the IF, the resources associated to the image are not closed, leading to a leak of file descriptors. -- 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-2213) Kerning is no longer applied
[
https://issues.apache.org/jira/browse/FOP-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13581630#comment-13581630
]
Vincent Hennebert commented on FOP-2213:
If a font provides a kern table but no 'kern' feature in the GPOS table, then
the kern table should be used as a fallback, as indicated at
http://www.microsoft.com/typography/otspec/recom.htm:
"When a kern table and GPOS table are both present in a font, and an OFF layout
engine is requested to apply kerning to a run of text of a particular script
and language system: (a) If the number of kern feature lookups in the resolved
language system in the GPOS table is zero, then the kern table should be
applied, followed by any remaining GPOS features requested."
Also, the original font I used was DejaVu Sans [1], that does have a 'kern'
feature in its GPOS table. But because FOP finds no match for the script
('latn') and language ('dflt') that it computes from the FO file, it doesn't
apply it. Actually, it will apply it only if I specify one of the languages
listed under the 'latn' table, for example, 'ROM' for Romanian. Except that the
'language' XSL-FO property does not accept an OpenType language system tag, but
a language tag that conforms to ISO 639-1 (2-letter tag) or ISO 639-2 (3-letter
tag). And the ISO 639-2 tag for Romanian is 'ron' or 'rum', not 'ROM'. So it
seems that the code is lacking the lookup tables that will match an ISO 639
country tag to an OpenType language system tag. Also, IIUC a script table may
reference a default language system that should be used if no language is
specified, or if the particular language is not listed.
[1] http://dejavu-fonts.org/wiki/Main_Page
> Kerning is no longer applied
>
>
> Key: FOP-2213
> URL: https://issues.apache.org/jira/browse/FOP-2213
> Project: Fop
> Issue Type: Bug
> Components: fonts
>Affects Versions: 1.1, trunk
>Reporter: Vincent Hennebert
> Attachments: fop.xconf, kerning_1.0.pdf, kerning_1.1.pdf, kerning.fo,
> kerning-v2_1.1-cs.pdf, kerning-v2_1.1-nocs.pdf, kerning-v2.fo
>
>
> See attached example. With FOP 1.0 the dot can be seen 'inside' the Y glyph
> as expected, while it's not the case with FOP 1.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] [Updated] (FOP-2213) Kerning is no longer applied
[ https://issues.apache.org/jira/browse/FOP-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert updated FOP-2213: --- Attachment: kerning_1.1.pdf kerning_1.0.pdf fop.xconf kerning.fo Sample FO file, fop.xconf (referring to the DejaVu LGC Serif font available in test/resources/fonts/ttf). Correct output produced by FOP 1.0. Incorrect output produced by FOP 1.1. > Kerning is no longer applied > > > Key: FOP-2213 > URL: https://issues.apache.org/jira/browse/FOP-2213 > Project: Fop > Issue Type: Bug > Components: fonts >Affects Versions: 1.1, trunk >Reporter: Vincent Hennebert > Attachments: fop.xconf, kerning_1.0.pdf, kerning_1.1.pdf, kerning.fo > > > See attached example. With FOP 1.0 the dot can be seen 'inside' the Y glyph > as expected, while it's not the case with FOP 1.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] [Created] (FOP-2213) Kerning is no longer applied
Vincent Hennebert created FOP-2213: -- Summary: Kerning is no longer applied Key: FOP-2213 URL: https://issues.apache.org/jira/browse/FOP-2213 Project: Fop Issue Type: Bug Components: fonts Affects Versions: 1.1, trunk Reporter: Vincent Hennebert See attached example. With FOP 1.0 the dot can be seen 'inside' the Y glyph as expected, while it's not the case with FOP 1.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] [Created] (FOP-2212) o.a.f.fonts.Font.getKernValue should take glyph indices and not characters as parameters
Vincent Hennebert created FOP-2212: -- Summary: 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] [Commented] (FOP-2211) [PATCH] Fix & improve the handling of temporary files using the new URI resource resolvers
[
https://issues.apache.org/jira/browse/FOP-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13577008#comment-13577008
]
Vincent Hennebert commented on FOP-2211:
Hi Alexios,
thanks for your patches. It is true that the current situation is less than
optimal. Maybe temporary resources shouldn't be handled through URIs at all.
However, do we always want to store them in a temp file? Referring to the email
thread you mention above, I think Peter has a point in saying that we may want
to just store them in memory, and reduce the I/O load on the server. Shouldn't
we leave that configurable?
As to the patches: I'm not sure we want to add a delete method to the
ResourceResolver interface. That method applies to temporary resources only and
the scope of that interface is broader than that. I'd rather have that method
on some sub-class implementing that interface.
That said, there seems to be a discrepancy in the code: if I take
PSDocumentHandler as an example, there is a TempResourceURIGenerator that is
used to create tmp URIs, that are then passed on to the userAgent's
ResourceResolver, but nothing indicates that that ResourceResolver can handle
tmp URIs. In fact, that may well not be the case if the user configured the
FopFactory with a custom ResourceResolver.
In light of this, it's probably best to remove the tmp URI facility altogether
and switch back to the createTempFile method for now. I guess we can always
think about a RAM version of temp files later on, if the OS' own caching
facility proves insufficient.
What do people think?
Vincent
> [PATCH] Fix & improve the handling of temporary files using the new URI
> resource resolvers
> --
>
> Key: FOP-2211
> URL: https://issues.apache.org/jira/browse/FOP-2211
> Project: Fop
> Issue Type: Bug
> Components: general
>Affects Versions: trunk
>Reporter: Alexis Giotis
> Fix For: trunk
>
> Attachments: fop.patch, xgc.patch
>
>
> As written in http://markmail.org/message/zelumstxxsdyvkcz , after the merge
> of the Temp_URI_Resolution branch (Sept 2012), the actual pattern of using
> temp files has changed from:
> {code}
> File tmpFile = File.createTempFile();
> // Write and read from the file
> tmpFile.delete();
> {code}
> to:
> {code}
> File tmpFile = new File(System.getProperty("java.io.tmpdir"),
> counterStartingFrom1AsString);
> tmpFile.deleteOnExit();
> // Write and read from the file
> {code}
> This is fine when FOP is executed from the command line (which I guess this
> is how most people use it) but it introduces a number of bad side effects for
> long running processes that use FOP embedded.
>
> 1. Different FOP processes can't be executed in parallel on the same system
> because creating the same temp file fails.
> 2. If the JVM is not normally terminated, the temp files are never deleted
> and the next invocation of the JVM fails to run.
> 3. deleteOnExit() keeps for the life of the JVM an unknown number of temp
> files both on disk and a reference in memory.
> There should not be a need to implement a custom resource resolver when using
> FOP embedded in order to fix those issues. The default implementation should
> work at least as good as it worked in FOP 1.1 or earlier.
> Attached are 2 patches, one for XGC and one for FOP that should fix and
> improve the handling of at least the temporary files.
> For reference, [1] lists some reasons for implementing the new URI resource
> resolvers.
> [1] http://wiki.apache.org/xmlgraphics-fop/URIResolution
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FOP-2148) page-position="only" in conditional-page-master-reference does not work
[ https://issues.apache.org/jira/browse/FOP-2148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert resolved FOP-2148. Resolution: Fixed Fix Version/s: trunk Thanks for your bug report. Support for page-position="only" had actually been left unfinished. The issue has been resolved in rev. 1444217: http://svn.apache.org/r1444217 > page-position="only" in conditional-page-master-reference does not work > --- > > Key: FOP-2148 > URL: https://issues.apache.org/jira/browse/FOP-2148 > Project: Fop > Issue Type: Bug > Components: page-master/layout >Affects Versions: trunk > Environment: Operating System: > Platform: PC >Reporter: ffimbel > Fix For: trunk > > Attachments: lastpage.fo, lastpage.fo.pdf, onlypage.fo, > onlypage.fo.pdf > > > Using the attribute page-position="only" in a > conditional-page-master-reference in order to produce a different page header > if the document has only one page does not work. > I get the header for multiple page even if I only have one page in the final > output document. > > > page-position="only" /> > > > > If I change the attribute to last, it works fine. > > > page-position="last" /> > > > > I attached fo and pdf to reproduce the issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FOP-1719) [PATCH] fop hangs, 100% cpu usage while rendering pdf
[ https://issues.apache.org/jira/browse/FOP-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert resolved FOP-1719. Resolution: Fixed Fixed in rev. 1440094: http://svn.apache.org/viewvc?rev=1440094&view=rev > [PATCH] fop hangs, 100% cpu usage while rendering pdf > - > > Key: FOP-1719 > URL: https://issues.apache.org/jira/browse/FOP-1719 > Project: Fop > Issue Type: Bug > Components: page-master/layout >Affects Versions: 0.95 > Environment: Operating System: Linux > Platform: PC >Reporter: Karel Vervaeke >Assignee: fop-dev > Attachments: 48063-minimal-testcase.xml, b48063.patch, fail.fo, > fail.xml, footnote_footnote-only-final-page_multiple_whole.xml, > fop-footnote.patch, stack1.txt, success.xml > > > executing fop from command line: > fop success.xml -pdf success.pdf > fop fail.xml -pdf fail.pdf > success.xml and fail.xml are similar, but rendering the latter seems to hang > fop. > I have not debugged it, but see attached stack dump. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FOP-1719) [PATCH] fop hangs, 100% cpu usage while rendering pdf
[ https://issues.apache.org/jira/browse/FOP-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Hennebert resolved FOP-1719. Resolution: Fixed Fixed in rev. 1440094: http://svn.apache.org/viewvc?rev=1440094&view=rev > [PATCH] fop hangs, 100% cpu usage while rendering pdf > - > > Key: FOP-1719 > URL: https://issues.apache.org/jira/browse/FOP-1719 > Project: Fop > Issue Type: Bug > Components: page-master/layout >Affects Versions: 0.95 > Environment: Operating System: Linux > Platform: PC >Reporter: Karel Vervaeke >Assignee: fop-dev > Attachments: 48063-minimal-testcase.xml, b48063.patch, fail.fo, > fail.xml, footnote_footnote-only-final-page_multiple_whole.xml, > fop-footnote.patch, stack1.txt, success.xml > > > executing fop from command line: > fop success.xml -pdf success.pdf > fop fail.xml -pdf fail.pdf > success.xml and fail.xml are similar, but rendering the latter seems to hang > fop. > I have not debugged it, but see attached stack dump. -- 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
