OASIS Open Document Format for Office Applications (OpenDocument) TC

On 2/19/07, Oliver-Rainer Wittmann - Software Engineer - Sun
Microsystems 

On 20/02/07, marbux 

On 20/02/07, marbux 

Marbux,

I am not entirely sure as to what is being proposed here. First of all, 
there is no problem with using the unicode *-space characters in 
OpenDocument text content. It is of course the responsibility of the 
application displaying the document to render those correctly.

At what places in ODF exactly would you want to support horizontal 
measurements based on the font-size and what would be the 
reference-size? Are you going to implement this or is anyone else going to?

Best Regrads,
Lars


marbux wrote:
> On 2/19/07, Oliver-Rainer Wittmann - Software Engineer - Sun
> Microsystems 

Sorry for the delay in responding. I had some catching up to do on
more urgent tasks.

[more inline]

On 2/20/07, Lars Oppermann 

Marbux,

thank you very much for thesr clarifications.

marbux wrote:
> Sorry for the delay in responding. I had some catching up to do on
> more urgent tasks.
> 
> [more inline]
> 
[..]

> 
> I said earlier that I did not know of anyone who planned to implement
> this at this time. That is why at this point, I am not asking that the
> em-based system of measurements actually be added to the spec, only
> that we not make changes, e.g., in lists, that would get in the way of
> adding them later.

Do you have any hints that the current list proposal would conflict with 
adding em-based measures? Or do you would only like to see that the 
editors of the proposal check that?

I'm asking because we are discussing the list proposals for a very long 
time now, so I think we should resolve any remaining issues as soon as 
possible, so that we can vote on the proposal.

Best regards

Michael

On 2/22/07, Michael Brauer 

Hi Marbux

Thanks for the clarification.

I played around a bit with emspaces inserted into the text-content of an 
ODF file in OpenOffice.org and it seemed to work well. So the default 
font-face that I used obviously had the proper metrics and such.

marbux wrote:
> On adding support for the em-based system of measurement to the spec,
> I'm not sure  I understand your question as to reference size. For the
> currently selected font, the reference size would be the horizontal
> width equal to the font's vertical type size in points, exclusive of
> any vertical padding between lines. So in 9 point type the em is 9
> points wide, in 18 point type it is 18 points wide, etc.

With reference-size, I meant the actual point-size with which the 
em-space gets rendered when the document is viewed. This is obvious in 
some parts of documents like paragraph. So if there was a feature to 
specify the leading indent of a paragraph in em-spaces, the actual size 
of the space would result from the font-size attribute of the 
paragraph-style.

For other parts of a document, this is more difficult. For instance page 
margins - There is not normally a font-size associated with a page. 
Paragraph styles are associated with master-page styles which are linked 
to page-layouts, but not the other way round (see sect. 2.8, 14.3 and 14.4).

I can see how em-based horizontal measurements can be useful in text 
documents. However, just calling to allow them wherever cm, in, pt etc. 
are allowed is not feasible. From reading your clarifications I can see 
that you don't want to do this.

Bests,
Lars

On 23/02/07, Lars Oppermann 

marbux wrote:
> > On adding support for the em-based system of measurement to the spec,
> > I'm not sure  I understand your question as to reference size. For the
> > currently selected font, the reference size would be the horizontal
> > width equal to the font's vertical type size in points, exclusive of
> > any vertical padding between lines. So in 9 point type the em is 9
> > points wide, in 18 point type it is 18 points wide, etc.

Lars Oppermann:
> I played around a bit with emspaces inserted into the text-content of an 
> ODF file in OpenOffice.org and it seemed to work well....
> With reference-size, I meant the actual point-size with which the 
> em-space gets rendered when the document is viewed. This is obvious in 
> some parts of documents like paragraph....
> For other parts of a document, this is more difficult. For instance page 
> margins - There is not normally a font-size associated with a page. 
> Paragraph styles are associated with master-page styles which are linked 
> to page-layouts, but not the other way round (see sect. 2.8, 14.3 and 14.4).
> 
> I can see how em-based horizontal measurements can be useful in text 
> documents. However, just calling to allow them wherever cm, in, pt etc. 
> are allowed is not feasible. From reading your clarifications I can see 
> that you don't want to do this.

