You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Jeremias Maerki <de...@jeremias-maerki.ch> on 2006/10/09 10:12:58 UTC
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
Re: XSL-FO 2.0 workshop in Heidelberg next week
Posted by "Peter B. West" <pe...@hp.com>.
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
Posted by "J.Pietschmann" <j3...@yahoo.de>.
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
Posted by Simon Pepping <sp...@leverkruid.eu>.
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
Posted by "J.Pietschmann" <j3...@yahoo.de>.
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
Re: XSL-FO 2.0 workshop in Heidelberg next week
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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
Posted by Nicol Bolas <jm...@comcast.net>.
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
Posted by Nicol Bolas <jm...@comcast.net>.
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
Posted by Vincent Hennebert <vi...@anyware-tech.com>.
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:
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". 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