Re: XSL-FO 2.0 workshop in Heidelberg next week
Thanks for all the feedback. I haven't been able to go through all of it, yet, but I have printed it out and will discuss it with Luca on Tuesday evening. We'll probably have to assign some priorities as the day will be over very quickly. I doubt we'll be able to go into much detail. Over all my main topics are: - Finding ways to improve the wording in the spec and to minimize room for interpretation. - (Again) suggest a comprehensive test suite which contains annotations for the various feature thus complementing the spec with an additional, very concrete source of information. - Trying to convince all implementors to adhere to the spec. :-) Some of my topics can also be found in your points (metadata usage, color models, etc.). One new feature I have on my list: - Propose some kind of fo:inline-alternatives which allows specification of different representations of a value. The implementation will then select the representation which fits best into the available room. This is something that is useful for business documents where you have little room to place your content and abbreviations are possible. This is to avoid tedious computations at the XSLT stage. I'll compile a report after the workshop. On 09.10.2006 10:12:58 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. Deadline > 2006-10-16 so I have time to prepare. Jeremias Maerki
Re: XSL-FO 2.0 workshop in Heidelberg next week
Oh, I found a good one in the 1.1 spec. Remove page-position=last/only; there is no way to guarentee that it can work. There is no algorithm that can make it work in the general case. Sure, if the last page and the page that would have been there had it not been the last page used the same region content rectangle, then it's fine. But the user is not so constrained; the user can use any page. If the content is small enough that it fits on the not-last-page version, but is too big for the the last page version (or, in 1.1's case, doesn't even provide a region body that is in this flow's region map), then it can't be the actual last page, as you need another. It's fundamentally impossible in the general case. If they can't be removed, then at least provide some warning to the user about unresolvable cases. And provide some specified behavior from the FO processor in this case (chop off the content, etc). I suppose one could cheat by adding a blank last page ;) But I imagine the user would be pretty upset by that... -- View this message in context: http://www.nabble.com/XSL-FO-2.0-workshop-in-Heidelberg-next-week-tf2408511.html#a6751725 Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: XSL-FO 2.0 workshop in Heidelberg next week
Simon Pepping wrote: > Block content in inline content is the natural organization of displayed formulas and tables. Demanding that FO generating stylesheets separate them is moving the burden back to them. I am not in favour of that. Ah, I start seeing the point. You might have add images as well. However, I have to agree with Peter about the clarification of the expected behaviour. In particular, is the line before the block adjusted according to text-align or to text-align-last? It could be argued both ways. And I still think that mixing inlines and blocks significantly complicates the FO processor implementation. :-P J.Pietschmann
Re: XSL-FO 2.0 workshop in Heidelberg next week
On Tue, 2006-10-10 at 12:42 +0200, Simon Pepping wrote: > On Mon, Oct 09, 2006 at 11:45:08PM +0200, J.Pietschmann wrote: > > 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. > > > > More radical thoughts: > > - Deprecate mixing inlines and blocks :-P > > Block content in inline content is the natural organization of > displayed formulas and tables. Demanding that FO generating > stylesheets separate them is moving the burden back to them. I am not > in favour of that. > > Regards, Simon > It would, however, be useful if the editors could get their story straight on this. I've never been able to work out exactly what was the expected behaviour of blocks within inlines. Peter
Re: XSL-FO 2.0 workshop in Heidelberg next week
On Mon, Oct 09, 2006 at 11:45:08PM +0200, J.Pietschmann wrote: > 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. > > More radical thoughts: > - Deprecate mixing inlines and blocks :-P Block content in inline content is the natural organization of displayed formulas and tables. Demanding that FO generating stylesheets separate them is moving the burden back to them. I am not in favour of that. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.eu
Re: XSL-FO 2.0 workshop in Heidelberg next week
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. Deadline 2006-10-16 so I have time to prepare. Luca, are you going, too? How do you travel? Yes, I'm going. I think I'll travel by train, but I haven't fixed all the details yet. I was waiting for more precise news to appear on the workshop site, but there have been no recent updates ... I should really start deciding anyway! I think I'll end up arriving the day before the workshop, and probably leaving the day after it, so we could find plenty of time to chat about fop. Regards Luca
Re: XSL-FO 2.0 workshop in Heidelberg next week
Jeremias Maerki a écrit : > 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. Deadline > 2006-10-16 so I have time to prepare. Jörg's comments just reminded me of something I think is missing in the current spec: Enable the "compact box" scheme specified in CSS2: if an inline box is short enough to fit in the margin of the following block box, it is put in the margin; otherwise, it is transformed into a block box to be put before the following block box. That allows to mimic the DT/DD items of HTML: termthe definition of the term "term". The definition of the term "term". The definition of the term "term". The definition of the term "term". The definition of the term "term". Another term too long to fit in the margin the definition of the "too long term". The definition of the "too long term". The definition of the "too long term". The definition of the "too long term". Unless I'm wrong, I don't think this is currently possible to do that in XSL-FO. Thanks, Vincent
Re: XSL-FO 2.0 workshop in Heidelberg next week
A few. I do think, when proposing these things, it is important to remember that XSL-FO is not intended to implement all possible typsetting operations, that it still needs to remain "easily" implementable. I guess one question I have is how different should XSL-FO 2.0 be from 1.1? Should it just be some minor changes/fixes, or are they considering some pretty substantial changes? Because if it is the latter, I've got some suggestions with that regard: * Eliminate entirely the notion of unbounded page lengths/viewports. That is, browser-like viewing with scrollbars and such. This, among other things, has the effect of making the viewport stuff unnecessary and substantially clarifies the specification and any descriptions thereof. The primary purpose of XSL-FO is for paged media; we already have tools for unpaged media. * Seriously reconsider having block-level elements and inline elements be interleaved. It probably makes FO processor implementation a bit more difficult. Plus, it's just needless; you can easily wrap that inline stuff in a block. * Page specification (simple-page-master) could be made so much more intuitive. It is far too easy to put a header in the middle of your content by accident, and while I support that functionality, it should not be the default. If it's just minor changes: * Allow for lists that periodically reverse the left/right (IPD, technically) positioning of the blocks. Generally, to allow for lists that alternate one after another which side the content and which side the list item is on. It would, also, be useful to alter other attributes when doing this. There is a FO-processor that has an extension to do it, but I forget its name. This alternation would likewise be reset at every page/region break. * In that same vein, similar alternation patters for table row properties that reset at page/region breaks. This would allow for alternate color backgrounds, but that always start (wherever they are visible) on a particular boundary. * FO 1.1 added the ability to have multiple body regions on a page, and a flow map to dictate how data flows from one to another. What was not added were appropriate keeps/breaks to deal with the possibility of switching to a new region without leaving the page itself. This distinction should be made. * The ability to specify 2-up/4-up/etc style page generation. This cannot be done even with FO 1.1's multiple body regions, because one lacks the ability to have multiple static content regions on a page, as well as where those regions get placed. Something like a "multiple-page-master" that physically shrinks several simple-page-masters onto a single page. * Footnote numbering/indexing per page or region, rather than leaving it up to the FO document. The "numbering", of course, needs to be flexible and user-definable (perhaps as a sequence of character possibilities that is referenced). * Meta-data needs to be handled in some way. A section, perhaps just after the page master section, would be ideal. * Please give us a RELAX NG+Schematron schema for XSL-FO. It would be so incredibly useful to have such a thing. -- View this message in context: http://www.nabble.com/XSL-FO-2.0-workshop-in-Heidelberg-next-week-tf2408511.html#a6727041 Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: XSL-FO 2.0 workshop in Heidelberg next week
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 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
XSL-FO 2.0 workshop in Heidelberg next week
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. Deadline 2006-10-16 so I have time to prepare. Luca, are you going, too? How do you travel? Jeremias Maerki
