Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
Well, Ivy has one fundamental problem in common with Maven that many regard as a great feature: the repository. Numerous times, I couldn't get a Maven build to complete successfully because some artifact was temporarily or permanently unavailable. Introducing an external repository immediately adds a new dependency in form of the repository to the build which is one more point of failure. And how many times did a Maven/Ivy build download half the Internet just to build a small project? For a private project I started out using Ant+Ivy but I'm in the process of dropping the Ivy part again. And I've had the repository hand-maintained in a project-local SVN subdirectory. My Eclipse's Maven and Ivy plug-ins are long uninstalled because of the trouble they caused. Repositories are probably ok in a corporate environment where you can run over to the admin to fix the server. For open source projects, my opinion and experience is that a repository only adds head-aches for some users. Another problem of an external repository is the lack of license management. ASF projects have clear requirements what kinds of dependencies are allowed. If you can't control transitive dependencies based on a license policy you're bound to run into a problem there. I know at least a couple of ASF projects which didn't notice a license problem by themselves and had to be pointed to it. I can check out (or extract) FOP and build at least a basic version locally with no outside connection. I like that and would like it to stay that way. On 07.09.2010 04:33:02 Craig Ringer wrote: > On 09/07/2010 04:25 AM, Glenn Adams wrote: > > Having gone through the process of creating this working maven build > > configuration, it seems that the potential benefits of its use include: > > > > * dependency management of the use of external artifacts, which is > > not managed by ant, and causes us to include external dependencies > > as part of the source (and binary) release, as well as maintain > > them in the repository; > > FWIW, you can also achieve that with Apache Ivy, which uses the Maven > repos to obtain and manage dependencies, but doesn't require the use of > Maven for builds. > >http://ant.apache.org/ivy/ > > That said, personally I'm reasonably fond of Maven, though I do > sometimes find the maze of plugins and options difficult to deal with > and find managing its configuration challenging. I do really like the > consistency and standardisation it brings to builds - if it's a Maven > project, you know how to build and use it, you can figure out build > issues immediately, you already know how the sources are structured, etc > etc etc. > > I've come from the C/C++ world of autotools (autoconf/automake/libtool), > CMake, and other nightmare build systems from hell ... so Maven is a > real breath of fresh air - despite its flaws. > > > In any case, I view this patch as being experimental, and am willing to > > maintain it. If after some time elapses I am the only user of it, then > > it could be removed. However, at present, there seems few negatives in > > commit it, particularly since it does not touch any other parts of the > > hierarchy. > > It'll also make it easier to maintain a Maven snapshot repository, which > should improve user testing in real-world use of embedded fop > significantly. I use in-progress code a *lot* more when there's a Maven > snapshot repo availible for it, so I don't have to track svn and > manually update the built jars periodically. > > If you're interested in running a snapshot repo, Sonatype Nexus may be > worth looking into. > > -- > Craig Ringer Jeremias Maerki
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
Craig, Thanks for the additional pointers. This was my first time to use maven to be honest. Since it is an Apache tool, I thought that perhaps using it would help me integrate better with common Apache tools. I did had to struggle a bit with some of the configuration ... *and* consult the source code of some of the plugins to figure out what was what. In the end, after more than a few times using the -X option, I learned the right tricks and got it working. Even with all that, I find it generally cleaner due to its built-in paradigms (lifecycles), which allow for better shared understanding of the process, and something one doesn't get from tool sets that don't formalize common conventions. Since you obviously have more experience with maven than I, I would appreciate any constructive comments you may have about the way I have gone about configuring it. Regards, Glenn On Tue, Sep 7, 2010 at 10:33 AM, Craig Ringer wrote: > On 09/07/2010 04:25 AM, Glenn Adams wrote: > >> Having gone through the process of creating this working maven build >> configuration, it seems that the potential benefits of its use include: >> >>* dependency management of the use of external artifacts, which is >> not managed by ant, and causes us to include external dependencies >> as part of the source (and binary) release, as well as maintain >> them in the repository; >> > > FWIW, you can also achieve that with Apache Ivy, which uses the Maven repos > to obtain and manage dependencies, but doesn't require the use of Maven for > builds. > > http://ant.apache.org/ivy/ > > That said, personally I'm reasonably fond of Maven, though I do sometimes > find the maze of plugins and options difficult to deal with and find > managing its configuration challenging. I do really like the consistency and > standardisation it brings to builds - if it's a Maven project, you know how > to build and use it, you can figure out build issues immediately, you > already know how the sources are structured, etc etc etc. > > I've come from the C/C++ world of autotools (autoconf/automake/libtool), > CMake, and other nightmare build systems from hell ... so Maven is a real > breath of fresh air - despite its flaws. > > > In any case, I view this patch as being experimental, and am willing to >> maintain it. If after some time elapses I am the only user of it, then >> it could be removed. However, at present, there seems few negatives in >> commit it, particularly since it does not touch any other parts of the >> hierarchy. >> > > It'll also make it easier to maintain a Maven snapshot repository, which > should improve user testing in real-world use of embedded fop significantly. > I use in-progress code a *lot* more when there's a Maven snapshot repo > availible for it, so I don't have to track svn and manually update the built > jars periodically. > > If you're interested in running a snapshot repo, Sonatype Nexus may be > worth looking into. > > -- > Craig Ringer >
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
On 09/07/2010 04:25 AM, Glenn Adams wrote: Having gone through the process of creating this working maven build configuration, it seems that the potential benefits of its use include: * dependency management of the use of external artifacts, which is not managed by ant, and causes us to include external dependencies as part of the source (and binary) release, as well as maintain them in the repository; FWIW, you can also achieve that with Apache Ivy, which uses the Maven repos to obtain and manage dependencies, but doesn't require the use of Maven for builds. http://ant.apache.org/ivy/ That said, personally I'm reasonably fond of Maven, though I do sometimes find the maze of plugins and options difficult to deal with and find managing its configuration challenging. I do really like the consistency and standardisation it brings to builds - if it's a Maven project, you know how to build and use it, you can figure out build issues immediately, you already know how the sources are structured, etc etc etc. I've come from the C/C++ world of autotools (autoconf/automake/libtool), CMake, and other nightmare build systems from hell ... so Maven is a real breath of fresh air - despite its flaws. In any case, I view this patch as being experimental, and am willing to maintain it. If after some time elapses I am the only user of it, then it could be removed. However, at present, there seems few negatives in commit it, particularly since it does not touch any other parts of the hierarchy. It'll also make it easier to maintain a Maven snapshot repository, which should improve user testing in real-world use of embedded fop significantly. I use in-progress code a *lot* more when there's a Maven snapshot repo availible for it, so I don't have to track svn and manually update the built jars periodically. If you're interested in running a snapshot repo, Sonatype Nexus may be worth looking into. -- Craig Ringer
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
Glenn,
FBOFW, it's clear that a number of core contributors (including the PMC
chair!) in fop-land are exceedingly Maven-averse. It's not that rare of a
viewpoint in the FOSS community.
All that dependency stuff can be done by borrowing maven dependencies in
ant, either via the maven ant tools or via ivy. For CI, in my opinion you're
completely correct, but you and I are completely outnumbered.
In my experience, things that start out needing a distressingly intricate
maven build with lots of ant call-outs can often be gradually simplified,
but I haven't looked at the fop build process in any detail.
Mayhap the fop community is OK with a parallel maven build system so long as
someone exists to maintain it.
I personally have a love-hate relationship with Maven -- when the build
process is fundamentally 'plain old Java', I think it's wonderful. When
there is a lot to do that isn't covered by maven plugins, and you wind up
with a lot of callouts to ant, I'm not so sure it's the bees knees.
--benson
On Mon, Sep 6, 2010 at 4:25 PM, Glenn Adams wrote:
> Having gone through the process of creating this working maven build
> configuration, it seems that the potential benefits of its use include:
>
>- dependency management of the use of external artifacts, which is not
>managed by ant, and causes us to include external dependencies as part of
>the source (and binary) release, as well as maintain them in the
> repository;
>- automated report generation
>- improved continuous integration management tools
>
> Although I had to puzzle through some aspects of maven configuration, I
> found it was sufficiently flexible, particularly in combination with the
> antrun plugin, to produce good results. I don't particularly see the use of
> maven as a maven vs ant issue. They both have their uses, and given the
> antrun plugin, one can accomplish the necessary customization of maven goals
> using ant, as opposed to writing custom, one-off plugins.
>
> In any case, I view this patch as being experimental, and am willing to
> maintain it. If after some time elapses I am the only user of it, then it
> could be removed. However, at present, there seems few negatives in commit
> it, particularly since it does not touch any other parts of the hierarchy.
>
> G.
>
> P.S. I did not try a WIN (cygwin) build. For symlinks, I used the ant
> task, both to create and delete. If that task is implemented on
> WIN, then I would expect it to work.
>
> On Mon, Sep 6, 2010 at 10:17 PM, Jeremias Maerki
> wrote:
>
>> Personally, I'd not be happy if we added a parallel build system. Given
>> that so much Ant code is necessary to handle some details shows how
>> inflexible Maven is. I haven't checked how much Ant code is duplicated
>> between the root-level build.xml and the files in the "maven"
>> subdirectory. IMO, this would be a maintenance head-ache since the two
>> always have to be kept in sync. If build.xml would be split into
>> re-usable sub-file (Ant is quite flexible), some duplication could be
>> avoided maybe. But that would still impose some level of redundancy. At
>> any rate, you probably can't count me in to help maintain the Maven side
>> due to my very bad experiences with it.
>>
>> Also, I'm not sure if the task will work as expected on
>> Windows.
>>
>> On 04.09.2010 12:41:14 bugzilla wrote:
>> > https://issues.apache.org/bugzilla/show_bug.cgi?id=49881
>> >
>> >Summary: [PATCH] add maven build support
>> >Product: Fop
>> >Version: 1.1dev
>> > Platform: All
>> > OS/Version: All
>> > Status: NEW
>> > Severity: enhancement
>> > Priority: P2
>> > Component: general
>> > AssignedTo: fop-dev@xmlgraphics.apache.org
>> > ReportedBy: gl...@skynav.com
>> >
>> >
>> > This patch adds support for building with maven 2.2.X or later. I have
>> tested
>> > it with the current version (2.2.1) on a JDK 1.6 platform.
>> >
>> > There are no direct dependencies on JDK 1.4 or 1.5 features, but I have
>> not
>> > verified yet.
>> >
>> > The patch creates a new top-level directory 'maven' in the FOP trunk
>> directory.
>> > See the file README-MAVEN.txt there for configuration and usage
>> information.
>> >
>> > Once downloaded to your home directory, this patch may be applied as
>> follows:
>> >
>> > cd ${FOP}/trunk
>> > gzcat ~/patch-maven-build.diff.gz | patch -p0
>> > svn add maven
>> >
>> > Note that only the core fop.jar artifact is built at this time. In
>> particular,
>> > the fop-transcoder and fop-sandbox jar artifacts are not yet built.
>> >
>> > This patch has been verified against repository version 992575.
>> >
>> > Regards,
>> > Glenn
>> >
>> > --
>> > Configure bugmail:
>> https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
>> > --- You are receiving this mail because: ---
>> > You are the assignee for the bug.
>>
>>
>>
>>
>> Jeremias Maerki
>>
>>
>
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
Having gone through the process of creating this working maven build
configuration, it seems that the potential benefits of its use include:
- dependency management of the use of external artifacts, which is not
managed by ant, and causes us to include external dependencies as part of
the source (and binary) release, as well as maintain them in the repository;
- automated report generation
- improved continuous integration management tools
Although I had to puzzle through some aspects of maven configuration, I
found it was sufficiently flexible, particularly in combination with the
antrun plugin, to produce good results. I don't particularly see the use of
maven as a maven vs ant issue. They both have their uses, and given the
antrun plugin, one can accomplish the necessary customization of maven goals
using ant, as opposed to writing custom, one-off plugins.
In any case, I view this patch as being experimental, and am willing to
maintain it. If after some time elapses I am the only user of it, then it
could be removed. However, at present, there seems few negatives in commit
it, particularly since it does not touch any other parts of the hierarchy.
G.
P.S. I did not try a WIN (cygwin) build. For symlinks, I used the ant
task, both to create and delete. If that task is implemented on
WIN, then I would expect it to work.
On Mon, Sep 6, 2010 at 10:17 PM, Jeremias Maerki wrote:
> Personally, I'd not be happy if we added a parallel build system. Given
> that so much Ant code is necessary to handle some details shows how
> inflexible Maven is. I haven't checked how much Ant code is duplicated
> between the root-level build.xml and the files in the "maven"
> subdirectory. IMO, this would be a maintenance head-ache since the two
> always have to be kept in sync. If build.xml would be split into
> re-usable sub-file (Ant is quite flexible), some duplication could be
> avoided maybe. But that would still impose some level of redundancy. At
> any rate, you probably can't count me in to help maintain the Maven side
> due to my very bad experiences with it.
>
> Also, I'm not sure if the task will work as expected on
> Windows.
>
> On 04.09.2010 12:41:14 bugzilla wrote:
> > https://issues.apache.org/bugzilla/show_bug.cgi?id=49881
> >
> >Summary: [PATCH] add maven build support
> >Product: Fop
> >Version: 1.1dev
> > Platform: All
> > OS/Version: All
> > Status: NEW
> > Severity: enhancement
> > Priority: P2
> > Component: general
> > AssignedTo: fop-dev@xmlgraphics.apache.org
> > ReportedBy: gl...@skynav.com
> >
> >
> > This patch adds support for building with maven 2.2.X or later. I have
> tested
> > it with the current version (2.2.1) on a JDK 1.6 platform.
> >
> > There are no direct dependencies on JDK 1.4 or 1.5 features, but I have
> not
> > verified yet.
> >
> > The patch creates a new top-level directory 'maven' in the FOP trunk
> directory.
> > See the file README-MAVEN.txt there for configuration and usage
> information.
> >
> > Once downloaded to your home directory, this patch may be applied as
> follows:
> >
> > cd ${FOP}/trunk
> > gzcat ~/patch-maven-build.diff.gz | patch -p0
> > svn add maven
> >
> > Note that only the core fop.jar artifact is built at this time. In
> particular,
> > the fop-transcoder and fop-sandbox jar artifacts are not yet built.
> >
> > This patch has been verified against repository version 992575.
> >
> > Regards,
> > Glenn
> >
> > --
> > Configure bugmail:
> https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
> > --- You are receiving this mail because: ---
> > You are the assignee for the bug.
>
>
>
>
> Jeremias Maerki
>
>
relative-align on lists
Someone asked me how much work it would be to implement relative-align on lists. I wonder if the following approach will work: ListItemLayoutManager first gets the element list for the label, then for the body. Each time a Layout context is passed it. The LineLayoutManager could set the baseline information for the first line as long as no other down-stream layout context has set that information. Then that information could be passed up until the ListItemLayoutManager which could then insert a dummy KnuthBox for a space used for alignment. The ListItemContentLayoutManager could then handle the necessary additional space. Probably something similar for tables. A little awkward but that should work. Is that feasible or does anyone have a better idea? Thanks, Jeremias Maerki
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
I'd generally encourage the use of the ant-to-maven wiring I supplied for
maven publication. Adding the ant maven tools to the standard build (or
using ivy?) would allow very quick consumption of FOP jars by Maven-built
applications, which I guess would be the goal here.
On Mon, Sep 6, 2010 at 10:17 AM, Jeremias Maerki wrote:
> Personally, I'd not be happy if we added a parallel build system. Given
> that so much Ant code is necessary to handle some details shows how
> inflexible Maven is. I haven't checked how much Ant code is duplicated
> between the root-level build.xml and the files in the "maven"
> subdirectory. IMO, this would be a maintenance head-ache since the two
> always have to be kept in sync. If build.xml would be split into
> re-usable sub-file (Ant is quite flexible), some duplication could be
> avoided maybe. But that would still impose some level of redundancy. At
> any rate, you probably can't count me in to help maintain the Maven side
> due to my very bad experiences with it.
>
> Also, I'm not sure if the task will work as expected on
> Windows.
>
> On 04.09.2010 12:41:14 bugzilla wrote:
> > https://issues.apache.org/bugzilla/show_bug.cgi?id=49881
> >
> >Summary: [PATCH] add maven build support
> >Product: Fop
> >Version: 1.1dev
> > Platform: All
> > OS/Version: All
> > Status: NEW
> > Severity: enhancement
> > Priority: P2
> > Component: general
> > AssignedTo: fop-dev@xmlgraphics.apache.org
> > ReportedBy: gl...@skynav.com
> >
> >
> > This patch adds support for building with maven 2.2.X or later. I have
> tested
> > it with the current version (2.2.1) on a JDK 1.6 platform.
> >
> > There are no direct dependencies on JDK 1.4 or 1.5 features, but I have
> not
> > verified yet.
> >
> > The patch creates a new top-level directory 'maven' in the FOP trunk
> directory.
> > See the file README-MAVEN.txt there for configuration and usage
> information.
> >
> > Once downloaded to your home directory, this patch may be applied as
> follows:
> >
> > cd ${FOP}/trunk
> > gzcat ~/patch-maven-build.diff.gz | patch -p0
> > svn add maven
> >
> > Note that only the core fop.jar artifact is built at this time. In
> particular,
> > the fop-transcoder and fop-sandbox jar artifacts are not yet built.
> >
> > This patch has been verified against repository version 992575.
> >
> > Regards,
> > Glenn
> >
> > --
> > Configure bugmail:
> https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
> > --- You are receiving this mail because: ---
> > You are the assignee for the bug.
>
>
>
>
> Jeremias Maerki
>
>
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
Personally, I'd not be happy if we added a parallel build system. Given
that so much Ant code is necessary to handle some details shows how
inflexible Maven is. I haven't checked how much Ant code is duplicated
between the root-level build.xml and the files in the "maven"
subdirectory. IMO, this would be a maintenance head-ache since the two
always have to be kept in sync. If build.xml would be split into
re-usable sub-file (Ant is quite flexible), some duplication could be
avoided maybe. But that would still impose some level of redundancy. At
any rate, you probably can't count me in to help maintain the Maven side
due to my very bad experiences with it.
Also, I'm not sure if the task will work as expected on
Windows.
On 04.09.2010 12:41:14 bugzilla wrote:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=49881
>
>Summary: [PATCH] add maven build support
>Product: Fop
>Version: 1.1dev
> Platform: All
> OS/Version: All
> Status: NEW
> Severity: enhancement
> Priority: P2
> Component: general
> AssignedTo: fop-dev@xmlgraphics.apache.org
> ReportedBy: gl...@skynav.com
>
>
> This patch adds support for building with maven 2.2.X or later. I have tested
> it with the current version (2.2.1) on a JDK 1.6 platform.
>
> There are no direct dependencies on JDK 1.4 or 1.5 features, but I have not
> verified yet.
>
> The patch creates a new top-level directory 'maven' in the FOP trunk
> directory.
> See the file README-MAVEN.txt there for configuration and usage information.
>
> Once downloaded to your home directory, this patch may be applied as follows:
>
> cd ${FOP}/trunk
> gzcat ~/patch-maven-build.diff.gz | patch -p0
> svn add maven
>
> Note that only the core fop.jar artifact is built at this time. In particular,
> the fop-transcoder and fop-sandbox jar artifacts are not yet built.
>
> This patch has been verified against repository version 992575.
>
> Regards,
> Glenn
>
> --
> Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You are the assignee for the bug.
Jeremias Maerki
Re: base 14 font kerning
I've already implemented in my complex scripts work, so it will make it into trunk in due time. However, I think I'll leave the default setting as it is for the time being. Users can explicitly enable it via their config. We can take up the issue of whether to change the default at a future time. G. On Mon, Sep 6, 2010 at 10:07 PM, Jeremias Maerki wrote: > I think that is for historical reasons. When this was implemented (I > think it was me) I guess we didn't want to change the layout behaviour > for existing users. For a long time, kerning for base 14 fonts was not > supported. > > http://svn.apache.org/viewvc?view=revision&revision=389086 > > You're right: this setting doesn't seem to be tied into the > FontManagerConfigurator. It would be great if you added that. > > That said, I'm not sure if enabling that would be so bad. I guess I'm > not opposed to it. > > On 06.09.2010 07:58:41 Glenn Adams wrote: > > Is there a reason that kerning of the base 14 fonts is disabled by > default? > > > > Furthermore, except by programmatic means, there does not seem to be a > way > > to enable it except by using FontManager.setBase14KerningEnabled() or the > > deprecated method FopFactory.setBase14KerningEnabled(). This technique is > > used to enable it during testing in one test case: > > layoutengine/standard-testcases/kerning_1_on.xml, by means of special > code > > in org.apache.fop.layoutengine.TestEnvironment. > > > > However, there appears no way for a user to enable it via non-programmitc > > means. To support this (which I need in testing the new generalized > position > > adjustments for text drawing), I'm adding a base14-kerning element to be > > placed in the top-level fop element in the FOP configuration file, e.g., > > > > > > ... > > true > > ... > > > > > > The rationale for making this a child of the top-level fop element is > that > > the enable/disable state is presently maintained in the singleton > > FontManager instance, which is configured (in FontManagerConfigurator) > from > > other top-level children of the fop element. > > > > For consistency, it my be better to enable base14 kerning by default, > then > > allow a user to disable it using the above mechanism. However, I have not > > made this latter change (yet). > > > > Comments? > > > > G. > > > > > Jeremias Maerki > >
Re: base 14 font kerning
I think that is for historical reasons. When this was implemented (I think it was me) I guess we didn't want to change the layout behaviour for existing users. For a long time, kerning for base 14 fonts was not supported. http://svn.apache.org/viewvc?view=revision&revision=389086 You're right: this setting doesn't seem to be tied into the FontManagerConfigurator. It would be great if you added that. That said, I'm not sure if enabling that would be so bad. I guess I'm not opposed to it. On 06.09.2010 07:58:41 Glenn Adams wrote: > Is there a reason that kerning of the base 14 fonts is disabled by default? > > Furthermore, except by programmatic means, there does not seem to be a way > to enable it except by using FontManager.setBase14KerningEnabled() or the > deprecated method FopFactory.setBase14KerningEnabled(). This technique is > used to enable it during testing in one test case: > layoutengine/standard-testcases/kerning_1_on.xml, by means of special code > in org.apache.fop.layoutengine.TestEnvironment. > > However, there appears no way for a user to enable it via non-programmitc > means. To support this (which I need in testing the new generalized position > adjustments for text drawing), I'm adding a base14-kerning element to be > placed in the top-level fop element in the FOP configuration file, e.g., > > > ... > true > ... > > > The rationale for making this a child of the top-level fop element is that > the enable/disable state is presently maintained in the singleton > FontManager instance, which is configured (in FontManagerConfigurator) from > other top-level children of the fop element. > > For consistency, it my be better to enable base14 kerning by default, then > allow a user to disable it using the above mechanism. However, I have not > made this latter change (yet). > > Comments? > > G. Jeremias Maerki
DO NOT REPLY [Bug 49801] Region-Body Column balancing incorrect if content is table with header
https://issues.apache.org/bugzilla/show_bug.cgi?id=49801 --- Comment #3 from Jeremias Maerki 2010-09-06 09:46:13 EDT --- I've been asked to look closer into this, and after about 10 hours spent brooding over it and consulting the "Digital Typography" book I'm no closer to solving it. I've been able to calculate the demerits which I expected to result in the right break decision (for one case), but the algorithm still chose another breaking point for reasons I just don't understand. The BalancingColumnBreakingAlgorithm class was some kind of hack to begin with which I knew had some short-comings. That is now pretty obvious, and I don't know how to proceed. I have to give up for now since this is simply a bit too high for me. I'll copy my local changes away so if anyone wants to give it a shot, I can provide them. But I'm not sure if they would really help. If anyone can help Adam, please get in touch with him. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 49885] Varying page breaks with multi columned region-body
https://issues.apache.org/bugzilla/show_bug.cgi?id=49885 --- Comment #2 from a.kov...@i-docs.com 2010-09-06 07:03:20 EDT --- Created an attachment (id=25992) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25992) test XSL/FO file -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 49885] Varying page breaks with multi columned region-body
https://issues.apache.org/bugzilla/show_bug.cgi?id=49885 --- Comment #1 from a.kov...@i-docs.com 2010-09-06 07:02:13 EDT --- Created an attachment (id=25991) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25991) test pdf -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 49885] New: Varying page breaks with multi columned region-body
https://issues.apache.org/bugzilla/show_bug.cgi?id=49885 Summary: Varying page breaks with multi columned region-body Product: Fop Version: 1.0 Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: page-master/layout AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: a.kov...@i-docs.com I have a multi columned region-body with a big table on it. The table is spanned over all columns. (fo:block span="all") I also have an odd/even repeatable-page-master-alternatives where odd and even pages have different margins. The table goes over more pages and every second odd and every second even page has a wrong page break. (one page is to short and the next page is to long (out of margin) ) 2 good pages are always followed by 2 wrong pages. If I switch to a single columned region-body the page breaks are correct. Attached is an XSL/FO example with result PDF. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
