W3C home > Mailing lists > Public > xsl-editors@w3.org > January to March 2010

Re: xslfo20 design notes feedback

From: Liam R E Quin <liam@w3.org>
Date: Wed, 13 Jan 2010 19:33:43 -0500
To: Dave Pawson <dave.pawson@gmail.com>
Cc: xsl-editors@w3.org
Message-ID: <1263429223.4159.1278.camel@desktop.barefootcomputing.com>
On Sun, Oct 11, 2009 at 01:39:01PM +0100, Dave Pawson wrote:
> 2009-10-09T09:52:33Z
> Comments on http://www.w3.org/TR/xslfo20/
> Author: Dave Pawson.
> Comments to xsl-editors@w3.org

Many thanks for your comments!

> Assumption. I agree with or am neutral on any para not mentioned
> explicitly in this set of comments.
> 
> 2.1.1. Very supportive. Excellent inclusion.
Thank you!

> 2.1.1.1  Open issue: 7562. font-size='auto'. I find it unclear how
> this is an issue? It seems quite logical.

In some cases "open issue" in the draft reflects places where the
document isn't fully fleshed out, or where the Working Group
didn't have strong agreement (I don't think there are any
strong disagreements)...

> typo: "the size of the initial cap MUST  then be included in the
> blog-progression-direction dimension of the block."
Fixed for the next draft, thank you!
(actually blog-progression-direction sounds interesting...)

> 2.1.1.2 This seems a form of syntactic sugar for a negative value of
>           2.1.1? Which makes it unclear what a negative number would
>           indicate? Would that make a negative value for
>           initial-cap-lines-before the same as a positive value for
>           initial-cap-lines? Lots of room for confusion?

No, because an initial cap can go both above and below the first
line of text at the same time.

> 2.2 Excellent addition! Very clear requirement.
> 
> Open issue: 7564
> 
> "Should users be able to direct marginalia to another region, or only
> to a predefined marginalia area? "
>    IMHO, no. Keeps a clear definition of marginalia.
Thank you for your feedback, noted.

> Open issue: 7566. Dynamic behaviour of marginalia areas. Suggest leave
> static, since it is the authors decision.
What if the author wants the marginalia area to be there only on
pages that have marginalia?

> 2.2.1.3 "distance"
>    Perhaps better named as 'dimension', since that is how it is
>    described? Even when it is a percentage this makes more sense.

We'll consider it; note that the property is not naming a dimension,
but is giving a distance between two points.

> page-viewpot-area.   typo.
Fixed for the next draft, thank you!

> 2.2.2.1 fo:marginalia
> 
>     A simple example early in this para would make descriptions
>     clearer.

Agreed, thanks.  There are examples in the requirements document,
but we should put one or more here too.

> 2.2.2.2 I'm unsure how I'd relate this marginalia to region-body
> content for alignment purposes. Is it the
> 'marginalia-destination-area'? Again, an example might clarify.
You put an fo:marginalia in the flow, with the
marginalia-destination-area
property set to the appropriate destination area, and the
marginalia-relative-align property can be set to baseline, before or
after
to specify the alignment of the resulting area in the margin with the
anchor in the running text.

We need to add an example.

> 2.3.2.1 block-progression-unit
>      I'm unsure about this one until I see it implemented. I can see
>      it looking really quite ugly with gross dimensioning.
Yes, you can certainly do ugly things with it; the primary use case is
for reducing problems with 'back-up" on printed pages, when printers
use really thin paper. It also may improve the appearance of facing
pages, by having the lines of text aligned with each other.

> 2.3.3 Vertical alignment within a page or column
>       Very happy to see that appearing!
> 
> Open issue: 7567 should vertical justification also apply to
>      fo:table-cell, for instance? What other areas? Yes, IMHO.

Thank you for that.

> 3.1.1 Considerations
>     particularly decimal alignment. suggest this be limited to a
>     single page (page based media) due to performance hits.

At one time people argued that HTML should not have
tables because they would render slowly.  They do, compared
to plain text, but sometimes you need what you need.

> 3.2 Table header/footer on boundaries
>     Yes!!!

:-)

>    An alternative for consideration?
>    ... if (X='boundary-condition1')
>          alternative content 1
>        elif (X='boundary-condition2')
>          alternative content 2
> 
> That way, it doesn't need to be restricted to table headers?
>    Could be a section/chapter head etc. Even a para.

Alternate content may also relate to copyfitting, and we are
also looking at expanding the expression language, so this
idea may well work better, thank you.

> 3.2.6 Spanning cell over all row and columns
>       Zero as a value seems to be a case of seeing a bad example and
>       following it? 'all' seems far more practical and intuitive. The
>       terminology for properties is becoming depressingly obtuse.

Thank you - we agree with you.  Unfortunately, HTML already uses zero
for this purpose; for now, we have noted this as an open issue for
the next publication of our draft.

> 3.4.1 fo:spread-page-master
>       Very welcome!
> 
> 3.5 Bleeds and Trim
>      More weak, old fashioned terminology? It may be accurate and
>      appropriate for a typographer and setter. Is it appropriate for
>      the user of this specification? IMHO - no.

We do have requirements to support bleed and trim, coming from
people doing that old-fashioned paper stuff :-)  The terms
are standard in the industry and very much in use today.  Or
are we misunderstanding you?

> 5.1. Fonts.
>    Look forward to it. Seems far too complex and implementation
>    dependent as it currently stands.
We can't promise that it will get simpler....

> 7. Images.
>    Ability to centre an image vertically on a page. Here or earlier?
>    I.e. Leave a header and an image as an odd page decoration or to
>    break some sort of page sequence
Wouldnt you do this in the page master?

> 7.4. Callouts
>      yes please! 'Ensure positioning, so I can label aunt Izabel and
>      uncle Joe.

Ah, 6.1.2. Yes, we don't have a good solution for this yet, beyond
an SVG overlay.

> 8.3. I'll guess others have asked for this... How to balance what is
> done here vs what properly belongs in printer setup and properties?
> IMHO this all belongs in printer properties.

Ah, 8.3 in requirements... print-specific properties... yes,
there's demand for it, but we have to balance what we do in XSL and
what is done with JDF.

Thank you for taking the time to view our draft!

The XSL-FO Subgroup.

-- 
Liam Quin, W3C XML Activity Lead, http://www.w3.org/People/Quin/
http://www.holoweb.net/~liam/ * http://www.fromoldbooks.org/
Received on Thursday, 14 January 2010 00:33:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 14 January 2010 00:34:07 GMT