Created attachment 19610 [details] example supporting the claim Here is an XSL-FO sample fragment and two jpg-s that show how it was rendered by the Antennahous formatter and FOP.
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?
(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.
resetting P2 open bugs to P3 pending further review