Discussion:
xslfo20 design notes feedback
Dave Pawson
2009-10-11 12:39:01 UTC
Permalink
2009-10-09T09:52:33Z
Comments on http://www.w3.org/TR/xslfo20/
Author: Dave Pawson.
Comments to xsl-***@w3.org

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.


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

typo: "the size of the initial cap MUST then be included in the
blog-progression-direction dimension of the block."


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?


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.

Open issue: 7566. Dynamic behaviour of marginalia areas. Suggest leave
static, since it is the authors decision.


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.

page-viewpot-area. typo.


2.2.2.1 fo:marginalia

A simple example early in this para would make descriptions
clearer.

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.


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.

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.

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

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.


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.

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.

5.1. Fonts.
Look forward to it. Seems far too complex and implementation
dependent as it currently stands.

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

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

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.



Regards DaveP
--
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk
Liam R E Quin
2010-01-14 00:33:43 UTC
Permalink
Post by Dave Pawson
2009-10-09T09:52:33Z
Comments on http://www.w3.org/TR/xslfo20/
Author: Dave Pawson.
Many thanks for your comments!
Post by Dave Pawson
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!
Post by Dave Pawson
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)...
Post by Dave Pawson
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...)
Post by Dave Pawson
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.
Post by Dave Pawson
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.
Post by Dave Pawson
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?
Post by Dave Pawson
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.
Post by Dave Pawson
page-viewpot-area. typo.
Fixed for the next draft, thank you!
Post by Dave Pawson
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.
Post by Dave Pawson
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.
Post by Dave Pawson
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.
Post by Dave Pawson
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.
Post by Dave Pawson
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.
Post by Dave Pawson
3.2 Table header/footer on boundaries
Yes!!!
:-)
Post by Dave Pawson
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.
Post by Dave Pawson
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.
Post by Dave Pawson
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?
Post by Dave Pawson
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....
Post by Dave Pawson
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?
Post by Dave Pawson
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.
Post by Dave Pawson
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/
Dave Pawson
2010-01-14 09:51:24 UTC
Permalink
Thanks for the reply Liam et al.
Post by Liam R E Quin
Post by Dave Pawson
2009-10-09T09:52:33Z
Comments on http://www.w3.org/TR/xslfo20/
Author: Dave Pawson.
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.
From my tech drawing days, the distance between two points
was a dimension?
Post by Liam R E Quin
Post by Dave Pawson
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.
As I said, see a bad example and follow it!
Hope to see it changed in the next draft.
Post by Liam R E Quin
Post by Dave Pawson
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?
"The industry" and a W3C rec are not the same thing. I see no
reason to assume every user of xsl-fo is an ex type-setter?
At least give us a glossary of 'old fashioned' terms to
something more modern? Even if it requires a graphic to
explain it.
Post by Liam R E Quin
Post by Dave Pawson
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?
Just so long as I can do it... though generating a special
page master just for such an odd page seems.... odd?
Post by Liam R E Quin
Post by Dave Pawson
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.
x=horizontal offset from top-left of graphic
y=vert offset from top-left of graphic?

docbook has a solution, where the co xml:id='n' generates the location
of the callout text. Unsure if this would meet your needs.
Post by Liam R E Quin
Thank you for taking the time to view our draft!
The XSL-FO Subgroup.
Welcome, and good luck.

regards
--
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk
Loading...