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 blocks. - 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. J.Pietschmann