Re: [GSoC] Auto-table layout questions
On 17.08.2006 04:00:30 Patrick Paul wrote: Jeremias Maerki wrote: Patrick, your ICLA hasn't shown up, yet. The last batch of ICLAs was committed 2006-07-31 so if you sent it after that date, it may show up in the next batch which I hope will be soon. It was sent after august first, around the 2nd or 3rd of august. I hope it will show up reel soon. Unfortunately, it hasn't. Jim Jagielski has recorded another batch on Tuesday where your name was still missing. Sounds to me like something went bad with the fax. Shrug. :-( What you can do if you have a scanner, is: Therefore, we are now accepting readable scanned images, sent via Email, but ONLY under the following conditions: 1. The Email MUST be sent to [EMAIL PROTECTED] AND [EMAIL PROTECTED] 2. Once received and verified as readable, the iclas.txt file will be updated with the information. Updating of the iclas.txt file will follow the same procedure as currently implemented: any officer can add an entry but it does not become official until acked and moved to the secretary's section of the file. So, if you put me ([EMAIL PROTECTED]) in the To: list of that mail you're already ok on the ICLA side and we don't have any further delays. I can also start up my fax software and you can send me that fax again and I'll handle the rest. If you want to do that, just contact me over IM. Have you made any progress on your side? Everything working out? I'm getting there... I've implemented a basic auto table layout but I still need to get the whole split done for the InlineElement.getNextKnuthElements. Currently I the element lists are created twice in order to determine the optimal width of each column. I am currently preparing some content to update the wiki page and explain everything... I have to learn to communicate *much* more. Hmm, yeah, that wouldn't hurt. Remember that the GSoC ends next Monday. I'll take a look at your initial draft patch ASAP. Patrick Paul On 07.08.2006 02:58:57 Patrick Paul wrote: Jeremias Maerki wrote: BTW, Patrick, when I checked the ICLA status of you and Vincent I saw that you still don't have an ICLA on file with the ASF. Please sign and send (i.e. fax) one to the ASF secretary: http://www.apache.org/licenses/#clas Thanks. Jeremias Maerki Hi Jeremias, I've been offline most of the time this past week. I have faxed my ICLA a few days ago, so I'm hoping it is on file with the ASF by now. Please let me know if its not. Thank you, Patrick Jeremias Maerki Jeremias Maerki
DO NOT REPLY [Bug 40270] - [PATCH] Make list item EndOfNode() method agile to strict-validation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=40270. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=40270 [EMAIL PROTECTED] changed: What|Removed |Added Summary|Make list item EndOfNode() |[PATCH] Make list item |method agile to strict- |EndOfNode() method agile to |validation |strict-validation --- Additional Comments From [EMAIL PROTECTED] 2006-08-17 07:56 --- Thanks for the patch! -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 40271] - auto table layout -- dirty draft
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=40271. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=40271 --- Additional Comments From [EMAIL PROTECTED] 2006-08-17 08:42 --- Hi Patrick, Just did a quick review of the patch, and one thing that immediately caught my eye, and thus I think needs more explaining (or an alternative solution): You seem to be inventing a whole new property 'column-min-width'. The properties infrastructure is there for support of standard FO properties (and ultimately extension properties). I get the impression it is being misused here to store a variable/value which is only relevant to FOP internally (more specifically: the auto-table layout algorithm) Cheers, Andreas -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 40271] - auto table layout -- dirty draft
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=40271. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=40271 --- Additional Comments From [EMAIL PROTECTED] 2006-08-17 09:21 --- Looking a bit closer, IMO the minimum column-width should be derived from the layout context. Count the number of non-null elements in the Table's column-list (one time process), then divide the refIPD of the layout-context by the number of explicitly defined columns (alt.: the largest number of cells in a row --that is a value that could be determined in the FOTree, before layout begins) Strictly speaking, I think a value of 'proportional-column-width(1)' does not always suffice... How is this expression to be interpreted in case of a table with table-layout=auto, no explicit rows, and a varying number of cells in each row? I guess the editors had good reason to constrain the explicit use of proportional-column-width() to fixed- table-layout. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 40271] - auto table layout -- dirty draft
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=40271. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=40271 --- Additional Comments From [EMAIL PROTECTED] 2006-08-17 10:14 --- Not to be a pain, but just committed a small change to the trunk that logs an error for this. http://svn.apache.org/viewvc?rev=432195view=rev Sorry. Kind of invalidates your patch, I guess. :/ -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 40270] - [PATCH] Make list item EndOfNode() method agile to strict-validation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=40270. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=40270 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2006-08-17 10:24 --- Patch applied with very small modifications. see: http://svn.apache.org/viewvc?rev=432201view=rev Thanks! -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: svn commit: r432201 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/flow/AbstractListItemPart.java
Andreas, when applying a patch it is nice to actually include the name of the person who submitted the patch in the commit message as well as the bugzilla number. That serves two purposes: - It faciliates later investigation in case of IP problems. - It is a way to say thank-you to one of those few people nowadays who actually do submit patches. Since the use of author tags is discouraged this is the only way to attribute a work to someone. We committers already have our names in the revision logs but the contributors haven't. Please update the commit message of revision 432201 to reflect that following the pattern I've always used: Bugzilla #.: commit message Submitted By: name and somewhat spam-protected mail address Thanks. On 17.08.2006 12:25:27 adelmelle wrote: Author: adelmelle Date: Thu Aug 17 03:25:27 2006 New Revision: 432201 URL: http://svn.apache.org/viewvc?rev=432201view=rev Log: Added relaxed validation for empty list-item-* (as produced by the buggy Microsoft Word2FO stylesheet) Modified: xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/flow/AbstractListItemPart.java snip/ Jeremias Maerki
Re: svn commit: r432201 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/flow/AbstractListItemPart.java
On Aug 17, 2006, at 14:02, Jeremias Maerki wrote: snip / Please update the commit message of revision 432201 to reflect that following the pattern I've always used: Bugzilla #.: commit message Submitted By: name and somewhat spam-protected mail address Sorry. Will keep an eye on it for later commits. For now, I saw I forgot to commit status.xml anyway. Credits to Gary on our changes page. Later, Andreas
DO NOT REPLY [Bug 40271] - auto table layout -- dirty draft
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=40271. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=40271 --- Additional Comments From [EMAIL PROTECTED] 2006-08-17 16:12 --- You are right. I will have to find an alternative solution to this. I was only using it to store the minimum width of a column. Thank you, Patrick -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 40271] - auto table layout -- dirty draft
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=40271. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=40271 --- Additional Comments From [EMAIL PROTECTED] 2006-08-17 17:25 --- (In reply to comment #6) snip / I am not sure I follow you. When you talk about the column-list, is that the ColumnSetup columns in TableLayoutManager ? Not entirely. ColumnSetup will currently only contain the actual column count in case you have explicitly defined columns. There's a method ColumnSetup.createFromFirstRow(), but this maps to return the table's default column (= FOP internal). So, in case you have a table without explicit columns, the maximum column-count would already be different. We could quite easily keep track of the maximum number of cells in a row as the FOTree is built, so that, by the time layout starts, the layoutmanager could already know what the maximum column- count will be for the whole table without having to iterate over all the rows. HTH! Andreas -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 40271] - auto table layout -- dirty draft
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=40271. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=40271 --- Additional Comments From [EMAIL PROTECTED] 2006-08-17 17:59 --- (In reply to comment #7) We could quite easily keep track of the maximum number of cells in a row as the FOTree is built, so that, by the time layout starts, the layoutmanager could already know what the maximum column- count will be for the whole table without having to iterate over all the rows. To expand a bit more upon this (could also be of use for fixed-layout): Ideally, ColumnSetup should be made to deal with both implicit and explicit columns completely, so the TableContentLM does not need to sort this stuff out. The columns in ColumnSetup should be the table- grid columns. I did wonder whether this should be viewed on a per-page basis...? I mean: say you have a table with five cells per row (100+ rows), except for the last row which has six. Do we layout the whole table as if there were six columns, or only the last page? Cheers Andreas -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 40271] - auto table layout -- dirty draft
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=40271. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=40271 --- Additional Comments From [EMAIL PROTECTED] 2006-08-17 18:19 --- (In reply to comment #8) I did wonder whether this should be viewed on a per-page basis...? I mean: say you have a table with five cells per row (100+ rows), except for the last row which has six. Do we layout the whole table as if there were six columns, or only the last page? Look at it this way: You'd expect an fo:block to occupy the whole width on both pages if that block is broken between two pages and the first is a landscape page and the second is a portrait page. Now transfer this to fo:table where you might specify columns entirely using proportional-column-width() (or even using auto-table layout). Especially when specifying the table width using width=100% you define that the area generated by the FO occupies 100% of the width of the containing area. So, especially in the light of the upcoming changes for changing available IPD, there's a possibility that you'll have to recalculate the column setup for every page. Not that the table layout can already deal with this situation, but it will have to at some point. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: [Xmlgraphics-fop Wiki] Update of GoogleSummerOfCode2006/FloatsImplementationProgress/ImplementingSideFloats by VincentHennebert
Vincent, On Tue, Aug 15, 2006 at 09:32:14PM +0200, Vincent Hennebert wrote: Hi Simon, Vincent, This page represents a good piece of work. Then a comment on the rules: Rule 1. Why does the rule not require not both x = 0 and x + ipd = ipd(ref-area), for both start and end floats, unless the float is wider than the ipd(ref-area)? In other words, why is rule 7 not required for any start and end floats? Hey, you're right. Ok, rule 1 is correct: a start-float may not stick out of the start-edge of the ref-area, period. The constraint on the opposite side is given by rule 7, which actually is badly phrased. More precisely, the formal wording is not equivalent to the loose wording given between parentheses. The loose wording is quite clear and intuitive; the formal wording forgets the case of a float alone: it's not because it is alone that it may stick out of the ref-area. Well, now that you've pointed it out this is pretty obvious... I've reformulated this rule according this time to the loose wording. Tell me if you don't agree. Rule 7a is logically correct, but I would say that the rule simply states that a start float should not stick out at the end side, even if it is not the one that is flush with the start side. Then x + ipd = ipd(ref-area) follows even without the condition ipd = ipd(ref-area). Rule 7b: the conclusion does not follow. The argument should be that an end float should not stick out at the start side, so that x =0. In 'Properties of the model': I do not see that rule 7 is satisfied. A start-float begins at the end-edge of the ref-area and is pulled along this edge (which is like a wall). So by nature it may not stick out of this edge. What the illustration attempts to show is that if previous start-floats occupy too much place, then the new start-float will strike against their after-edges (the start-guide) without being able to go beforer. I see now that the rules are satisfied. To show that it is only necessary to point out that it is satisfied by the initial position, and is not violated by subsequent movements. Whether it is stopped by the start guide is not relevant in this argument. You say nothing about the end floats. The argument is of course the same. Finally some thoughts on a possible algorithm: for each legal pagebreak for each active pagebreak node layout the page and calculate its demerits Laying out the page involves breaking each paragraph on the page into lines; each legal linebreak/active linebreak node combination (that is, each iteration in the two nested loops of the linebreak calculation) is associated with a certain side float layout, and thus the line widths for that case are known and the demerits can be calculated. One issue is that some legal pagebreaks are unknown until paragraphs are laid out (because of widows/orphans, for example). So the for each legal pagebreak is not that simple and might involve some backtracking. Yes, there is a problem there. The solution could be as follows: When the legal pagebreak is in a paragraph, it is also the considered legal linebreak. It is tested whether this linebreak could end the last line of the page. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.eu
DO NOT REPLY [Bug 40271] - auto table layout -- dirty draft
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=40271. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=40271 --- Additional Comments From [EMAIL PROTECTED] 2006-08-17 23:37 --- (In reply to comment #9) I did wonder whether this should be viewed on a per-page basis...? I mean: say you have a table with five cells per row (100+ rows), except for the last row which has six. Do we layout the whole table as if there were six columns, or only the last page? Look at it this way: You'd expect an fo:block to occupy the whole width on both pages if that block is broken between two pages and the first is a landscape page and the second is a portrait page. Now transfer this to fo:table where you might specify columns entirely using proportional-column-width() (or even using auto-table layout). Yes, but what I'm referring to is more that the _proportions_ would remain the same over the whole table, no matter what the actual page-dimensions are. Given that proportional-column-width() and auto table-layout are mutually exclusive, distribution of remaining space can occur if: a) table-layout=fixed, explicit columns with relative widths (some using p-c-w()) b) table-layout=fixed, implicit columns with relative widths (from cells in the first row) c) table-layout=auto Take case a): Suppose six defined columns, then in my original example, I'd expect the column-widths to have the same proportions on every page, no matter if the page contains a cell that occupies a particular column. This is what the average human being would expect, I guess, especially if it isn't the last column. Move on to case b): Suppose the first row contains five cells, each with a relative width of 20% --no proportional-column- width() here. Strictly following the Rec, we should end up with a table of five columns, equally large in proportion on all pages. What happens if I add a sixth cell to the last row? (I'd say we can safely ignore and complain about it, which we already do, IIC) Case c) seems to offers more liberty here, since not only the absolute, but also the relative values can be evaluated separately for each page. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
