cvs commit: xml-fop/src/codegen foproperties.xml
keiron 01/08/06 02:17:24 Modified:src/codegen foproperties.xml Log: setup a couple of props Revision ChangesPath 1.23 +8 -3 xml-fop/src/codegen/foproperties.xml Index: foproperties.xml === RCS file: /home/cvs/xml-fop/src/codegen/foproperties.xml,v retrieving revision 1.22 retrieving revision 1.23 diff -u -r1.22 -r1.23 --- foproperties.xml 2001/07/26 00:53:26 1.22 +++ foproperties.xml 2001/08/06 09:17:24 1.23 @@ -213,13 +213,13 @@ property namesource-document/name inheritedfalse/inherited -datatypeToBeImplemented/datatype +datatypeString/datatype defaultnone/default /property property namerole/name inheritedfalse/inherited -datatypeToBeImplemented/datatype +datatypeString/datatype defaultnone/default /property @@ -915,7 +915,12 @@ property namebaseline-shift/name inheritedfalse/inherited -datatypeToBeImplemented/datatype +datatypeLength/datatype + enumeration +value const=BASELINEbaseline/value +value const=SUBsub/value +value const=SUPERsuper/value + /enumeration defaultbaseline/default /property property - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
Reason for delay
Hi, all The main sticking point at the moment is the updating of the CHANGES file. I have not yet mustered up the courage to do this. We actually need 2 sets of changes added - 0.18 to 0.19, and 0.19 to 0.20. I have no idea how long this will take so I'm not going to speculate exactly on when I can build the release itself. But for anyone wrapping up loose ends, you can certainly assume next weekend and no earlier. 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: tables with margins and borders
Koen, Please indicate which version of FOP you are using and which renderer (-awt, -pdf, -print etc) displays this behavior. ' Best, -Ralph LaChance At 11:24 AM 8/6/01 +0100, you wrote: I'm having some issues with the rendering of table borders. When I ask to render a border around the table cell's and the table has a left margin of for example 2cm, than the text is shifted correctly 2 cm to the rigth but the borders appear disaligned with the text, ie 2cm to much to the left (I tend to conclude that the margins are not taken into account when rendering the cell borders). It looks like a 'bug' to me, as the same file is rendered correctly in the trial versions of the commericial tools availlable? - 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: Reason for delay
On Mon, 06 Aug 2001 13:17:28 Arved Sandstrom wrote: Hi, all The main sticking point at the moment is the updating of the CHANGES file. I have not yet mustered up the courage to do this. We actually need 2 sets of changes added - 0.18 to 0.19, and 0.19 to 0.20. I have no idea how long this will take so I'm not going to speculate exactly on when I can build the release itself. But for anyone wrapping up loose ends, you can certainly assume next weekend and no earlier. Just to give you a hand, I'll try to remember some of the things that have been changed (by various people). Hopefully I can remember it correctly. I'm sure I have forgotten some things... 0.18 - 0.19 - svg handled with batik, supported in pdf, awt and ps - svg-pdf transcoder, PDFGraphics2D for drawing into pdf - ps renderer - testing system, for use with the w3c defined testsuite.dtd including our tests 0.19-0.20 - all properties are read, a message will indicate if it is not supported - all elements now handled, with a message for unsupported elements - uses Unknown element if namespace+element not found, rather than using FObjMixed - support for only loading user fonts for pdf when needed - fo:wrapper should support inheriting properties better - table row span - support for drawing text into PDFGraphics2D - marker support (I'm sure you know) - streaming pdf - changed rendering of alpha images for svg in pdf, now uses white background - proper device information for PDFGraphics2D rendering - code formatted - element and property list mappings now added through single interface Not sure where - better handling table borders - lines/borders render better in pdf - better handling of base directory, image locating That's enough for me, my short term memory is empty. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: logging
On Fri, 03 Aug 2001 15:34:26 Daniel Parker wrote: And a good one. I'm not familiar with Velocity or it's particular approach, but the basic idea of separating logging interface from logging implementation is sound. Components such as fop should not require a particular logging implementation, they should write to an interface and allow different implementations of that interface to be configured. Any serious application that uses fop will have its own application wide logging facilities and will not be interested in fop's logging implementation. Regards, Daniel Parker That is exactly the role of a logging implementation (logkit etc.) it takes care of that. By that argument, if fop is to work with velocity we should have an interface that can use fop's logging interface or velocity. Then each of those two interfaces will interface to logkit, log4j etc. Then logkit and log4j have there own mechanism for directing output etc. So instead we can simply say that fop uses logkit. If you want to direct the logging to somewhere else (log4j, your own system etc.) then you need to create a target for logkit that does that for you. After all fop needs _a_ logging implementation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: logging
When FOP is a production ready library, I wont care for any FOP logging. Logging in FOP now is only for debugging as far as I'm concerned. There is no need for integration into other logging systems. Think about how you use other libraries. Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: tables with margins and borders
At 11:43 AM 8/6/01 -0400, Ralph LaChance wrote: fyi, the awt renderer changes are included in the latest snapshot and will presumably be in 0.20.0 Oh, they will be, no question about it. What's in CVS (or probably anything that gets added in the next couple of days) will definitely be in there. Regards, 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: tables with margins and borders
Hi Arved, Did you get a chance to look at the JPEG image I send you which increases the PDF file size? Please advise as I am not sure what I need to do to reduce the PDF file size. Thanks, Chetan Vig Arved Sandstrom wrote: At 11:43 AM 8/6/01 -0400, Ralph LaChance wrote: fyi, the awt renderer changes are included in the latest snapshot and will presumably be in 0.20.0 Oh, they will be, no question about it. What's in CVS (or probably anything that gets added in the next couple of days) will definitely be in there. Regards, 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] - 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 2094] - number-rows-spanned not implemented for fo:table-body
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=2094 *** shadow/2094 Sat Jun 9 04:21:32 2001 --- shadow/2094.tmp.9063Mon Aug 6 14:22:34 2001 *** *** 2,9 | number-rows-spanned not implemented for fo:table-body | ++ |Bug #: 2094Product: Fop | ! | Status: NEW Version: all | ! | Resolution:Platform: Other | | Severity: MinorOS/Version: Other | | Priority: Other Component: pdf renderer| ++ --- 2,9 | number-rows-spanned not implemented for fo:table-body | ++ |Bug #: 2094Product: Fop | ! | Status: RESOLVEDVersion: all | ! | Resolution: FIXED Platform: Other | | Severity: MinorOS/Version: Other | | Priority: Other Component: pdf renderer| ++ *** *** 39,41 --- 39,45 total. The resulting table is discarded. + + --- Additional Comments From [EMAIL PROTECTED] 2001-08-06 14:22 --- + This is fixed in CVS and will be in the 0.20 release. + Note: it will also work in table-header and table-footer! \ No newline at end of file - 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]
[Bug 2475] - Borders don't appear to work in fo:table-row
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=2475 *** shadow/2475 Fri Jul 6 05:14:24 2001 --- shadow/2475.tmp.9103Mon Aug 6 14:27:29 2001 *** *** 2,11 | Borders don't appear to work in fo:table-row | ++ |Bug #: 2475Product: Fop | ! | Status: NEW Version: all | | Resolution:Platform: PC | | Severity: Normal OS/Version: Windows NT/2K | ! | Priority: Other Component: pdf renderer| ++ | Assigned To: [EMAIL PROTECTED] | | Reported By: [EMAIL PROTECTED]| --- 2,11 | Borders don't appear to work in fo:table-row | ++ |Bug #: 2475Product: Fop | ! | Status: ASSIGNEDVersion: all | | Resolution:Platform: PC | | Severity: Normal OS/Version: Windows NT/2K | ! | Priority: Other Component: general | ++ | Assigned To: [EMAIL PROTECTED] | | Reported By: [EMAIL PROTECTED]| *** *** 33,35 --- 33,40 'best -Ralph LaChance + + --- Additional Comments From [EMAIL PROTECTED] 2001-08-06 14:27 --- + Known problem. borders should be taken into account on table-row if the + border-collapse property is set to collapse on table. Some clarification from + XSL spec is needed and is expected in the CR version. \ No newline at end of file - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[Bug 2740] - multi-page tables sometimes render badly
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=2740 *** shadow/2740 Mon Jul 23 07:25:43 2001 --- shadow/2740.tmp.9130Mon Aug 6 14:30:47 2001 *** *** 35,37 --- 35,44 --- Additional Comments From [EMAIL PROTECTED] 2001-07-23 07:25 --- Created an attachment (id=351) the badly rendered PDF - notice how row 23 is lost + + + --- Additional Comments From [EMAIL PROTECTED] 2001-08-06 14:30 --- + The overflow problem is fixed in CVS and will be in 0.20 release. But the test + file makes a different bug show up involving trailing white-space in the table + row. This isn't fixed yet, but the workaround is to get rid of extra white-space + at the end of table-cell content. \ No newline at end of file - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[Bug 1795] - table-cell background colour doesn't work.
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=1795 *** shadow/1795 Mon May 28 01:55:44 2001 --- shadow/1795.tmp.9154Mon Aug 6 14:33:16 2001 *** *** 2,9 | table-cell background colour doesn't work. | ++ |Bug #: 1795Product: Fop | ! | Status: NEW Version: 0.17| ! | Resolution:Platform: PC | | Severity: Normal OS/Version: Windows NT/2K | | Priority: High Component: general | ++ --- 2,9 | table-cell background colour doesn't work. | ++ |Bug #: 1795Product: Fop | ! | Status: RESOLVEDVersion: 0.17| ! | Resolution: FIXED Platform: PC | | Severity: Normal OS/Version: Windows NT/2K | | Priority: High Component: general | ++ *** *** 20,22 --- 20,25 greetings dominik berger + + --- Additional Comments From [EMAIL PROTECTED] 2001-08-06 14:33 --- + Fixed since 0.18 or maybe 0.19. \ No newline at end of file - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: logging
And a good one. I'm not familiar with Velocity or it's particular approach, but the basic idea of separating logging interface from logging implementation is sound. Components such as fop should not require a particular logging implementation, they should write to an interface and allow different implementations of that interface to be configured. Any serious application that uses fop will have its own application wide logging facilities and will not be interested in fop's logging implementation. Actually, we had the same problem of Which logging API do I use?; and we feel that others will likely have the same problem. As a result, we wrote an interface called Trunk (http://openinstitute.org/trunk/) that provides a fairly full-featured generic logging interface. There is already a Log4J driver, and more will be written soon. This interface could be considered for use in FOP; and even if it is not used, please do check it out and email with any comments that you have. Since we just started the openinstitute.org site last week, only the Javadocs are on there currently; but as soon as I package it up nicely and upload it (probably within the next day or two), the code will be there too. We're also looking for other Java developers to get involved with openinstitute.org; so if you're interested, check out our Wiki site which is linked off the main page at http://openinstitute.org/. - Eric P.S. Our ISP has been having quite a few problems lately, so if you can't access the site, try again in a few hours. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[Bug 2150] - New page with a table-header but without any table-body
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=2150 *** shadow/2150 Wed Jun 13 02:25:31 2001 --- shadow/2150.tmp.9188Mon Aug 6 14:41:27 2001 *** *** 2,11 | New page with a table-header but without any table-body | ++ |Bug #: 2150Product: Fop | ! | Status: NEW Version: all | | Resolution:Platform: PC | | Severity: MajorOS/Version: Windows NT/2K | ! | Priority: Other Component: pdf renderer| ++ | Assigned To: [EMAIL PROTECTED] | | Reported By: [EMAIL PROTECTED] | --- 2,11 | New page with a table-header but without any table-body | ++ |Bug #: 2150Product: Fop | ! | Status: ASSIGNEDVersion: all | | Resolution:Platform: PC | | Severity: MajorOS/Version: Windows NT/2K | ! | Priority: Other Component: page-master/layout | ++ | Assigned To: [EMAIL PROTECTED] | | Reported By: [EMAIL PROTECTED] | - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: XSL-FO Engine comparisons
I've been using FOP in production for many months. The catch is that I don't use it 'live'; I use it to build static PDF documents from XML documentation. I have not personally found FOP to be very crashy with my input docs, but I would still probably be nervous about using it live in a servlet application... -- Christopher Farley www.northernbrewer.com - 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]
Newbie attempting to help
Hi-
Well, I am trying to make my first contribution to
FOP. By working on bug 2988 which I submitted. I
willingly accept any and all help.
I tried forcing the status return from
ListItemLabel.layout to keep-with-next in an attempt
to force other code to handle keeping the
list-item-label and list-item-body together. That
didn't work, but keep-with-next is broken anyways, so
that is probably not unexpected. My thought right
now is to change
the end of ListItemLabel.layout to:
if(status == Status.OK) {
status = new Status(Status.KEEP_WITH_NEXT);
}
return status;
At least temporally, until I figure how to get FOP to
obey the keep_with_next when there is an
external-graphics as the first element in the
list-item-body.
Anything wrong with that? Any pointers in the right
direction?
Don Wellington
__
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
