Re: Additions to FOP/LIMITATIONS page
Clay Leeds wrote: - Using page-number-citation for Page x of n using the ol' fo:page-number/ of fo:page-number-citation ref-id=endofdoc/ combined with a fo:block id=endofdoc/ at the end of the fo:region-body trick This is a FO trick, hardly anything related to limitations. BTW, IIRC, fo:table requires table-layout=fixed. However, on the /fop/limitations.html example, it's missing that. You'd be amazed how many known limitations are missing from the limitations page: - dropped Text if inline FOs fall near page boundaries - dropped lines if inline images and other elements cause page breaks - fo:inline is basically ineffective, can only be used as property holder like fo:wrapper - fo:character lacks basically all features you'd want to use it for - no proper vertical alignment in lines, most of the values aren't recognized - no handling of different font sizes within the same line - linefeed-treatment not implemented - whitespace-treatment not implemented - improper line breaking - improper hyphenation - no implementation for the advanced hyphenation controls - no reparenting for markers after retrival - retrieve-marker-position only really works to first-starting-within-page and occasionally for last-ending-within-page, everything else is pure coincidence - retrieval of wrong markers in case page rendering is deferred - footnotes are not broken correctly - footnotes don't mix well with multi-column layout - leaders may be misaligned (even after the recent fixes) - conditional spaces and borders are not implemented - margins are not properly implemented - forced page breaking is not properly implemented - the space resolution algorithm mandated by the spec is not implemented - collapsed table borders are not properly implemented - row spanning cells can cause interesting effects, use with care This does not include the elements and properties well known to be not implemented as well as small bugs on the other end of the spectrum, like referring to ids on table cell can cause NPEs. Does FOP do that (assume the obvious, tell me about it, and slap my wrist) in other places as well? Yes, sometimes. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Additions to FOP/LIMITATIONS page
J.Pietschmann wrote: You'd be amazed how many known limitations are missing from the limitations page: Judging by the length of this list (and the quality of some of these... ;-), you're right. I am amazed. snip I've found that occasionally text-align=center|right doesn't always work the way I expect (often displacing the text by one or two #160;). In these instances, I've found that placing text inside of a problematic fo:block, inside a fo:inline, fixes the problem. Here's a sample of where I had to do this: fo:table-cell text-align=right display-align=center padding-bottom=1pt padding-top=2pt fo:block color=#ff display-align=center font-weight=bold fo:inline text-align=right display-align=centerREDUCTION/fo:inline /fo:block /fo:table-cell snip - no proper vertical alignment in lines, most of the values aren't recognized also, vertical-align and it's horizontal brother text-align appear to only be functional with text. - no handling of different font sizes within the same line That may be true (you should know!), but I use the following to decrease the whitespace between two words (while retaining something of a nowrap): fo:inline font-weight=boldAdjustorfo:inline font-size=4pt#160;/fo:inlineID:/fo:inline snip This does not include the elements and properties well known to be not implemented as well as small bugs on the other end of the spectrum, like referring to ids on table cell can cause NPEs. It seems like many/most of these would find a good home in the limitations page. So, what's keeping these jewels of information (which surely must be annoying the bejeebers out of some developers) out of the public eye? Anyway, thanks for the highlights! I've appropriately flagged your message as a place to look when I need to know why something I'm expecting to work isn't actually working. ;-) -- Clay Leeds - [EMAIL PROTECTED] Web Developer - Medata, Inc. - http://www.medata.com PGP Public Key: https://mail.medata.com/pgp/cleeds.asc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Additions to FOP/LIMITATIONS page
Clay Leeds wrote: I've found that occasionally text-align=center|right doesn't always work the way I expect (often displacing the text by one or two #160;). If you have a space at the end of the text, like fo:block REDUCTION /fo:block the space will be appended to the line and cause misalignment for centering and right alignment. Use fo:block REDUCTION/fo:block instead. The fo:inline works too, because then the whitespace after the inline is somehow dropped. This is partly due to the improper line breaking I quoted. Mind you, the spec isn't really clear whether spaces at the end of a block are dropped by default (the relevant part is probably the omit-at-line-break trait which causes spaces to be stripped when text breaks across lines, however, it is not really spelled out whether the beginning and the end of a block have to be considered a line break for this purpose too). also, vertical-align and it's horizontal brother text-align appear to only be functional with text. They should work for inline graphic too. A graphic is, unfortunately, always aligned a bit odd (I think top), so you should only inline images which are roughly of the line height or smaller. The only values recognized for vertical-align are sub and super, everything else from section 7.13 is completely ignored. - no handling of different font sizes within the same line Try fo:block font-size=10ptfoo fo:wrapper font-size=30ptbar /fo:wrapper/fo:block It seems like many/most of these would find a good home in the limitations page. So, what's keeping these jewels of information (which surely must be annoying the bejeebers out of some developers) out of the public eye? Mainly because the list changes frequently and nobody cares whether it is up to date. An outdated limitations list can be even more annoying than none at all. Also, long lists of feaures are better for publicity than long lists of misfeatures. And most people wouldn't notice anything anyway, no need to scare them away. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
