Jeremias Maerki wrote:
If anyone has any requirements for XSL-FO 2.0 which I should bring up at
the workshop in Heidelberg next week, please let me know.

Some rough ideas, unpolished, and without even having had a look at
both 1.1 and the current 2.0 proposals:
- Generalize headers/footers for every block FO, with some control
  of behaviour:
  - render at the start resp. end of each (normal) area generated
    by the FO
  - render only at page breaks, not at start of first resp. end
    of last area
  - render only at start of first resp. end of last area, not at
    page breaks (complement of previous behaviour)
  Needed for the dreaded "continued next page" stuff, which can
  then be used for lists and other blocks too.
- Blocks with multicolumn layout like for body regions (difficult
  to implement if BPD isn't easily determined from external
  constraints, needs probably a memory consuming branch & bound
  algorithm for layout). Needed for newspaper-like and journal
  layouts, for side boxes and such.
- Text floating around areas absolutely positioned on a page.
  This means, among other things, that line areas may be split.
  In multicolumn layouts, the fixed area may affect more than
  one column. Needed for some journal layouts, for focus text
  and images, side boxes and such.
- An element to get the total number of pages in a page sequence
  or for the whole document (instead of formatted page numbers).
  There are probably some generalizations in there, perhaps the
  number of pages which are plastered with normal areas from an
  arbitrary FO. Needed for some legal documents, namely contracts.
- more color models
- Doing something about the "subtotals on this page" and "number
  of foo stuff on this page" problems, preferably without plugging
  a complete spreadsheet language into XSLFO. Perhaps a <fo:calculate
  refer="page/fo-id" select="xpath expression"/> with a possibly
  slightly restricted XPath expression, which selects from the
  referenced page. In case of subtotals, the values to be processed
  should probably be in FO properties (XML attrs) in a canonical
  lexical representation instead of using the formatted content. This
  avoids reparsing the formatted, possibly localized content. XSLT can
  easily generate the additional, redundant data.
- Clarify the hyphenation-char stuff. Is it a char or a string? A
  FO property expression or a shorthand with a special syntax?
- Fix the kludge which allows page-number-format="01" to be
  processed according to common expectations. If done properly,
  this may fix some other problems like the problem with
  hyphenation-char above as well.
- Recommendations on metadata, references to appropriate standards
- Recommendations and/or (non-)contracts on how to handle external
  ressources if they are used multiple times (e.g. images in static
  content). Useful to know how the processor may or must not behave
  if the ressource is dynamically generated on access.

More radical thoughts:
- Deprecate both list and table elements and replace by a single
  unified element set for grid layouts. A content flow is a series
  of blocks, which may contain in a blocks, inlines or a grid of other
- Deprecate mixing inlines and blocks :-P
- Invent controls so that blocks can be broken both in IPD and BPD
  for pagination. This may solve the "break wide tables horizontally" as
  well as the "parallel flow text" problems, unless it is already solved
  this way in 1.1
- Automatic page master switching in case of IPD overflow. This is the
  "switch to landscape for wide tables/images" problem. The difference
  to explicitely switching page masters is that some other content
  before/after the wide FO may flow onto the page, thereby avoiding
  unpleasant white areas on the page before and on the last page of the
  wide element.

Please tell me if you need clarifications on any of the points.


Reply via email to