Yes, I think we're all seeing the same problem: em-measurements require that you know what the current font size _is_.

But I think it'd still be very useful to include this measurement system; there are cases when you want relative not absolute measures. Why not note here that "em" is also permitted in some cases, and then later on note the cases where this is portable (so don't put it elsewhere in portable documents)?

The fact that other document formats (e.g., CSS) include em-measurements is a good argument for its utility.  In general, OpenDocument is much more general and is a superset of the capabilities of other documents.  This is one narrow exception (the lack of em-measurements) which I'd like to get rid of.

--- David A. Wheeler

On 2/23/07, Lars Oppermann 

On Friday 23 February 2007 23:32, marbux wrote:
> > I can see how em-based horizontal measurements can be useful in text
> > documents. However, just calling to allow them wherever cm, in, pt etc.
> > are allowed is not feasible. From reading your clarifications I can see
> > that you don't want to do this.
>
> You have me figured out. :-)  I'm after accessibility and
> compatibility with other standards like CSS and XSL:FO, not a side
> trip to 16th Century technology. Em-based measurements should only be
> implemented where they make sense.

If you find specific cases where that is the case, let us know :)

Specifically, if I alter the config of a list-style I type a space in the 
postfix often, I can imagine a user wanting to type an em-space there.  But 
my guess is that most users will just be too lazy and type two spaces instead 
which tends to get just about the same effect.

-- 
Thomas Zander

On 27/02/07, Thomas Zander 

On 2/27/07, Thomas Zander 

On Tuesday 27 February 2007 10:16, marbux wrote:
> But the effect is about the same only if the line is left justified.
> If it's justified fully, the spacing becomes unpredictable unless you
> work with tab stops.

Someone pointed out to me that you might be thinking about the fact that in 
justified blocks of text the area for a space can change.  If that was what 
you were thinking, then I can put your worries at ease. The list-style 
postfix is not part of the paragraph. Its part of the list-label. And thus 
not justified.
-- 
Thomas Zander

On 27/02/07, marbux 

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
> 

David,

I don't have the details at my finger tips but I recall that there are 
multiple definitions of "em" in typography.

If we specify one, shouldn't we allow for choices of the others?

I can run down the details a bit later this week.

Hope you are having a great day!

Patrick

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

Patrick:
> I don't have the details at my finger tips but I recall that there are 
> multiple definitions of "em" in typography.
> 
> If we specify one, shouldn't we allow for choices of the others?
> 
> I can run down the details a bit later this week.

Please do.   We should try to make sure we cover the major standards, at least, and if there's an interpretation used by any widely-used office suite.

Marbux had a few pointers.  Here's what CSS says:
http://www.w3.org/TR/2006/PR-xsl11-20061006/#d0e5490
"The em-based relative units of measurement are defined in the Unicode
standard, 

David,

Should have checked my email archives *before* hitting the send button.

The concern is not with "em" but with "pt."

As reported by my friend Martin Bryan from the UK:

>Also I'm a printer, so the term pt raises a rag to a bull. Do you mean
>1/72nd of an inch used in modern copires, the Anglo/American point used in
>printing in the US and UK or the European Diderot point?
>
Still waiting for someone to develop topic map software to manage email 
archives!

Hope you are having a great day!

Patrick

David A. Wheeler wrote:

>Patrick:
>  
>
>>I don't have the details at my finger tips but I recall that there are 
>>multiple definitions of "em" in typography.
>>
>>If we specify one, shouldn't we allow for choices of the others?
>>
>>I can run down the details a bit later this week.
>>    
>>
>
>Please do.   We should try to make sure we cover the major standards, at least, and if there's an interpretation used by any widely-used office suite.
>
>Marbux had a few pointers.  Here's what CSS says:
>http://www.w3.org/TR/2006/PR-xsl11-20061006/#d0e5490
>"The em-based relative units of measurement are defined in the Unicode
>standard, 

On 20/02/07, Patrick Durusau 

On 20/02/07, Patrick Durusau 

Dave,

Dave Pawson wrote:

> On 20/02/07, Patrick Durusau 

On 20/02/07, Patrick Durusau 

On 20/02/07, Patrick Durusau 

Hi,

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

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