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=41633>. 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=41633 ------- Additional Comments From [EMAIL PROTECTED] 2007-02-17 14:15 ------- (In reply to comment #2) > -> implement necessary parts in fop.layoutmgr.inline.InlineLayoutManager > > WRT the latter: > Does anyone know what the expected behaviour is if the fo:inline's content exceeds the specified or > implied inline-progression-dimension.maximum? I'd expect the inline to grow with a warning, since no > clip/overflow apply here and they're non-inherited, but I'm not 100% certain... The behaviour would be > different than for the (as yet unimplemented) fo:inline-container, where the content could be clipped? I'd agree with your view here. It's something similar to the b-p-d on table-row where growing beyond the specified maximum does not clip, but instead grows and only issues an error message. Frankly, I'm surprised to see b-p-d and i-p-d applicable to inline at all. After all it's the only FO which generates normal areas, not viewport or reference areas that i-p-d and b-p-d applies to. That's weird IMO! IMO it would sufficed to let inline-container handle this case. Too bad, we haven't implemented that one, yet. -- 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.
