Re: [office] Unicode relative spaces -- Was, proposal for new position and space attributes for the list level

["Dave Pawson" <dave.pawson@gmail.com>]

On 20/02/07, marbux <marbux@gmail.com> wrote:

> I've been working on a proposal that might impact how horizontal
> spaces are handled in lists. I had hoped to put in another day on it,
> but y'all have forced my hand. :-)
>
>
> The ODF specification currently lacks support for the Unicode em-based
> relative typographic spaces. Adding such support to the specification
> is one of my goals.

And now mine.



>
> ODF 1.1 section 16.1 currently provides in relevant part:

> length
>
> A (positive or negative) physical length, consisting of magnitude and
> unit, in  conformance with §5.9.11 of [XSL:FO]. Supported units are
> „cm", „mm", „in", „pt" and „pc". Applications *shall* support all
> these units. Applications *may* also support "px" (pixel). Where the
> description of an attribute explicitly states that pixel lengths are
> supported, applications  should support them.
>
> Examples for valid lengths are "2.54cm" and "1in".
>
> ===============
>
> So we apparently have only absolute and margin percentage positions
> for horizontal measurements currently supported in the spec. That
> seems to me as though it could lead to issues in transformations.
> XSL:FO section 5.9.11.28 calls for use of the em-based system as the
> unit of measurement for relative units, but despite the citation to
> that section in the ODF spec, ODF does not reflect XSL:FO in that
> regard. See <http://www.w3.org/TR/2006/PR-xsl11-20061006/#d0e5490>.
>

I'd provide another use case. Not as a typographer, but from a user
view. If preparing content for a low vision user, the font size is required
to be modified. Transforms to xsl-fo present no problem, styles can
be replaced by attribute-sets which are all relative, based on a baseline
size.

If spaces cannot be 'scaled' in the same way, this presents a barrier
to accessibility. My organisation has customers needing 24 point print
and even larger. If a space retains its size when scaled from (some people
generate 8 and 10 point documents) small print, the inter-word gaps, list
spacings etc become almost invisible.

Hence I'm very strongly in favour of adding the em as a unit of length.




 Use of the typographic spaces is recommended by the
> W3C Web Content Accessibility Guidelines Working Group in their best
> practices guide for CSS stylesheets.
> <http://www.w3.org/WAI/GL/css2em.htm>. That page recommends that type
> sizes and horizontal spaces be expressed in CSS stylesheets in ems
> (scalable) rather than using percentages or absolute measurements
> unless there is a specific requirement for non-scalable widths.

I've yet to see a justifiable one if accessibility is considered.


<snip/>




> [1] In my opinion, the ODF specification also needs a
> <text:space-to-fill> tag to indicate the insertion point for space
> needed to justify a line left and right. Where two or more tags occur
> per line, the implementing application should divide the space to fill
> equally in the specified position. For example, take the common book
> header line that includes a page number, the chapter title, and the
> book title:

I'm guessing this is a description of the \Latex rubber space,  or
http://www.w3.org/TR/2004/WD-xsl11-20041216/#fo_leader
the leader.

This is very useful in layout. Especially two in a line to generate
left/center/right
headers.

(and many thanks for the background information.)


regards




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