[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] Unicode relative spaces -- Was, proposal for new position and space attributes for the list level
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]