FOP website, release preparations: refactoring necessary
While we're at it: In preparation for the first release we need to start thinking about a refactoring of our website. Since FOP 0.20.5 will probably stay the preferred productive version for some time and FOP Trunk is substantially different, I'd like to propose doing a version split like Forrest [1] have done. That would involve factoring out the version-dependent docs into a separate tab (or something like that), so we can have info for both versions side-by-side for the time being. I think stuff like embedding info would become too complicated and unreadable if we tried to put everything in the same place. If anyone would like to take the lead here, I'd be grateful. Otherwise, I will squeeze it in somewhere. [1] http://forrest.apache.org Jeremias Maerki
Re: StAX, JAXP 1.4
Elliotte Harold wrote: Peter B. West wrote: But of course, I'm talking about Folio, which was built on a pull-parsing model before I had ever heard of pull-parsing, because it was the screamingly obvious thing to do. It gives me acute pleasure to see my original design decisions vindicated by the the development of the StAX API, and the current surge of interest. So, all of this, and more, _is_ the case. My invitation stands. I haven't looked at Folio yet. Perhaps it's screamingly obvious that it needs a pull model. If so it's the first such application I've encountered. The really useful pull models are implemented on top of tree structures, and provide random access. I've yet to see a case where a one-way streaming pull parser did anything that couldn't be accomplished equally easily and efficiently with a push parser. The primary benefit to pull parsers is that some developers either don't understand or simply don't like the observer design pattern as embodied in push parsers, and prefer the iterator design pattern as embodied in pull parsers. Whatever floats your boat. However there's no evidence that either pattern is in any way fundamentally superior to the other, except as a matter of developer taste. As a practical matter, existing SAX parsers are much better optimized and debugged than existing StAX parsers. They're simply a more mature product. Elliotte, We're seriously OT here, so I'll off-line my response. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ smime.p7s Description: S/MIME Cryptographic Signature
Re: FOP website, release preparations: refactoring necessary
I would like to take care of that. I should have some free time in the next few weeks, so I will start doing a little bit everyday starting Wednesday. Patrick Jeremias Maerki wrote: While we're at it: In preparation for the first release we need to start thinking about a refactoring of our website. Since FOP 0.20.5 will probably stay the preferred productive version for some time and FOP Trunk is substantially different, I'd like to propose doing a version split like Forrest [1] have done. That would involve factoring out the version-dependent docs into a separate tab (or something like that), so we can have info for both versions side-by-side for the time being. I think stuff like embedding info would become too complicated and unreadable if we tried to put everything in the same place. If anyone would like to take the lead here, I'd be grateful. Otherwise, I will squeeze it in somewhere. [1] http://forrest.apache.org Jeremias Maerki
Re: FOP website, release preparations: refactoring necessary
I would be willing to help in any way I can... One thing I've noticed, is that Forrest 0.7 appears to have created separate versions of their documentation. It may make sense to follow their example: http://forrest.apache.org/versions/index.html Web Maestro Clay On Aug 23, 2005, at 5:41 AM, Jeremias Maerki wrote: Very cool! Thanks a lot! If you need any help, just yell. On 23.08.2005 14:37:38 Patrick Paul wrote: I would like to take care of that. I should have some free time in the next few weeks, so I will start doing a little bit everyday starting Wednesday. Patrick Jeremias Maerki wrote: Regards, Web Maestro Clay -- [EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/ My religion is simple. My religion is kindness. - HH The 14th Dalai Lama of Tibet
enhancing rtf support
Hello fop-team, i'd like to spend again some time with enhancing the RTF support. I have been inactive for over a year now (sorry, i was quite busy). Do you want me to send patches, because i was inactive for such a long time? Or can i access the svn repository? I have received the fop-dev-mailing list, but usually have only read the subject lines. I'd like to accomplish following tasks: (1) FOP has already support for white-space-treatment, linefeed-treatment and white-space-collapse. But the results of these implementations are only availabe in RTFHandler.endBlock. So i had introduced delaying processing of the FOs until endBlock. Unfortunatelly this makes the code quite complex and buggy, so i want to remove this (of course the rtf module won't support above mentioned attributes any longer). (2) I want to test support for fo:table. This had worked quite good before i introduced the delaying. But now the table-columns get not processed. This will be fixed when (1) is finished. Sorry, i didn't notice this malfunction. (3) Add support for baseline-shift=sub and baseline-shift=super. (4) After all that i have to think about how we can get white-space-treatment, linefeed-treatment and white-space-collapse to work. The difficulty is that RTFHandler handles text nodes in its implementation of FOEventHandler.characters. But at this time FOP's algorithms have not been run. Currently i see three possibilities (just ideas: any comment appreciated): a. Find a solution without delaying processing any FOs. (I don't know how this could work, in spite of implementing the complete algorithm by myself just for the RTFHandler. Maybe this is the worst solution.) b. Find a solution by delaying *every* FO. This would make the FOInputHandler interface useless, because i just had to wait for a particular event (e. g. endPageSequence) and then iterate the passed PageSequence object. Would be a great effort and would introduce the same problems as described in (1). c. Maybe i should not process the text nodes in FOEventHandler.characters but simply add a placeholder to my rtf. When i reach endBlock i have to iterate the passed Block object and search only for FOText objects. The contents of these FOText's have to replace the placeholders. Kind regards, Peter Herweg
Re: Non-implemented props: border-*-precedence
On 23.08.2005 21:01:13 Andreas L Delmelle wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
Back from holiday, and just started work on the collapsing border model
(something I discussed thoroughly with Jeremias a while ago --don't
worry, I'm not going to start all over :-) ) Let me just say that,
Woh! Thanks for taking this not quite trivial task upon yourself.
You know we're going to be heroes if we get the collapsing border model
working!
where earlier on I didn't have a clear idea on what needed to be done
code-wise, right now I'm pretty confident that I will be able to offer
a patch-proposal very soon...
Can't wait!
Note that, although it will mean that part of the border-collapsing
logic will move to the FOTree, I'm still convinced this will make the
related code in layout much easier to follow --but to get the FULL
picture, potential devs will need to look at both the FOTree AND the
LayoutManagers.
That's ok.
On to the topic then: while I'm at it, I would also like to try and
implement the border-precedence properties (and ultimately also
collapse-with-precedence), and have the following questions/remarks
about this:
* What would be the correct property type to use? So far my working
hypothesis is 'EnumNumber', since the value can be an enum (=force), as
well as any integer value. Correct assumption?
I think it would be a normal NumberProperty to which you add enums by
calling addEnum().
...but IANFOTS = I am no FO tree specialist. :-)
+ Another question concerning the possible value of 'inherit': does it
suffice to have Maker.setInherited() set the flag to true (in
FOProperyMapping)?
No, the border precedence properties are not inherited. I think the
inherited value is automatically handled. You don't need to do
anything special.
* Another issue may be that those properties' default values depend on
the type of object they are bound to. The most straightforward way of
dealing with this seems to be to defer determining the actual default
value until the respective FObj's bind() methods...
Does this sound OK, or does anyone see a better way? I know every
Can't tell. Sorry.
PropertyList holds a reference to its parent FObj, but checking the
runtime-type of that FObj for each of the individual PropertyLists
seems a rather cumbersome approach. I somehow feel it would be tidier
if we use the FObj class hierarchy here, and let each subclass decide
for itself what default value to assign if the value is none at that
point (none = the default that is set in FOPropertyMapping)
* In the table objects' bind() methods, I was thinking of reading these
from the property list into a small array, where the indices correspond
to constant values for the four sides --the ones defined in
CommonBorderPaddingBackground?--, so that layout can conveniently
access the precedence values through a method like:
public int getBorderPrecedence(int side) {
return borderPrecedence[side];
}
Comments/suggestions welcome.
That's it for now.
Good luck!!!
Jeremias Maerki
.htaccess file for the old FOP website
FYI, I've added a .htaccess file with the following content to the /www/xml.apache.org/fop/ directory: Redirect /fop/ http://xmlgraphics.apache.org/fop/ I hope this is correct. In case the old website acts up you can still rename the file. Too bad we can't force a local rsync to quickly preview. I'll remove the old website as soon as we've verified that the redirect works properly. Now to the main XML Graphics site Jeremias Maerki
Re: Non-implemented props: border-*-precedence
Andreas L Delmelle wrote: Hi all, Back from holiday, and just started work on the collapsing border model (something I discussed thoroughly with Jeremias a while ago --don't worry, I'm not going to start all over :-) ) Let me just say that, where earlier on I didn't have a clear idea on what needed to be done code-wise, right now I'm pretty confident that I will be able to offer a patch-proposal very soon... Note that, although it will mean that part of the border-collapsing logic will move to the FOTree, I'm still convinced this will make the related code in layout much easier to follow --but to get the FULL picture, potential devs will need to look at both the FOTree AND the LayoutManagers. On to the topic then: while I'm at it, I would also like to try and implement the border-precedence properties (and ultimately also collapse-with-precedence), and have the following questions/remarks about this: * What would be the correct property type to use? So far my working hypothesis is 'EnumNumber', since the value can be an enum (=force), as well as any integer value. Correct assumption? The type should be a number with added 'force' enum. The number property will then coerce a 'force' value into an EnumNumber which is a number that also holds a enum value, but only the property subsystem needs to know that. + Another question concerning the possible value of 'inherit': does it suffice to have Maker.setInherited() set the flag to true (in FOProperyMapping)? * Another issue may be that those properties' default values depend on the type of object they are bound to. The most straightforward way of dealing with this seems to be to defer determining the actual default value until the respective FObj's bind() methods... Does this sound OK, or does anyone see a better way? It was my goal that all the properties should return the correct value from the PropertyList. So if it is possible at all, I would prefer to see that the inheritance issues is implemented in the PropertyMaker classes, instead of the FObjs (or the LayoutManagers). regards, finn
Re: Non-implemented props: border-*-precedence
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 23, 2005, at 22:09, Finn Bock wrote: Andreas L Delmelle wrote: The type should be a number with added 'force' enum. The number property will then coerce a 'force' value into an EnumNumber which is a number that also holds a enum value, but only the property subsystem needs to know that. (Just the man whose input I was looking for :-) ) OK, thanks for clarifying. * Another issue may be that those properties' default values depend on the type of object they are bound to. The most straightforward way of dealing with this seems to be to defer determining the actual default value until the respective FObj's bind() methods... Does this sound OK, or does anyone see a better way? It was my goal that all the properties should return the correct value from the PropertyList. That's what I suspected, hence my question. If we consider inheritance in the following simple case: fo:table !-- no border precedence specified, so all default to 6 -- fo:table-column border-before-precedence=inherit ... / If I interpret the Rec correctly (5.1.4 Inheritance) the column inherits the computed value of 6 from the table (as opposed to getting its own default value of 4). That complicates matters... but maybe only a bit, since I already hinted at the other option: from within the property subsystem, check the runtime-type of the FObj to which the PropertyList is attached, and use that type to determine the default value. My only remaining question is: where exactly should that happen? Can anyone think of another property where the default value depends on the type of object it is attached to? Maybe that'll give me some idea. So if it is possible at all, I would prefer to see that the inheritance issues is implemented in the PropertyMaker classes, instead of the FObjs (or the LayoutManagers). Oh, I definitely think it's possible. It will just take some more time to figure it out. Thanks for your input. Cheers, Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFDC5X1yHTbFO9b8aARAruDAKCvwewDpY29d5Yf5R2zhDyRjq1S3wCgslaj lQd10RWhp9Hvsjj8U82GR5k= =piTN -END PGP SIGNATURE-
