DO NOT REPLY [Bug 2964] - problems with height of cells in tables
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2964. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2964 problems with height of cells in tables --- Additional Comments From [EMAIL PROTECTED] 2003-03-18 13:19 --- Created an attachment (id=5405) i don t understant why CADRE B hasn t a different height than the other cells - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 2964] - problems with height of cells in tables
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2964. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2964 problems with height of cells in tables --- Additional Comments From [EMAIL PROTECTED] 2003-03-18 13:21 --- cells have different height even though they are in the same row. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 2964] - problems with height of cells in tables
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2964. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2964 problems with height of cells in tables [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2002-11-14 21:30 --- 0.20.4 doesn't crash, but the bug is still there. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 2964] - problems with height of cells in tables
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2964. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2964 problems with height of cells in tables --- Additional Comments From [EMAIL PROTECTED] 2002-05-06 15:59 --- The attached file crashes FOP 0.20.3 with a NullPointerException while trying to get the next page master. I think this is a new bug. Apart from this the described bug is still there. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Table Status (was Re: problems with height of cells in tables)
Hi Arved (and other interested parties), Lots of other bugs (like the inline-area height) show up well in tables because the grid makes things visible. That's the case with the trailing white-space bug I saw the other day, resulting in an empty table row. Some of these can also be shown by using border, padding and background on fo:block, which also needs more test cases. I think base-level table functionality has gotten considerably better, and we need to publicize that with the next release, since there have been so many problems in the past releases. Of course, I know there are still a number of bugs, but I think the row-spanning, vertical alignment and general border-handling improvements should help lots of people. Off the top of my head, here are major areas for work: 1. border-collapse=collapse. There is a partial bandaid for this now. I've written a lot of pseudo-code for this, as the general case is quite complex. It should take into account cell, row and column borders (though I'd like to see the final word in the PR on this). As often, I ran up against the problem of handling the break conditions, since that can affect the borders. But unless someone else has done lots of work here or has some easy improvements, I'd like to keep it on my plate (after vacation). 2. Keeps and breaks. There are some cases where breaks cause problems; as I recall the culprit is in table-body. I know the general problem of keeps can't really be handled, but tables are a particularly sore point for that. It's worth trying to do keep-together for table-row; actually I think I did a first pass on this when I did spans. 3. Handling limit conditions, like table-row with keeps but which doesn't fit on the page. 4. Indents. Just looked at Koen's bug, which involves the indents not affecting the table itself, but rather the cell content. My reading of the CR is that the areas created by fo:table are block areas and should be positioned by indents. Lots of people also want to center their tables; I can't figure out how this is supposed to happen, unless it's in table-and-capation. 5. The table-and-caption fo. 6. Row-less tables using start-row and end-row properties on the cells. I think this can be handled in addChild for the table-body by creating fake TableRow objects as needed. 7. Automatic table layout style (this is a fairly big deal). Or at least really implement the percentage stuff, which would be simpler and still quite flexible. This needs some work in calculating the column widths once the size of the containing reference area is known. 8. The relative-align style for vertical alignment. Needs post-processing once all cells in the row are done. Might as well wait until we get our line-stacking straightened out. That should keep people thinking for a while... There are also a few remarks below. I'll be away from my Internet access for a while, so this is probably it for now. Overall the idea seems good. Obviously if I've temporarily let go of bottom-up layout, it was to try to reduce the volume of table-related complaints. Regards and a bientot Karen Arved Sandstrom wrote: Hi, Karen (and other interested parties) A thought occurred to me just now. A high percentage of our bandwidth (and bug reports) are devoted to tables. There are so many table-related bug reports mainly because so many folks want to use tables, I believe, not because there are more bugs in tables than elsewhere. I'm thinking that perhaps we can use table support as the centrepiece for all of our FOP efforts. In order to have tables be fully supported, and work properly, a really big percentage of the XSL specification (and FOP mechanics) gets exercised. Redesign of layout is something of a fuzzy goal; making tables work isn't. You've currently got probably the best perspective on tables. What I am thinking would be useful would be a report concerning table FOs, with a property-by-property breakdown, that assesses what works, and what doesn't, and what needs to happen in order to make things work. This could drive a whole bunch of tasks that people could take on. It would be easier to gauge the progress of FOP, because table support would be a bellwether for FOP as a whole. This doesn't mean that everything else would be ignored. But the shift of emphasis would be as follows: if I want to work on markers, I make sure that they work inside fo:table-and-caption, fo:table, fo:table-caption, fo:table-header, fo:table-footer, fo:table-body, and fo:table-cell. If someone wants to make sure FO X works, they make sure it works also as a descendant of fo:table-cell. Keiron has laid the groundwork for testing - a really suitable area for a first comprehensive set of test-cases could be (you guessed it) tables! :-) KL: Agreed. I started to do some test cases, but then discovered I needed to add more properties to the AreaTree concerning borders and padding. I didn't get around to doing this, so we can put
Re: problems with height of cells in tables
Hi Peter, Thanks for the test files. Yes, you are right that font metrics influence the calculation. In fact, these examples point out a number of problems with FOP's line sizing logic. The sizing is really determined by the font-family and font-size specified or inherited on the fo:block containing the text. The actual size of the text is ignored in calculating the line height! So the last four lines of your table correspond to this: 1. 18pt, Arial 2. 18pt, default font-family (sans-serif) 3. default font-size (12pt), Arial 4. default font-size (12pt), default font-family (sans-serif) The font metrics for Arial obviously have a larger ascender value than those for the default font. So much for the explanations. Unfortunately, I'm not sure I'll try to fix this right away, since I fear that it involves some rather major changes. It really comes down to the fact that the fo:inline object doesn't actually generate a nested inline area, but just adds characters to the LineArea. So there's no place for it to actually store the line-height information. Perhaps someone else will be be braver. In any case, it's certainly on the list for the layout redesign... Regards, Karen Petr Andrs wrote: Hi Karen, I have made some further investigation. I agree that this is probably not specific to tables, but it is better observable on tables. When using embedded TTF fonts, height of line is influenced also by font- family attribute. If font-family is specified on table-row or cell (I think it can be generalized to any block level object) height of line is different from case when font-family is specified on inline level object. So I made simple testing example. I made table with lines having all possible combinations of place of specificatin of font-size and font-family (at block level v. at inline level) resulting in four table lines. Then I made more combinations using two different font- sizes and two different font-families resulting in 16 line table. Results of this experiment are attached. You can notice than every line printed by Arial 18pt (the four bottom lines) has its own unique height of line. So it maybe has something to do with usage of font metrics. Petr On 5 Aug 2001, at 0:16 Karen Lease wrote about Re: problems with height of cells i : Hi Petr, I've looked at this quickly and my first reaction is that it's probably not specific to tables. I think it has to do with line-height (aka leading in old typographic terms). Neither font-size nor line-height are specified at a high level in your .fo. The default font-size is 12pt and the default line-height 1.2 em (14.4pt). When you set font-size at the block level as in the last row, that will also change the line-height, since it's relative, so the total height is smaller. When you set font-size at the inline or wrapper, it apparently isn't changing line-height. I guess since line-height can be specified for both fo:ineline and fo:character (via the fo:wrapper), that the line-height should also be modified by setting font-size on those objects too. Good eye! on thousand lines the difference makes several pages so it is quite noticable Regards, Karen Petr Andrs wrote: Please see attached file. There is table with three lines, which all should have equal height. But they haven't, the last one has lower height than the other two. (Or the fist two have greater height than the las one) I would expect all three lines to look something like the last one, the first two are too high for my eye. Petr Name: emptest.fo emptest.foType: unspecified type (Application/Octet-stream) Encoding: BASE64 Name: emptest.pdf emptest.pdfType: Portable Document Format (application/pdf) Encoding: BASE64 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: problems with height of cells in tables
At 12:22 AM 8/6/01 +0200, Karen Lease wrote: So much for the explanations. Unfortunately, I'm not sure I'll try to fix this right away, since I fear that it involves some rather major changes. It really comes down to the fact that the fo:inline object doesn't actually generate a nested inline area, but just adds characters to the LineArea. So there's no place for it to actually store the line-height information. Perhaps someone else will be be braver. In any case, it's certainly on the list for the layout redesign... As soon as FOP 0.20.0 hits the streets, this is something that we may as well tackle and get over with. I ran into the same stumbling block a few weeks ago - I wanted to complete the set of FOs that can have markers, and fo:inline was one. Unfortunately, as you point out, fo:inline currently generates no area. If we are going to follow the conceptual model in the spec, which FOP currently does, then I figure we need to do so consistently, so fo:inline needs to create an area. I actually went down the initial design and coding road a bit. My conclusion was that if this is carefully done then it is not that bad. I also figured that for an initial cut it is better to duplicate and add classes to support this rather than to modify any existing classes, like FOText, because they are too central. But one could make the argument that FOText itself maybe needs work, so why _not_ modify it for the general case? Regards, Arved Sandstrom Fairly Senior Software Type e-plicity (http://www.e-plicity.com) Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: problems with height of cells in tables
Arved Sandstrom wrote: At 12:22 AM 8/6/01 +0200, Karen Lease wrote: So much for the explanations. Unfortunately, I'm not sure I'll try to fix this right away, since I fear that it involves some rather major changes. It really comes down to the fact that the fo:inline object doesn't actually generate a nested inline area, but just adds characters to the LineArea. So there's no place for it to actually store the line-height information. Perhaps someone else will be be braver. In any case, it's certainly on the list for the layout redesign... As soon as FOP 0.20.0 hits the streets, this is something that we may as well tackle and get over with. I ran into the same stumbling block a few weeks ago - I wanted to complete the set of FOs that can have markers, and fo:inline was one. Unfortunately, as you point out, fo:inline currently generates no area. If we are going to follow the conceptual model in the spec, which FOP currently does, then I figure we need to do so consistently, so fo:inline needs to create an area. I actually went down the initial design and coding road a bit. My conclusion was that if this is carefully done then it is not that bad. I also figured that for an initial cut it is better to duplicate and add classes to support this rather than to modify any existing classes, like FOText, because they are too central. But one could make the argument that FOText itself maybe needs work, so why _not_ modify it for the general case? Yes, I pretty much agree. When I was doing the redesign, I was working on the concept of creating inline areas for all inline type objects (except wrappers). I was going to just make one big inline flow set with all the inline areas in a single sequence, and then do the breaking from there. Once the line breaks were determined, then we can do the line-height calculations according to the rules and the values of the different properties. The biggest problem with having the actual text at different levels in the tree is for doing things like white-space handling, word-breaking hyphenation etc (assuming that at least some of those should abstract from the actual inline tree). Along those lines, and after trying to understand the white-space handling in LineArea, I was wondering if it wouldn't be possible to do that while building the FO tree. I was thinking of some kind of state machine and using an iterator over the FO tree to abstract the level problem. Sounds like I need to look into Peter's Tree work. (I'm sure all that sounds quite obscure... oh well, just lettings people know where I might be poking around.) Regards, Karen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[Bug 2964] - problems with height of cells in tables
PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL BE LOST SOMEWHERE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2964 *** shadow/2964 Thu Aug 2 05:28:25 2001 --- shadow/2964.tmp.9076Mon Aug 6 14:23:47 2001 *** *** 23,25 --- 23,30 --- Additional Comments From [EMAIL PROTECTED] 2001-08-02 05:28 --- Created an attachment (id=379) Demonstrating example + + + --- Additional Comments From [EMAIL PROTECTED] 2001-08-06 14:23 --- + You are right, but it's not only in tables; it's due to incorrect handling of + inline areas and should be fixed. \ No newline at end of file - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: problems with height of cells in tables
Hi, Karen (and other interested parties) A thought occurred to me just now. A high percentage of our bandwidth (and bug reports) are devoted to tables. There are so many table-related bug reports mainly because so many folks want to use tables, I believe, not because there are more bugs in tables than elsewhere. I'm thinking that perhaps we can use table support as the centrepiece for all of our FOP efforts. In order to have tables be fully supported, and work properly, a really big percentage of the XSL specification (and FOP mechanics) gets exercised. Redesign of layout is something of a fuzzy goal; making tables work isn't. You've currently got probably the best perspective on tables. What I am thinking would be useful would be a report concerning table FOs, with a property-by-property breakdown, that assesses what works, and what doesn't, and what needs to happen in order to make things work. This could drive a whole bunch of tasks that people could take on. It would be easier to gauge the progress of FOP, because table support would be a bellwether for FOP as a whole. This doesn't mean that everything else would be ignored. But the shift of emphasis would be as follows: if I want to work on markers, I make sure that they work inside fo:table-and-caption, fo:table, fo:table-caption, fo:table-header, fo:table-footer, fo:table-body, and fo:table-cell. If someone wants to make sure FO X works, they make sure it works also as a descendant of fo:table-cell. Keiron has laid the groundwork for testing - a really suitable area for a first comprehensive set of test-cases could be (you guessed it) tables! :-) It would be really cool if you could generate such a report concerning table status - we could generate tasks from the description of unimplemented or work-in-progress features, and take it from there. My concern at the moment is that a lot of what we have is somewhat superficial - things that work on fo:block begin to break down when blocks are nested, or occur inside lists and tables. I'm as guilty of this as anyone, I figure. Having one central major area that we can concentrate on allows us to get to the point where things work everywhere they are supposed to. This is an initial thought. I'm certainly not trying to pile more work on your shoulders, but I genuinely believe that this is a good route to follow, and you can be of great assistance here. Thanks, Arved Fairly Senior Software Type e-plicity (http://www.e-plicity.com) Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: problems with height of cells in tables
Hi Petr, I've looked at this quickly and my first reaction is that it's probably not specific to tables. I think it has to do with line-height (aka leading in old typographic terms). Neither font-size nor line-height are specified at a high level in your .fo. The default font-size is 12pt and the default line-height 1.2 em (14.4pt). When you set font-size at the block level as in the last row, that will also change the line-height, since it's relative, so the total height is smaller. When you set font-size at the inline or wrapper, it apparently isn't changing line-height. I guess since line-height can be specified for both fo:ineline and fo:character (via the fo:wrapper), that the line-height should also be modified by setting font-size on those objects too. Good eye! Regards, Karen Petr Andrs wrote: Please see attached file. There is table with three lines, which all should have equal height. But they haven't, the last one has lower height than the other two. (Or the fist two have greater height than the las one) I would expect all three lines to look something like the last one, the first two are too high for my eye. Petr Name: emptest.fo emptest.foType: unspecified type (Application/Octet-stream) Encoding: BASE64 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
