DO NOT REPLY [Bug 47145] Using keep-together.within-column and break-after results in missing text
https://issues.apache.org/bugzilla/show_bug.cgi?id=47145
--- Comment #6 from Vincent Hennebert 2009-05-07
02:38:41 PST ---
(In reply to comment #4)
> (In reply to comment #3)
> > The bug is this second penalty that shouldn't be generated in the first
> > place,
> > since breaks win over keeps. There may be an opportunity to fix that in the
> > same time as bug #46905.
>
> Agreed. As I remember from another similar issue I fixed recently in
> FlowLayoutManager, it could turn out to be a very straightforward fix. I'll
> see
> if I can confirm later tonight.
> At some point in getNextKnuthElements(), the parentLM adds a break in between
> the sequences returned by two consecutive childLMs. It's likely to be a simple
> matter of :
>
> if (!ElementListUtils.endsWithForcedBreak(returnedList)) {
> //add in-between break
> }
I think a LayoutManager shouldn't generate a Penalty element for a
break-before/after. That's the job of the enclosing LayoutManager, when its
addInBetweenBreak method is called. It's there that all the information about
break-after on the current childLM, break-before on the next childLM,
keep-with-next/with-previous/together can be collected, and a proper Penalty
element can (optionally) be generated. I say optionally because no element
needs be generated at all if a break-after is set on the last block of a
page-sequence, for example.
That's what I did in tables (see TableContentLM.getKnuthElementsForRowIterator)
and it works pretty well.
Vincent
--
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 47101] table duplication in Region-Before and Region-After
https://issues.apache.org/bugzilla/show_bug.cgi?id=47101 Vincent Hennebert changed: What|Removed |Added Attachment #23547|0 |1 is obsolete|| --- Comment #1 from Vincent Hennebert 2009-05-07 03:39:27 PST --- Created an attachment (id=23623) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=23623) Simplified FO file showing the problem Thank you for your bug report. I attach a simplified FO file that can be used for debugging. Not sure what is the reason for the duplication of the table though. -- 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 47101] Table in marker gets duplicated at each marker retrieval
https://issues.apache.org/bugzilla/show_bug.cgi?id=47101 Vincent Hennebert changed: What|Removed |Added Summary|table duplication in|Table in marker gets |Region-Before and |duplicated at each marker |Region-After|retrieval -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: svn commit: r772672 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/apps/FOURIResolver.java
On Thu, May 07, 2009 at 03:08:30PM -, cbowdi...@apache.org wrote: > Author: cbowditch > Date: Thu May 7 15:08:30 2009 > New Revision: 772672 > > URL: http://svn.apache.org/viewvc?rev=772672&view=rev > Log: > bug fix: allow back slashes for file URLs as they are commonly used in Windows I would not like to call file:///C:\mydirectory\myfile a correct URL. URLs are one format where Windows and Unix users use the same forward slashes. URL is a standard for all OSes alike. Simon -- Simon Pepping home page: http://www.leverkruid.eu
Re: svn commit: r772672 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/apps/FOURIResolver.java
On 07 May 2009, at 21:15, Simon Pepping wrote: On Thu, May 07, 2009 at 03:08:30PM -, cbowdi...@apache.org wrote: Author: cbowditch Date: Thu May 7 15:08:30 2009 New Revision: 772672 URL: http://svn.apache.org/viewvc?rev=772672&view=rev Log: bug fix: allow back slashes for file URLs as they are commonly used in Windows I would not like to call file:///C:\mydirectory\myfile a correct URL. URLs are one format where Windows and Unix users use the same forward slashes. URL is a standard for all OSes alike. I very much agree with that assessment. Browsing through the related RFCs, one notices that the forward slash is a 'reserved' character, while a backslash is considered 'unwise'. The reason is that "gateways and other transport agents are known to sometimes modify such characters, or they are used as delimiters". Following RFC 2396, the URL 'file:///c:\mydirectory\myfile' is not equivalent to 'file:///c:/mydirectory/myfile' from the point of view of URI syntax. Therefore, it is wrong to expect them to yield the same behavior. One could argue that we then also need to allow a colon as separator for the hierarchical parts, to satisfy legacy Mac OS users... :-) Regards Andreas
DO NOT REPLY [Bug 47101] Table in marker gets duplicated at each marker retrieval
https://issues.apache.org/bugzilla/show_bug.cgi?id=47101 --- Comment #2 from Andreas L. Delmelle 2009-05-07 13:25:36 PST --- (In reply to comment #1) > Created an attachment (id=23623) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=23623) [details] > Simplified FO file showing the problem > > Thank you for your bug report. I attach a simplified FO file that can be used > for debugging. Not sure what is the reason for the duplication of the table > though. I did a quick check here, but haven't found out what the exact cause is either. One interesting thing I did notice so far: it is not the table that is duplicated, but the table-cell. On the first page, I get only one call to TableCellLM. On the second page, I get two, made by the same RowGroupLM. The table-body on the second page has its rowGroups set to 2... -- 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 47101] Table in marker gets duplicated at each marker retrieval
https://issues.apache.org/bugzilla/show_bug.cgi?id=47101 --- Comment #3 from Andreas L. Delmelle 2009-05-07 13:33:43 PST --- Most likely cause: when cloning the table-body upon each marker-retrieval, it does not go deep enough. Some member (can't tell yet which one exactly) is copied as a reference, while it should, in fact, be an entirely separate instance. Overriding clone() in the corresponding FONode type (TablePart?) to add specific behavior may just be enough to fix this... -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
