OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [office] Adding support for "em" measurements


I support "em" as a measurement in that I do a lot of design work based on ratios to the current point size.

As for measurements in points, most software now uses the "Adobe point" (i.e., 1/72 inch, where 1 inch is defined (by law in the U.S., at least) as 2.54 cm). The difference between the "Adobe point" and the Anglo-American printers' point is fairly small, as well as being a subject of diagreement. If you want to compensate, you could take Don Knuth's RSU (rediculously small unit) as a starting point. 

As for anything UNICODE/ISO 10646 might say about the subject, it's technically outside of their scope (which is limited to abstract glyphs associated to with code points). Things having to do with typographic measure belong in SC34 or TC130. (SC34 has a new project having to do with documentation of the capabilities of rendering devices; we'll have to see what stand it takes on this matter.)

Jim Mason

-----Original Message-----
From: David A. Wheeler [mailto:dwheeler@dwheeler.com] 
Sent: Tuesday, February 20, 2007 11:40 AM
To: office@lists.oasis-open.org
Subject: [office] Adding support for "em" measurements

Marbux:
> The ODF specification currently lacks support for the Unicode em-based 
> relative typographic spaces....
> 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)...

+1 for adding "em" to the list of supported units; I think we should do that for version 1.2.  It's easily done, and will make it easier to interoperate with other formats that use "em"s.

In cases where the font is changing size, I'd interpret that as "whatever font is active at that moment".   (Is there a case where there's NO active font yet?  If so, we could recommend using Paragraph "Default"s, and fail if there isn't one.)

> [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

Hmm - that seems odd. Is there a better way?

(BTW, that's an incredibly long email... I don't think you needed to get into all that!).

--- David A. Wheeler


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]