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 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Platform|PC |All Summary|inline-progression-dimension|*-progression-dimension on |on inlines does not work |inlines not implemented |(v.0.93) | Version|0.93 |1.0dev ------- Additional Comments From [EMAIL PROTECTED] 2007-02-17 03:17 ------- Took a closer look, and neither block- nor inline-progression-dimension are supported on fo:inline, so changed the bug summary to reflect this. Steps to take: -> activate related property code in fop.fo.flow.Inline.java Related properties are currently commented out/unused. This goes for inline- and block-progression-dimension, height and width. Those properties need to be merged anyway, to avoid storing the very same value twice: proposal here would obviously be to use native XSL properties as the instance members, and if necessary, implement accessor methods for height/width. -> 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? -- 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.
