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


David A. Wheeler wrote:
> 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.

While adding support for "em" may look easy at the first glance, I'm
afraid that it may not be so easy actually. We have to take into account
that relative lengths like "em" are only meaningful if enough
information is available to convert them into absolute values, and we
have to take into account that they of cause also need to be implemented
if we want to benefit from them. I therefore suggest that we get the
opinion of those who provide ODF implementations whether support for em
units is something they think is doable.

Regarding the conversion issue: The "em" unit specifies a length
relative to a font size. It therefore can only be evaluated for
formatting properties that are applied to paragraphs and text, and even
then there must be a well defined font-height to which the "em" unit may
refer . Which means, we cannot simply add "em" to the list of supported
units, but we have to identify those formatting properties individually
where specifying an "em" unit may be possible. And we have to define
what the reference font height is there.

That's what we actually did for percentage values, that are also not
just a length unit, but where the schema explicitly allows it use for
certain attributes.

Regarding the implementation issue: Current ODF implementation work with
absolute lengths. One option to support "em" would be to convert the
lengths in question to absolute lengths at the time the document is
imported, but I assume that this is not what is expected when asking for
support of "em". What I assume is expected is that the applications
keep the "em" value, and re-calculates the length dynamically if the
font-height the length is relative to changes. In order to support that,
office applications have to adapt their layout algorithms and user
interfaces. So, the request to support "em" results in a feature
request to support relative lengths for certain formatting properties.

Taking it all together: While adding support for "em" is a very
interesting idea and while I assume that it may be implementable for at
least a few properties, I believe that we need some research and 
implementation experience first before we can decide whether this 
something we can do for the 1.2.

Best regards


Michael Brauer, Technical Architect Software Engineering
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500

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