W3C home > Mailing lists > Public > xsl-editors@w3.org > October to December 2009

xslfo20 design notes feedback

From: Dave Pawson <dave.pawson@gmail.com>
Date: Sun, 11 Oct 2009 13:39:01 +0100
Message-ID: <711a73df0910110539v5f36c24cjef7d471bed94ca1b@mail.gmail.com>
To: xsl-editors@w3.org
2009-10-09T09:52:33Z
Comments on http://www.w3.org/TR/xslfo20/
Author: Dave Pawson.
Comments to xsl-editors@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
Received on Sunday, 11 October 2009 12:39:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 11:00:00 GMT