This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 11144 - Elastic region extents based on content
Summary: Elastic region extents based on content
Status: NEW
Alias: None
Product: XSLFO
Classification: Unclassified
Component: XSL-FO Requirements (show other bugs)
Version: 2.0 Working Draft
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Mailing list for comments on XSL (XSl-FO)
QA Contact: Mailing list for comments on XSL (XSl-FO)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-25 22:03 UTC by G. Ken Holman
Modified: 2010-11-03 14:18 UTC (History)
0 users

See Also:


Attachments

Description G. Ken Holman 2010-10-25 22:03:11 UTC
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.
Comment 1 G. Ken Holman 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!