block-container compliance
Just stumbled across this on our compliance page. For block-container we say in the compliance column for 0.91 'partial' but in the comment it says '[0.91 beta] No known restrictions'. Who is right? Manuel
Re: table-columns and number-columns-spanned
On Jan 12, 2006, at 21:55, gerhard oettl wrote: from Andreas L. Delmelle I see you made the same mistake (?) in interpretation of the Rec that I initially made: the Rec states literally that the column-number for a fo:table-column is 1 plus the column-number of the previous column Literaly you are absolutly right especially if reading the spec to column-number (7.26.8) first. My main argument against this is the description of number-columns-repeated (7.26.12) that says: a) The number-columns-repeated property specifies the repetition of a table-column specification n times; with the same effect as if the fo:table-column formatting object had been repeated n times in the result treewith the same effect as if the fo:table-column formatting object had been repeated n times in the result tree. Yeah, I remember we discussed this at the time I was implementing these in the FOTree, and we took this to be an inconsistency in the Rec... The main issue, I think, that kept me from following the definition under 7.26.12, is that you could end up with a situation where a given table-cell has column-number=2, while there is no column that has that column-number... In your example, the column-number 2 is not assigned to any column. What would you do if a bit further down in the tree, there is a fo:table-cell with column-number=2 ? With number-columns-repeated=N, you create the effect of separate columns occupying column-numbers I to I + N - 1, where I is the initial-value (the parent FO's currentColumnIndex = the previous column's number plus 1). I would distinguish number-columns- spanned=M, precisely by having it not occupy M column indices. If not, what would be the point in having two separate properties? and b) The column-number property, for all but the first, is the column-number of the previous one plus its value of the number-columns-spanned property. now verify a) fo:table-column number-columns-spanned=2 number-columns-repeated=2/ [ initial colnum = default = 1 ] would be expanded according to b) to: fo:table-column number-columns-spanned=2/ [ colnum = 1 ] fo:table-column number-columns-spanned=2/ [ colnum = 3 ] Stop! number-columns-repeated=N means insert a column node like this one N times, where 1 is the default/initial value. in comparison with:with the same effect as if the fo:table-column formatting object had been repeated n times in the result tree fo:table-column number-columns-spanned=2/ [ colnum = 1 ] fo:table-column number-columns-spanned=2/ [ colnum = 2 ] You see the two parts of the spec are not compatible and for this case i would prefere the rule that was given at column-numbers-repeat. As a side-effect the verification-example would produce overlapping table-columns. Hmm... I still think I like the latter more :-) Any table-cell having column-number=1 will occupy the first two columns (because of number-columns-spanned=2 on its corresponding table-column). If no cell has been assigned column-number=1, then a cell having column-number=2 will occupy column 2 and the next, whatever column-span (or column-number!) is specified on that next column. My sight could be wrong, but I think it is a good argument ;-) So could mine... Maybe others have anything to add to all of this? Cheers, Andreas
Re: block-container compliance
On Sun, 15 Jan 2006 06:40 pm, Jeremias Maerki wrote: Probably the partial indicator. Please review the following thread: http://www.nabble.com/Preparing-for-the-first-release---Examples-t542 439.html#a1461388 (especially the part where we realized that the spec changed in a backwards-incompatible way). At some point this will have to be looked at again. Interesting - is this a bug or a compliance issue - I don't quite understand? On 15.01.2006 10:15:27 Manuel Mall wrote: Just stumbled across this on our compliance page. For block-container we say in the compliance column for 0.91 'partial' but in the comment it says '[0.91 beta] No known restrictions'. Who is right? Jeremias Maerki Manuel
Re: block-container compliance
On Sun, 15 Jan 2006 11:28 pm, Jeremias Maerki wrote: Mostly a compliance issue. If you look at it from the XSL-1.1 POV, it's probably a bug, too. ATM, I'm unsure what to do. We probably need to verify that we understand the spec concerning the top/left properties on absolutely positioned block-containers correctly. I'm tempted to leave everything like it is for now. I was just wondering if our documentation is consistent and if we should capture this issue may be in a testcase or a bugzilla so we don't loose track of it? On 15.01.2006 16:01:04 Manuel Mall wrote: On Sun, 15 Jan 2006 06:40 pm, Jeremias Maerki wrote: Probably the partial indicator. Please review the following thread: http://www.nabble.com/Preparing-for-the-first-release---Examples- t542 439.html#a1461388 (especially the part where we realized that the spec changed in a backwards-incompatible way). At some point this will have to be looked at again. Interesting - is this a bug or a compliance issue - I don't quite understand? On 15.01.2006 10:15:27 Manuel Mall wrote: Just stumbled across this on our compliance page. For block-container we say in the compliance column for 0.91 'partial' but in the comment it says '[0.91 beta] No known restrictions'. Who is right? Jeremias Maerki Manuel Jeremias Maerki Manuel
DO NOT REPLY [Bug 37725] - NullPointerException in -rtf only (not pdf, txt, png..)
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=37725. 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=37725 --- Additional Comments From [EMAIL PROTECTED] 2006-01-15 19:08 --- I am working on it. The offending FO file does not throw a NPE anymore. But the result still does not look like expected. Kind regards, Peter Herweg -- 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: table-columns and number-columns-spanned
On Sun, Jan 15, 2006 at 11:56:54AM +0100, Andreas L Delmelle wrote: On Jan 12, 2006, at 21:55, gerhard oettl wrote: from Andreas L. Delmelle I see you made the same mistake (?) in interpretation of the Rec that I initially made: the Rec states literally that the column-number for a fo:table-column is 1 plus the column-number of the previous column Literaly you are absolutly right especially if reading the spec to column-number (7.26.8) first. My main argument against this is the description of number-columns-repeated (7.26.12) that says: Yeah, I remember we discussed this at the time I was implementing these in the FOTree, I expected this and searched, but did not succeed. The MARC archive findes nothing (but also not this thread) and the apache eyebrowse link points to a non-existent page. So if you know the timeframe (some month more or less don't matter) where I can look in the archive it would be nice to let me know. and we took this to be an inconsistency in the Rec... Here I can fully agree. But the implementation of fop should not ;-) I can life with every sight, but want to show some pros and cons and want to know which part of the inconsitent Rec should be canceled to adopt the from-table-column function. I see the spec a little overcrowded here by trying to put two features into the table-column element in general and to the number-columns-spanned property in special: I) background information (pointing to column groups in CSS2 for determining the background - in the notes for fo:table) II) as a container for informations that can be used by from-table-column. For II) it would be best to have all column-number / number-columns-spanned pairs allowed (what was in contrast to the table-cell spec not explicitly forbidden and what would mean to have the same column-number used more than once) but I think it a nightmare for I) because how to decide which background-color to use? - and it was not explicitly allowed too. On the other hand the first fallback described in the from-table-column function (retry with number-columns-spanned=1) is useless if every column-number can only be used once. If there is a table-column with the same column-number as the table-cell has you always end at this table-column regardless of the number-columns-spanned on the table-column or on the table-cell. It only would make sense if there are more table-columns with the same column-number but with different number-columns-spanned. Could make everything more complicated than it is already ;-) I am astonished that XSL 1.1 does not clarify anything here. The main issue, I think, that kept me from following the definition under 7.26.12, is that you could end up with a situation where a given table-cell has column-number=2, while there is no column that has that column-number... In your example, the column-number 2 is not assigned to any column. What would you do if a bit further down in the tree, there is a fo:table-cell with column-number=2 ? IMHO it should take the information from the spanned range, if it spannes 1 column or otherwise the default value for the property in question. My base is the (maybe also to freely interpreted) sentence from 7.26.13 that says: 'For an fo:table-column the number-columns-spanned property specifies the number of columns spanned by table-cells that may use properties from this fo:table-column formatting object using the from-table-column() function.' - which i read every cell that has a spanned range (begincol to endcol) that is within the range spanned by the table-column - and which I used as second fallback. With number-columns-repeated=N, you create the effect of separate columns occupying column-numbers I to I + N - 1, where I is the initial-value (the parent FO's currentColumnIndex = the previous column's number plus 1). I would distinguish number-columns- spanned=M, precisely by having it not occupy M column indices. Though I argue against, I have to say that it is a fully legal point of view. If not, what would be the point in having two separate properties? Very right. This is a question I asked myself more than once without any realy answer. The only case I could think where they differ is: fo:table-column column-number=1 number-columns-spanned=5 text-align=center/ fo:table-column column-number=6 number-columns-spanned=2/ etc/ fo:table-cell column-number=4 number-columns-spanned=3 fo:block text-align=from-table-column() Here not all columns spanned by the cell (column 4 to 6) are spanned by the first table-column definition and no table-column with the column-number 4 exists (first fallback-rule for from-table-colum), so it falls back to the default (start). With the current implementation of number-columns-repeated it would end up with center. Any table-cell having column-number=1 will occupy the first two columns (because of number-columns-spanned=2 on its corresponding table-column). If no cell has been assigned
DO NOT REPLY [Bug 38282] New: - [patch] from-table-column implementation
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=38282. 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=38282 Summary: [patch] from-table-column implementation Product: Fop Version: 1.0dev Platform: Other OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: fo tree AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] This patch should implement the from-table-function. Changes to TableFObj.java: 1) Make the getTable method public to have a quick access. Alternatives: 1a) Only make public in TableCell (and call there super.getTable) 1b) Explicitly traverse back in the FromTableColumnFunction with getParent until we reach the Table object. Changes to TableColumn: 2) Preserve PropertyList and add an accessor for this list Note: Preserved PropertyList could be cleared at the end of the table at fo tree parsing (for memory freeing) because it is not needed for the layout-managers. Should I do this in Table.endOfNode? Changes to FromTableColumnFunction.java: Details of implementation under discussion at fop-dev. Thread: table-columns and number-columns-spanned last fallback and eventually second fallback may be obsoleted by this discussion. -- 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.
Bug report for Fop [2006/01/15]
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) |
| | +-+
| | | Severity: BLK=Blocker CRI=CriticalMAJ=Major |
| | | MIN=Minor NOR=Normal ENH=Enhancement |
| | | +-+
| | | | Date Posted |
| | | | +--+
| | | | | Description |
| | | | | |
| 953|Opn|Nor|2001-03-12|Incorrect hyperlinks area rendering in justified t|
| 1063|New|Nor|2001-03-21|fop does not handle large fo files|
| 1180|New|Maj|2001-04-02|Problem with monospaced font |
| 1859|Opn|Min|2001-05-22|org.apache.fop.apps.Driver.reset() doesn't fully r|
| 1998|New|Nor|2001-06-05|linefeed-treatment not understood |
| 2150|Ass|Maj|2001-06-13|New page with a table-header but without any tabl|
| 2475|Ass|Nor|2001-07-06|Borders don't appear to work in fo:table-row|
| 2740|New|Maj|2001-07-23|multi-page tables sometimes render badly |
| 2909|New|Maj|2001-07-30|Gradient render error |
| 2964|Ass|Nor|2001-08-02|problems with height of cells in tables |
| 2988|New|Maj|2001-08-03|0.19: list-item-label does not stick to list-item-|
| 3044|Ass|Maj|2001-08-08|keep-together not functioning |
| 3280|New|Nor|2001-08-27|PCL Renderer doesn't work |
| 3305|Opn|Nor|2001-08-28|list-block overlapping footnote body |
| 3497|New|Cri|2001-09-07|id already exists error when using span=all attr|
| 3824|New|Blk|2001-09-25|MIF option with tables|
| 4030|New|Nor|2001-10-08|IOException creating Postscript with graphics on S|
| 4126|New|Nor|2001-10-12|FontState.width() returns pts instead of millipts |
| 4226|New|Nor|2001-10-17|The orphans property doesn't seem to work |
| 4388|New|Nor|2001-10-24|Nullpointer exception in the construction of new D|
| 4415|New|Nor|2001-10-25|scaling=uniform does not work on images... |
| 4510|New|Nor|2001-10-30|fo:inline common properties ignored? |
| 4535|New|Maj|2001-10-31|PCL renderer 1.13 not rendering SVG |
| 4767|New|Nor|2001-11-09|SVG text is distored in PDF output|
| 5001|New|Nor|2001-11-21|content-width and content-height ignored? |
| 5010|New|Enh|2001-11-21|Better error reporting needed |
| 5124|New|Maj|2001-11-27|fo:block-container is not rendered properly using |
| 5335|Opn|Min|2001-12-10|Text with embedded CID fonts not retrievable from |
| 5655|Ass|Nor|2002-01-02|text-decoration cannot take multiple values |
| 6094|Opn|Maj|2002-01-29|0.20.3rc hangs in endless loop|
| 6237|Opn|Nor|2002-02-05|#xFB01 (fi ligature) produces a sharp? |
| 6305|New|Nor|2002-02-07|Using fo:table-and-caption results in empty output|
| 6427|New|Enh|2002-02-13|Adding additional Type 1 fonts problem|
| 6437|New|Maj|2002-02-13|Tables without fo:table-column don't render |
| 6483|New|Nor|2002-02-15|Table, Loop, footer could not fit on page, moving|
| 6844|New|Nor|2002-03-04|No line breaks inserted in list-item-label|
| 6918|New|Enh|2002-03-06|reference-orientation has no effect |
| 6997|New|Nor|2002-03-09|[PATCH] Row-spanned row data breaks over a page wi|
| 7140|New|Enh|2002-03-15|page-position attribute set to last on condition|
| 7241|New|Nor|2002-03-19|keep-with-previous, keep-with-next only working on|
| 7283|New|Nor|2002-03-20|Table border misaligned when using margin-left in |
| 7337|New|Nor|2002-03-21|border around external image leaves empty space |
| 7487|New|Nor|2002-03-26|break-before=page for table inserts empty page |
| 7496|New|Nor|2002-03-26|The table header borders are not adjusted to the b|
| 7525|New|Cri|2002-03-27|table with spans inside a list-block |
| 7919|New|Cri|2002-04-10|problem to use attribute linefeed-treatment and li|
| 8003|Ass|Maj|2002-04-12|FopImageFactory never releases cached images |
| 8050|New|Nor|2002-04-13|Soft hyphen (shy;) is not handled properly |
| 8321|New|Nor|2002-04-19|from-parent('width') returns 0 for nested tables |
| 8463|New|Nor|2002-04-24|SVG clipping in external.fo example doc when rende|
| 8767|Ass|Min|2002-05-03|Image and solid colour background rectangle sizes |
|
DO NOT REPLY [Bug 38282] - [patch] from-table-column implementation
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=38282. 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=38282 --- Additional Comments From [EMAIL PROTECTED] 2006-01-15 23:09 --- Created an attachment (id=17427) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=17427action=view) an example fo-file -- 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.
