Re: Collapsing borders: FOTree stage -- progress update
On Sun, 28 Aug 2005 10:33 am, Manuel Mall wrote: On Sat, 27 Aug 2005 02:07 am, Andreas L Delmelle wrote: Hi all, snip/ * The first step I took was moving much of the logic that is currently in CollapsingBorderModelEyeCatching (in the layout package) to CommonBorderPaddingBackground. I must admit I know very little about collapsing borders. Therefore if my comment is useless just ignore it. Oooops - you better ignore this. Just realised that while padding and margin allow percentages border-width doesn't. So its not an issue. Sorry for the noise. Manuel I have recently worked on all this percentage stuff. This applies also to border-width specifications. I believe border-width is one of the inputs to the border collapse algorithm. Relative border-width specifications can only be resolved at layout time (with the appropriate context). This seems to indicate the border collapse algorithm (at least the parts related to border-width) can only run during layout. snip/ Cheers, Andreas Manuel
Re: Collapsing borders: FOTree stage -- progress update
On Aug 28, 2005, at 04:33, Manuel Mall wrote: I must admit I know very little about collapsing borders. Therefore if my comment is useless just ignore it. Well, I certainly don't think it's useless... I have recently worked on all this percentage stuff. This applies also to border-width specifications. I believe border-width is one of the inputs to the border collapse algorithm. Relative border-width specifications can only be resolved at layout time (with the appropriate context). This seems to indicate the border collapse algorithm (at least the parts related to border-width) can only run during layout. Not really, I think. That has been on my mind as well, but as I see it, the border-widths will always be available as Length properties (not necessarily as fixed widths, unless they were already specified in the source document as such). I don't really intend to resolve those widths yet, just determine at FOTree stage *which* border (as in: specified on *which* element) will be applicable. If they were specified as percentages, those will still need to be resolved further on. Does this address your concerns, or am I misunderstanding you here? Cheers, Andreas
Re: Collapsing borders: FOTree stage -- progress update
On Aug 28, 2005, at 14:38, Andreas L Delmelle wrote: On Aug 28, 2005, at 00:06, Jeremias Maerki wrote: AFAIK you're trying to move the pre-resolvable pieces into the FO tree while you only do the specialities in the LMs, right? Exactly. Come to think of it, maybe that last idea won't be feasible Just for the sake of completeness (since I snipped away too much of my own message :-) ) I'm talking about my own idea of storing extra BorderInfo instances. Cheers, Andreas
Re: Automatic column widths in fop
On Aug 28, 2005, at 15:57, Manuel Mall wrote: This is just a clarification question to those in the know. In HTML when specifying a table browsers usually choose the smallest width without causing unforced breaks in columns. That is in XSL-FO terms the ipd of the table can be smaller than the containing block. In the current fop version it appears as if the table width is always forced to the width of the containing block, i.e. it behaves like setting width=100% in HTML on the table. I compared this to XEP and it renders more like HTML. Is this a feature, a bug, a not yet implemented, or do I misunderstand something? What layout-algorithm are you referring to exactly: fixed or auto? table-layout=auto is still unimplemented ATM. There have been numerous loose remarks about this in various threads, but no real work on this has started AFAIK. As for table-layout=fixed, CSS states that: The table's width may be specified explicitly with the 'width' property. A value of 'auto' ... means use the automatic table layout algorithm. http://www.w3.org/TR/REC-CSS2/tables.html#width-layout So, all things considered, if one doesn't specify an exact (fixed or percentage) IPD on the table, I think this means it is currently unimplemented. I haven't run any tests myself, but if FOP silently supposes a default inline-progression-dimension=100% in this case, then that would definitely be a bug. We could either: - drop the table completely (+ warn about this, of course) - explicitly notify the user that, because auto-layout is not supported, the default value of auto is ignored and replaced by 100% - throw a FOPException and exit Cheers, Andreas
Re: FOP website, release preparations: refactoring necessary
Jeremias Maerki wrote: (It's probably best to collapse Development and Design into one tab. Too many tabs are not ideal. I second that. J.Pietschmann
Bug report for Fop [2005/08/28]
+---+
| 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 |
| | | | | |
| 635|Opn|Nor|2001-02-18|Doesn't support id= attribute in fo:page-sequence |
| 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|
|
Re: Automatic column widths in fop
On Aug 28, 2005, at 16:21, Manuel Mall wrote: [Me:] We could either: - drop the table completely (+ warn about this, of course) - explicitly notify the user that, because auto-layout is not supported, the default value of auto is ignored and replaced by 100% I second that for the time being. Seemed the most sane thing to me as well, so added a few warnings for: - lack of support of auto-layout (if explicitly specified) - non-standard fallback when using fixed layout/auto width Cheers, Andreas
