Re: Fix for fo:leader
J.Pietschmann wrote: Yeah, lets leave that command line stuff alone. btw, what about moving it to CLI in the trunk? I've been thinking about it, it seems to me CLI doesn't support such optional options like our -fo, but the rest looks okay. Certainly an idea. However, I'd like to have the API proposal in the wiki discussed before, the CLI would then have to be rewritten to a large part. Sure. Does it should eb separate wiki or part of Avalonization? Is there something like getopts/gengetopts for Java? Hmm, that's what I meant - not a CLI, but the CLI, part of Jakarta Commons, see http://jakarta.apache.org/commons/cli/index.html. -- Oleg Tkachenko Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Fix for fo:leader
Oleg Tkachenko wrote: Yeah, lets leave that command line stuff alone. btw, what about moving it to CLI in the trunk? I've been thinking about it, it seems to me CLI doesn't support such optional options like our -fo, but the rest looks okay. Certainly an idea. However, I'd like to have the API proposal in the wiki discussed before, the CLI would then have to be rewritten to a large part. Is there something like getopts/gengetopts for Java? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Fix for fo:leader
J.Pietschmann wrote: May be creating -outfo param for fop.bat/sh is better? Certainly, but this is real work. Even better would be fop -xml foo.xml -xsl foo.xsl -fo foo.fo but this requires even more work (because the FO file is no longer automatically an input)/ Yeah, lets leave that command line stuff alone. btw, what about moving it to CLI in the trunk? I've been thinking about it, it seems to me CLI doesn't support such optional options like our -fo, but the rest looks okay. -- Oleg Tkachenko Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Fix for fo:leader
Oleg Tkachenko wrote: - I want to add the Xalan.bat/.sh May be creating -outfo param for fop.bat/sh is better? Certainly, but this is real work. Even better would be fop -xml foo.xml -xsl foo.xsl -fo foo.fo but this requires even more work (because the FO file is no longer automatically an input)/ Or at least name that batch in more liberal way, xslt.bat/sh Has been discussed and rejected (although this is my favorite). or even transform.bat/sh (as XEP has). Um, a bit long but certainly possible. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Fix for fo:leader
J.Pietschmann wrote: Christian Geisert wrote: problems if leaders are mixed with graphics on the same line Did this work with older releases? Probably not. There is a potential for line overflows, dropped text and missing spaces. IIRC in the current code space before leaders was always dropped. If not it isn't really necessary to fix this IMHO. Hmm. Not that I don't want to see bugs get fixed but I'd rather like to see us working in HEAD (and get all the things done there) As I would like to do the release *soon* we could add this to the release notes. Please delay for another day, I'll heve to get rid of an few issues: Sure. Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Fix for fo:leader
Peter B. West wrote: public final static int JUSTIFY = 54; This indicates a missing break in the JUSTIFY case... bingo, right! I'm humilated. :-/ J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Fix for fo:leader
J.Pietschmann wrote: - I want to add the Xalan.bat/.sh May be creating -outfo param for fop.bat/sh is better? Or at least name that batch in more liberal way, xslt.bat/sh or even transform.bat/sh (as XEP has). -- Oleg Tkachenko Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Fix for fo:leader
J.Pietschmann wrote: - I get a value of 54 for the text align occasionally. I suspect this is "inherit". Does one of the property gurus know what this means offhand? Joerg, My initial response - no, but try me with '42'. Later... In .../fo/properties/Constants.java from fop-0_20_2-maintain (not built for a while): public final static int INHERIT = 51; public final static int INSET = 52; public final static int INTEGER_PIXELS = 53; public final static int JUSTIFY = 54; Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ "Lord, to whom shall we go?" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Fix for fo:leader
Christian Geisert wrote: problems if leaders are mixed with graphics on the same line Did this work with older releases? Probably not. There is a potential for line overflows, dropped text and missing spaces. IIRC in the current code space before leaders was always dropped. If not it isn't really necessary to fix this IMHO. Hmm. As I would like to do the release *soon* we could add this to the release notes. Please delay for another day, I'll heve to get rid of an few issues: - Trace statements. This is easy :-) - I get a value of 54 for the text align occasionally. I suspect this is "inherit". Does one of the property gurus know what this means offhand? - I want to add the Xalan.bat/.sh J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Fix for fo:leader
J.Pietschmann wrote: Hi, I more or less fixed the leader generation causing all sorts of problems and specifically #15936. Some issues: - The state machine detecting line breaks is brittle. It will probably cause problems if leaders are mixed with graphics on the same line I'm again tempted to do something about this. Did this work with older releases? If not it isn't really necessary to fix this IMHO. - If the source contains whitespace at the end of the text in a block, the last line of the block will have a space appended. Therefore Entry 32 will not be properly right aligned. I have no idea how to get rid of said space. Should we simply recommend to avoid whitespace at the end of blocks if alignment is critical? As I would like to do the release *soon* we could add this to the release notes. Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Fix for fo:leader
Victor Mote wrote: Unless the spec indicates something different, my naive solution would be to distribute it in proportion to their pre-existing (optimal) size. The spec basically leaves it to the implementation. There is only a vague comment "User agents may choose to use the value of 'leader-length.optimum' to determine where to break the line" (sect. 7.20.4, nicely repeated in Leader.java) So with 3 leaders, A, B, & C: new sizeA = sizeA + (sizeA / (sizeA + sizeB + sizeC) * slack) Compute the above for each leader, limiting each to the max. If any max out, they are completed, and the excess returns to the pool. Repeat this for remaining leaders until excess is used up or all of them max out. Don't apply your rounding until the end. If all of them max out, it would seem reasonable to distribute any remaining slack equally as space between the leaders. This is an excellent formulation of what was only vaguely forming in my head. Thanks! J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Fix for fo:leader
J.Pietschmann wrote: >3. Distribute any slack space left equally on the resizable spaces > (subject to round off, should use a Bresenham-like algo for > perfection :-) >Can anybody come up with an algorithm to distribute slack space >over several leaders which can deal with arbitrary combinations >of opt-max intervals? Unless the spec indicates something different, my naive solution would be to distribute it in proportion to their pre-existing (optimal) size. So with 3 leaders, A, B, & C: new sizeA = sizeA + (sizeA / (sizeA + sizeB + sizeC) * slack) Compute the above for each leader, limiting each to the max. If any max out, they are completed, and the excess returns to the pool. Repeat this for remaining leaders until excess is used up or all of them max out. Don't apply your rounding until the end. If all of them max out, it would seem reasonable to distribute any remaining slack equally as space between the leaders. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
