DO NOT REPLY [Bug 36533] - Incorrect ipd and twsadjust settings
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=36533. 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=36533 --- Additional Comments From [EMAIL PROTECTED] 2005-09-11 10:37 --- Created an attachment (id=16355) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16355action=view) Testcase xml file (version with hyphenate=true) - no sensible checks though -- 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 36533] - Incorrect ipd and twsadjust settings
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=36533. 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=36533 --- Additional Comments From [EMAIL PROTECTED] 2005-09-11 10:38 --- Created an attachment (id=16356) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16356action=view) Area tree generated from attachment #16321 -- 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 36533] - Incorrect ipd and twsadjust settings
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=36533. 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=36533 --- Additional Comments From [EMAIL PROTECTED] 2005-09-11 10:40 --- Created an attachment (id=16357) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16357action=view) PDF generated from attachment #16355 -- 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 36533] - Incorrect ipd and twsadjust settings
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=36533. 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=36533 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #16356|Area tree generated from|Area tree generated from description|attachment #16321 |attachment #16355 -- 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: FOP website, release preparations: refactoring necessary
Patrick, I'm glad you took the time to finish the changes all the same. I'd simply put the SVN diff file in a Bugzilla issue and I'll deal with everything so that history is preserved. If there are any problems applying your patch, I can always get back to you. If you renamed any files while moving them, please indicate those as they are probably not easily recognizable in the patch. Thanks for doing that for us! That's one of the most important preconditions to get the first release out. PS: Some might have seen that I've changed my mail address for posting to mailing lists. The ISP for that old address has recently moved to M$ Exchange for mail infrastructure and since then I've had to deal with a lot of annoyances. On Friday, I finally migrated my 30+ list subscriptions. Phew. On 11.09.2005 05:22:30 Patrick Paul wrote: I apologize for not responding sooner, but I've been very busy lately. Anyways, I've finally found some time to get working on the website. I think I got everything right, now I just need to work on some broken links. Also, I am wondering if the svn diff will show everything (I moved some files around, for example the ones listed below are now in a directory called 0.20.5). I hope this is not a big issue. Cheers, Patrick Paul Jeremias Maerki wrote: Ok, so let's try to come up with a list. I see: The whole Using FOP section - compiling.xml - configuration.xml - running.xml - embedding.xml - servlets.xml - anttask.xml then most of Features: - output.xml - pdfencryption.xml - graphics.xml - fonts.xml - hyphenation.xml - extensions.xml The only item left out is this last section was compliance.xml which contains information for both versions. I'm not sure what to do with it. On 29.08.2005 00:10:31 Patrick Paul wrote: Now I have to determine what goes in the 2 newly created tabs. ;-) Jeremias Maerki Jeremias Maerki
Re: Space-resolution doesn't work
On 10.09.2005 21:54:56 Simon Pepping wrote:
On Fri, Sep 09, 2005 at 02:04:08PM +0200, Luca Furini wrote:
Luca Furini wrote:
For example, if we have this LM tree
Outer BlockLM
|
+++
|||
BlockLM 1BlockLM 2BlockLM 3
|
+--+-+
||
BlockLM ABlockLM B
BlockLM1.getNextKnuthElements() would return to the outer BlockLM only the
elements representing its block content, without any space.
In order to decide which elements it has to create, the outer BlockLM
could have some lines like:
(currentChild = BlockLM 1
nextChild = BlockLM 2)
space1 = currentChild.getSpaceAfter();
space2 = nextChild.getSpaceBefore();
if (this.mustKeepTogether()
|| currentChild.mustKeepWithNext() !nextChild.hasBreakBefore()
|| !currentChild.hasBreakAfter() nextChild.mustKeepWithPrevious) {
// there cannot be a break between the two children,
createElementsForSpace(resolve(space1, space2, false, false));
} else {
// there can be a break between the children
createElementsForSpace(resolve(space1, null, false, true),
resolve(null, space2, true, false),
resolve(space1, space2, false, false));
}
This is a good idea.
I agree.
Each LM would invoke this whenever it steps from
one child to another. Only the top level LM would also invoke it for
its before and after edges.
I would think of a different treatment of the spaces (space specifiers):
List spaces = new List(currentChild.getSpacesAfter(),
nextChild.getSpacesBefore());
createElementsForSpaces(spaces);
Good idea, too. I actually wondered how to implement Luca's suggestion
and I ended up subclassing Knuth classes (in my mind for now) to hold
the additional space specifier info, but this is a much cleaner approach
even if a little more objects might be instantiated here. I'll try to
document this on the Wiki once I'm through playing through my examples
so I really understand every aspect of the topic.
createElementsForSpaces would create a single glue and a single
penalty, because all space specifiers in a single block stacking
constraint need to be considered together to calculate the space
value. Resolution and creating elements go together, as a penalty must
be created to reflect the influence of a page break.
I'm not sure about this part, yet. I have some doubts about the rule 1
whose effects are only seen after the page breaking. But I'll find out
while creating my examples.
Jeremias Maerki
Re: Tables, Columns... : FOTree or Layout?
On 10.09.2005 01:41:05 Andreas L Delmelle wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, In my attempt to facilitate an implementation of the collapsing border model on tables by moving the lion's share of the logic from layoutmgr.table over to the fo.flow package, I stumbled upon some other parts that are currently dealt with at layout stage while I feel they don't really belong there. To put it generally: there are questions about a table's structure that can be answered by looking *solely* at the tree structure itself (i.e. no details about the how, when or even if of layout are required). The other ones I encountered so far: implicit columns (from cells in first row), column-number and number-columns-repeated. Especially the second seems out of place in layout, since it is needed by the (currently unimplemented) function from-table-column(). If the column-numbering is deferred until layout, it seems to become all the more difficult to provide an eventual implementation for this function. The other two are closely related to this, since they are necessary to get the column-numbers right. Point. But I somehow share Simon's reservation about moving table normalization into the FO tree. I share his view that the FO tree should represent the FO document like a DOM. On the other side, the FOEventHandlers (RTF, for example) could profit from the table normalization available on the FO tree level. But then the FOEventHandler could easily reuse the TableRowIterator. I'm not a big help here but after all I think the current table normalization works fine except that the from-table-column() method will be difficult to implement. This kind of on-the-fly normalization of the tree structure has advantages for layout in that the table-grid co-ordinates will be readily available (no interpretation needed, just pick up the cells as building-blocks and map them onto the grid without too much effort). Huh? But that's already the case with the TableRowIterator!? The only downside is that certain information is lost. The tree structure won't be the structure as specified in the source document, but will actually correspond to another structure that yields exactly the same results. Another related issue then, is that of storing the columns as a List. Currently, in layoutmgr.table.ColumnSetup, an error message is logged when there is a gap (i.e. non-occupied column-numbers). According to the Rec, this is no error, since there is no need for column-numbers to be monotonically increasing from one formatting object to the next (see: 7.26.8 column-number) This is probably why no exception is thrown (?) Yes, that should actually be no error, only maybe a hint to the user that default values will be used for a certain column. The problem is creating a TableColumn instance for the gaps. The case that more columns a required than are defined is handled differently by returning the last specified TableColumn. I take this to mean that an author can decide to number the first column as 3, and specify a number of 7 for the next. Yes. To allow for a straightforward way to map between the List index and the column-number, we'd need to create a List containing 7 elements, 5 of which aren't real elements at all... and that's still leaving number-columns-spanned out of the picture. Remember that number-columns-spanned on table-column don't actually span cells but only define column groups and provide a value for from-table-column(). The larger the gaps and the more spanning columns, the more unnecessary nulls to add. Right, but how many times does it happen? So, basically two questions here: 1) Anyone opposed to moving column-numbering, number-columns-repeated, implicit columns over to the FOTree side? (I already have a pretty good idea of what needs to be done, so I can start immediately on that.) Not opposed, but I don't really see how exactly you are going to do it. 2) Anyone opposed to using a Map to store the columns instead of a List? (Key = Integer or Numeric (column-number); Value = TableColumn) I wonder if the Map not actually uses more space or creates more object instances than the List approach with a few null values. Jeremias Maerki
Re: font-selection-strategy
I must say (from a pure FOP-POV), that I'm looking forward to see what Vincent will come up with with your help. WRT font-selection-strategy I believe that character-by-character will be a huge step forward for our two FO processors and should cover 98% of all use cases. If anyone needs more we can always look at it when this happens. I wouldn't think too much about that, yet, especially since we don't know the exact requirements that would come up. But I fully share your interpretation of the issues here. On 09.09.2005 19:54:38 Victor Mote wrote: FOP-devs: WRT font-selection-strategy, I think the new aXSL methods provide the means to client applications to implement the character-by-character option. My current reading of the spec is that the auto option is merely an opportunity, a hook if you will, for an implementation to do something fancier than character-by-character. This whole attribute is actually an extension to CSS, which only does character-by-character. The definition of auto is The selection criterion given by the contextual characters is used in an implementation defined manner. That seems to cover almost anything doesn't it? Including character-by-character. The Note under auto seems to confirm this. Nevertheless, the example given in the Note provides some ideas for other algorithms, and seems to suggest that there is room for more than one. So, the general framework would seem to include the definition of one or more such algorithms, naming each one, and then providing that name through some global-ish mechanism like a font-configuration file or other configuration option. The font system can then implement the algorithm, perhaps with the help of call-back methods to provide, for example, the various pieces of contextual text. Now, I suggest that the creation and definition of such algorithms should be driven by the user base. IOW, if a user wishes to suggest an algorithm for font-selection that provides something useful to them, it should be considered. I say this partly because I don't seem to have a need for any such thing. My general approach is going to be to provide a list of exactly one font-family and then (by perusing the log!!) make sure that font-family actually got used. If it did not, I'm going to consider my stylesheet to be deficient as opposed to the font selection algorithm. In other words, I am going to implement my own manual algorithm. The other wrinkle that the standard seems to present is qualitative judgments like better quality fonts and match each other badly stylistically. I know of no way to get this information other than asking the user for it. So it is likely that some algorithms will require additional information in font-configuration. This post does not require any response from anyone. I realize you are trying to get a release out the door. I just wanted to document my thoughts on the matter for you before they escaped. Victor Mote Jeremias Maerki
Re: Space-resolution doesn't work
On Sun, Sep 11, 2005 at 11:19:38AM +0200, Jeremias Maerki wrote:
On 10.09.2005 21:54:56 Simon Pepping wrote:
On Fri, Sep 09, 2005 at 02:04:08PM +0200, Luca Furini wrote:
Luca Furini wrote:
For example, if we have this LM tree
Outer BlockLM
|
+++
|||
BlockLM 1BlockLM 2BlockLM 3
|
+--+-+
||
BlockLM ABlockLM B
BlockLM1.getNextKnuthElements() would return to the outer BlockLM only
the
elements representing its block content, without any space.
In order to decide which elements it has to create, the outer BlockLM
could have some lines like:
(currentChild = BlockLM 1
nextChild = BlockLM 2)
space1 = currentChild.getSpaceAfter();
space2 = nextChild.getSpaceBefore();
if (this.mustKeepTogether()
|| currentChild.mustKeepWithNext() !nextChild.hasBreakBefore()
|| !currentChild.hasBreakAfter() nextChild.mustKeepWithPrevious) {
// there cannot be a break between the two children,
createElementsForSpace(resolve(space1, space2, false, false));
} else {
// there can be a break between the children
createElementsForSpace(resolve(space1, null, false, true),
resolve(null, space2, true, false),
resolve(space1, space2, false, false));
}
This is a good idea.
I agree.
Each LM would invoke this whenever it steps from
one child to another. Only the top level LM would also invoke it for
its before and after edges.
I would think of a different treatment of the spaces (space specifiers):
List spaces = new List(currentChild.getSpacesAfter(),
nextChild.getSpacesBefore());
createElementsForSpaces(spaces);
Good idea, too. I actually wondered how to implement Luca's suggestion
and I ended up subclassing Knuth classes (in my mind for now) to hold
the additional space specifier info, but this is a much cleaner approach
even if a little more objects might be instantiated here. I'll try to
document this on the Wiki once I'm through playing through my examples
so I really understand every aspect of the topic.
An alternative procedure is this: Let each LM return spaces together
with the Knuth elements in getNextKnuthElements. At a higher level,
the returned list is scanned for consecutive lists of spaces, which
are then resolved. The advantage is that it fits in with the existing
getNextKnuthElements, and the LMs can calculate their spaces when they
are calculating their Knuth elements, like they do now.
Simon
--
Simon Pepping
home page: http://www.leverkruid.nl
Re: Space-resolution doesn't work
I like it! On 11.09.2005 12:10:14 Simon Pepping wrote: snip/ An alternative procedure is this: Let each LM return spaces together with the Knuth elements in getNextKnuthElements. At a higher level, the returned list is scanned for consecutive lists of spaces, which are then resolved. The advantage is that it fits in with the existing getNextKnuthElements, and the LMs can calculate their spaces when they are calculating their Knuth elements, like they do now. Jeremias Maerki
Re: Tables, Columns... : FOTree or Layout?
On Sep 11, 2005, at 11:52, Jeremias Maerki wrote: Hi, On 10.09.2005 01:41:05 Andreas L Delmelle wrote: This kind of on-the-fly normalization of the tree structure has advantages for layout in that the table-grid co-ordinates will be readily available (no interpretation needed, just pick up the cells as building-blocks and map them onto the grid without too much effort). Huh? But that's already the case with the TableRowIterator!? Yes, but that class is situated in the layout package. So, this doesn't exactly provide the TableCell or TableColumn with the correct initial value for column-number (as described in the Rec). It leaves this up to the layout engine. In the short-term, this may not be too much of a problem, but if the long-term goal is still to provide the possibility of plugging in different layout engines, any such engine would have to take into account that FOP's tree structure will be lacking the correct initial property values here... snip / To allow for a straightforward way to map between the List index and the column-number, we'd need to create a List containing 7 elements, 5 of which aren't real elements at all... and that's still leaving number-columns-spanned out of the picture. Remember that number-columns-spanned on table-column don't actually span cells but only define column groups and provide a value for from-table-column(). OK, I overlooked this tiny detail... Thanks for pointing that out. Even then, I guess my concern was the combination of number-columns-spanned and number-columns-repeated. If you have a spanning column that is repeated, the column-numbers for the repeated columns will have to consider the value for number-columns-spanned. see: Rec 7.26.12 number-columns-repeated 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. The larger the gaps and the more spanning columns, the more unnecessary nulls to add. Right, but how many times does it happen? Yep. Precisely the reason I'm asking... So, basically two questions here: 1) Anyone opposed to moving column-numbering, number-columns-repeated, implicit columns over to the FOTree side? (I already have a pretty good idea of what needs to be done, so I can start immediately on that.) Not opposed, but I don't really see how exactly you are going to do it. For the column-numbers: tracking the columns as they are added to the tree, and increasing the column index should do the trick. The default value for the column-number property will be available as the column index of the parent table. In case a column-number was explicitly specified, and deviates from the initial value (the column index), the index will be forced to that column's column-number, so that it is correct for the next column. For the repeating columns: insert new TableColumns immediately into the tree structure. The only problem I'm facing here is that the properties can't actually be the same instances as those of the first column --this is currently the only case that will break the border-collapsing strategy I have in mind. (not going into details here; expect a separate post on that) For creating columns from the cells in the first row: still investigating... 2) Anyone opposed to using a Map to store the columns instead of a List? (Key = Integer or Numeric (column-number); Value = TableColumn) I wonder if the Map not actually uses more space or creates more object instances than the List approach with a few null values. Exactly why I'm asking. If this doesn't occur too much, it would indeed be a waste of resources... All things considered, this may indeed not be such a good idea. Thanks for your input. Cheers, Andreas
Re: Tables, Columns... : FOTree or Layout?
On 11.09.2005 12:47:03 Andreas L Delmelle wrote: On Sep 11, 2005, at 11:52, Jeremias Maerki wrote: Hi, On 10.09.2005 01:41:05 Andreas L Delmelle wrote: This kind of on-the-fly normalization of the tree structure has advantages for layout in that the table-grid co-ordinates will be readily available (no interpretation needed, just pick up the cells as building-blocks and map them onto the grid without too much effort). Huh? But that's already the case with the TableRowIterator!? Yes, but that class is situated in the layout package. So, this doesn't exactly provide the TableCell or TableColumn with the correct initial value for column-number (as described in the Rec). It leaves this up to the layout engine. In the short-term, this may not be too much of a problem, but if the long-term goal is still to provide the possibility of plugging in different layout engines, any such engine would have to take into account that FOP's tree structure will be lacking the correct initial property values here... There's nothing special about FOP's tree structure. It's just the exact representation of the FO file without any normalization. Anyway, if I hadn't introduced the TableCellLM in the PrimaryGridUnit you could simply move TableRowIterator and the GridUnit classes into the FO package because they have no dependency on the layout classes except for the little exception above. I imagine you will need to reproduce exactly what I implemented in TableRowIterator again in the FO tree. snip / To allow for a straightforward way to map between the List index and the column-number, we'd need to create a List containing 7 elements, 5 of which aren't real elements at all... and that's still leaving number-columns-spanned out of the picture. Remember that number-columns-spanned on table-column don't actually span cells but only define column groups and provide a value for from-table-column(). OK, I overlooked this tiny detail... Thanks for pointing that out. Even then, I guess my concern was the combination of number-columns-spanned and number-columns-repeated. If you have a spanning column that is repeated, the column-numbers for the repeated columns will have to consider the value for number-columns-spanned. see: Rec 7.26.12 number-columns-repeated 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. Hmm, to me that sounds like a mistake in the spec. This is completely illogical. At the very least, this sentence is in the wrong place. It doesn't even refer to the number-columns-repeated property. IMO this sentence creates a conflict between number-columns-repeated, number-columns-spanned and column-number for table-column. Note that the same sentence is also found in XSL 1.1WD. What do I miss? The larger the gaps and the more spanning columns, the more unnecessary nulls to add. Right, but how many times does it happen? Yep. Precisely the reason I'm asking... Ok, to answer my question: IMO not so often. So, basically two questions here: 1) Anyone opposed to moving column-numbering, number-columns-repeated, implicit columns over to the FOTree side? (I already have a pretty good idea of what needs to be done, so I can start immediately on that.) Not opposed, but I don't really see how exactly you are going to do it. For the column-numbers: tracking the columns as they are added to the tree, and increasing the column index should do the trick. The default value for the column-number property will be available as the column index of the parent table. In case a column-number was explicitly specified, and deviates from the initial value (the column index), the index will be forced to that column's column-number, so that it is correct for the next column. For the repeating columns: insert new TableColumns immediately into the tree structure. The only problem I'm facing here is that the properties can't actually be the same instances as those of the first column --this is currently the only case that will break the border-collapsing strategy I have in mind. (not going into details here; expect a separate post on that) That's also the big problem I see. I never actually figured out how to properly and manually create FO nodes. I'm sure there's an answer to that. For creating columns from the cells in the first row: still investigating... I don't think this is a big problem. Just check for the availability of a column set once the first row is available and create the column setup if necessary. 2) Anyone opposed to using a Map to store the columns instead of a List? (Key = Integer or Numeric (column-number); Value = TableColumn) I wonder if the Map not actually uses more space or creates more object instances than the List approach with a few null values. Exactly why I'm asking. If
Re: Tables, Columns... : FOTree or Layout?
On Sun, 11 Sep 2005 09:01 pm, Andreas L Delmelle wrote: On Sep 11, 2005, at 13:19, Jeremias Maerki wrote: On 11.09.2005 12:47:03 Andreas L Delmelle wrote: snip/ But anyway, currently the balance is: +2 for having the tree structure exactly resemble the FO source document versus +1 for performing normalization as the tree is built Apologies, but my understanding of this area is far too limited to give an opinion either way. Manuel
Re: Tables, Columns... : FOTree or Layout?
On 11.09.2005 15:01:30 Andreas L Delmelle wrote: On Sep 11, 2005, at 13:19, Jeremias Maerki wrote: On 11.09.2005 12:47:03 Andreas L Delmelle wrote: There's nothing special about FOP's tree structure. ... except that it currently doesn't provide the correct initial values for the mentioned properties :-) Right, sorry. It's just the exact representation of the FO file without any normalization. Anyway, if I hadn't introduced the TableCellLM in the PrimaryGridUnit you could simply move TableRowIterator and the GridUnit classes into the FO package because they have no dependency on the layout classes except for the little exception above. I imagine you will need to reproduce exactly what I implemented in TableRowIterator again in the FO tree. That may be an idea worth investigating: only implement it in the FOTree, and make it available to the layout package, so that layout can also use it --*if* it still needs to... IMO this would make the layout code massively more transparent. But anyway, currently the balance is: +2 for having the tree structure exactly resemble the FO source document versus +1 for performing normalization as the tree is built I think the first doesn't necessarily exclude the second. Maybe the normalized structure can be made available through the table element. This way you'd still have the normalized table available in the FO tree and to the FOEventHandlers while preserving the original FO tree. Plus my +1 on the first item is not a full +1, only perhaps a +0.5 as I'm fully aware that certain problem can only be resolved if some of the normalization happens in the FO tree already. We probably still haven't found the right design. Based on that, if no other devs jump in to support me, it seems I may have to abandon my plans for collapsing borders there altogether, as this would also mean that the BorderInfos for the table elements are altered (so they wouldn't correspond exactly to what was specified in the source document) :-( WRT efficiency, I still think it would be worthwhile to end up with a table tree structure with elements referring to the very same BorderInfo instance for a given side (losing BorderInfo instances for certain elements would be immediately discarded and replaced with a reference to the winning BorderInfo) Think of a table with 100+ rows, with the table's start-border dominating over all other elements' start-borders. First table-column, every table-body, every table-row, and all the first cells in every row would simply get a reference to the table's BorderInfo for that side. The idea behind it is that: a) the user shouldn't have supplied the losing border-specs in the first place (i.e. it would make no difference if he hadn't --his source document would produce exactly the same result), but b) this is often not under the user's control --think of a stylesheet that conveniently uses the same attribute-set for all cells in a given row, regardless of whether they share an edge with higher table-elements. I'm feeling stupid but I keep having problems following you. Maybe it would be worthwhile if you put your work in a branch so everyone could have a look. snip/ Jeremias Maerki
Bug report for Fop [2005/09/11]
+---+
| 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: Classpath setup problem
Simon Pepping wrote: What do you mean with repository? xml-fop/lib? No, $HOME/lib. I thought of either adding exclude name=fop*.jar/ exclude name=batik*.jar/ and perhaps a few more to filesets which load from optional.lib.dir, or have specific filesets for Jimi, JAI, JCE providers etc. Neither is completely foolproof, in particular ther may be people with JCE providers other than bouncy castle. J.Pietschmann
