buildbot failure in ASF Buildbot on fop-trunk
The Buildbot has detected a new failure on builder fop-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/fop-trunk/builds/330 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: orcus_ubuntu Build Reason: The Nightly scheduler named 'fopNightly' triggered this build Build Source Stamp: [branch xmlgraphics/fop/trunk] HEAD Blamelist: BUILD FAILED: failed Sincerely, -The Buildbot
[jira] [Updated] (FOP-2478) Incorrect position of block-container with fixed absolute-position
[ https://issues.apache.org/jira/browse/FOP-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle updated FOP-2478: - Affects Version/s: 2.0 > Incorrect position of block-container with fixed absolute-position > -- > > Key: FOP-2478 > URL: https://issues.apache.org/jira/browse/FOP-2478 > Project: FOP > Issue Type: Bug >Affects Versions: 1.1, trunk, 2.0 >Reporter: Jan Tošovský > Attachments: block-container-fop.pdf, block-container-xep.pdf, > block-container.fo > > > In the attached example there is specified a distance of 180 mm between the > bottom edge of block-container and bottom edge of the page. However, in FOP > output this distance is different, bigger. Like both top and bottom margins > (2x15 mm) would be added to this dimension. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2478) Incorrect position of block-container with fixed absolute-position
[ https://issues.apache.org/jira/browse/FOP-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14575859#comment-14575859 ] Andreas L. Delmelle commented on FOP-2478: -- I am inclined to accept this as a bug. Reading the XSL 1.1 Rec - 7.6.1, absolute positioning is handled via top/bottom/left/right properties, specifying offsets with respect to the nearest ancestor reference area. A bit further down, in the restrictions for paged media, it is stated that the areas generated by absolute-positioned objects become descendants of the page, etc. I would take that to mean that the offsets are with respect to the page-reference-area, not the region-reference-area, which seems to be what FOP is doing. > Incorrect position of block-container with fixed absolute-position > -- > > Key: FOP-2478 > URL: https://issues.apache.org/jira/browse/FOP-2478 > Project: FOP > Issue Type: Bug >Affects Versions: 1.1, trunk, 2.0 >Reporter: Jan Tošovský > Attachments: block-container-fop.pdf, block-container-xep.pdf, > block-container.fo > > > In the attached example there is specified a distance of 180 mm between the > bottom edge of block-container and bottom edge of the page. However, in FOP > output this distance is different, bigger. Like both top and bottom margins > (2x15 mm) would be added to this dimension. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2469) [PATCH] auto table layout
[ https://issues.apache.org/jira/browse/FOP-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14575949#comment-14575949 ] Andreas L. Delmelle commented on FOP-2469: -- Investigating a bit further the creation and usage of the LayoutContext, I am beginning to think that all usages of LC.newInstance() are actually candidates for a switch to copyOf() or offspringOf(). The former would copy the whole parent context, all flags and settings included, which may be undesirable in some cases, but is likely to be what one would expect from a child context anyway. The latter currently copies only one single flag, but could easily be extended to serve other purposes as well. At least, it seems it was intended to be an in-between of newInstance() and copyOf(). The explicit LC init calls (copyPendingMarks(), setRefIPD()...) in the various LMs still remain, but would then override the inherited settings. The settings that are not explicitly set or unset by the LM can then be assumed to be propagated, which is exactly the behaviour we are looking for. > [PATCH] auto table layout > - > > Key: FOP-2469 > URL: https://issues.apache.org/jira/browse/FOP-2469 > Project: FOP > Issue Type: Bug > Components: layout/unqualified >Affects Versions: trunk > Environment: Windows 7, JDK 7 >Reporter: Gregor Berg >Assignee: Andreas L. Delmelle > Fix For: trunk > > Attachments: 2015-05-13-auto-table-layout.patch, > 2015-05-27-LM-to-LC-refactoring.patch, FOP2469-auto-table-layout.xml > > > Hi, > this is a patch which enables table-layout=auto. It is quite robust, it can > not only handle linebreaks and pagebreaks, but it also copes with auto tables > in fixed tables in auto tables. > Essentially, it is the patch of issue FOP-2450 adapted to the trunk version > of FOP. > Best regards, > Gregor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FOP-2483) [PATCH] Markers don't work on page added by break-before=odd/even-page
Matthias Reischenbacher created FOP-2483: Summary: [PATCH] Markers don't work on page added by break-before=odd/even-page Key: FOP-2483 URL: https://issues.apache.org/jira/browse/FOP-2483 Project: FOP Issue Type: Bug Components: layout/page Reporter: Matthias Reischenbacher If a page is added at the beginning of a page-sequence by a break-before=odd/even-even page property no markers are generated. My fix consists of adding an auxiliary box before a odd/even page-break. It relies on FOP-2060 being fixed differently, because the auxiliary box is removed otherwise. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
