[Bug 11144] New: Elastic region extents based on content

[b***@jessica.w3.org]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11144

Summary: Elastic region extents based on content
Product: XSLFO
Version: 2.0 Working Draft
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: XSL-FO Requirements
AssignedTo: xsl-***@w3.org
ReportedBy: ***@cranesoftwrights.com
QAContact: xsl-***@w3.org


There are times when the number of lines occupied by the content of the header
or footer cannot be accurately estimated during transformation due to vagaries
of H&J and font metrics used during rendering. At other times it can be a
different number of lines on different pages within a single page sequence.

An example is in the rendering of security classification designations at the
top of pages in intelligence documents. Such designations may run five to
seven lines long because of a complex semantic collection of inclusions and
exclusions expressed for each of a long list of groups of readers. This could
be for the entire page sequence (specified in static content) or even just a
subset of pages (specified in a retrieved marker).

Being able to specify .minimum, .optimum and .maximum components of the before
and after region extents could mimic the specification of the height of a block
container. This would allow (in the example above) a minimum extent used when
the content has a minimally-sized security classification designation and an
elastic growth to accommodate the all of the lines flowed in the region when
the content has a lengthy security classification designation.

[b***@jessica.w3.org]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11144

--- Comment #1 from G. Ken Holman <***@cranesoftwrights.com> 2010-11-03 14:18:51 UTC ---
I recognize that dynamically changing the extent on a per page basis imposes
considerable difficulty and situations similar to "race conditions" when
dealing with retrieved markers changing the extent of the region.

If this is considered by the committee to be too onerous, then a compromise
position regarding this feature would be as follows: disregarding retrieved
markers, the elasticity of the region is determined solely by the content of
the flow defined in the static content. That calculated extent would then be
fixed for all pages in the page sequence, and any retrieved content requiring
more extent would be treated as overflow.

Though it would be nice if it were truly elastic on a per-page basis.

Thanks!