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] xml:lang settings. Confused.

Hi Dave,

Dave Pawson wrote:
> On 20/06/07, Michael Brauer <Michael.Brauer@sun.com> wrote:
>> > Why can't the xml:lang be used throughout?
>> > For clarity where does 'western' finish and (presumably ) Eastern 
>> start?
>> > xml:lang is so much simpler.
>> ODF has an style:script-type attribute that (optionally) provides hints
>> where the script types start and end. It's defined in section 15.4.21.
> My question related to the weak definition Michael.
> Western and Eastern isn't precise for a specification.

But that's a different issue, isn't it? Script types are a feature of 
Unicode itself. I'm not an Unicode expert. If the term "latin" (it's 
latin, not western - I was wrong in my previous mail) is not precise 
enough, then we may have to define it more precisely. But is this a 
reason to switch to xml:lang?

>> But the different attributes for the language, and also for other
>> attributes like the font family, do exist for usability reasons.
> Can we just discuss xml:lang please, fonts may be associated
> but should be a seperable problem.

 From the user perspective it is the same problem. In mixed documents,
you not only have to switch the language, but also the fonts and other
settings. This should be done consistently in the application's user 
interfaces, and I believe also in ODF.

> If you
>> write a mixed text, you probably don't want to assign the language to
>> every piece of text that does not have the default language.
> That doesn't make sense to me. From a visual perspective,
> I can continue writing, say, my English, and use some subset of French,
> and no one will know.
> If I change to use Katakana then I'd hope the author would indicate the 
> fact!
> So yes, to be correct, I would want the author to assign a language
> to the block of text in question.

But some office applications added the different settings because 
authors don't want to do so. So, it is indeed not a question of
encoding. The selection of languages and other formatting properties 
based on the script type is a real feature. The xml:lang attribute won't 
be sufficient to represent that feature. That's why ODF uses different 

The "style:script-type" attribute I have mentioned actually also allows 
to specify that a document does use fo:language only. That means, 
applications that do not support script type depended attributes may 
indicate that, and don't have to export the Asian and complex 
attributes, too.

So, don't get me wrong. I agree that it would be easier if there would
be only xsl:lang. But some office applications have a more complex
way to assign languages to text. That means, if you want to be able to
represent such documents in ODF, then ODF must support more complex
systems as well, and xml:lang alone is not sufficient any longer. We may 
of cause add it, but the question is then: Who wins, and get things 
really easier if we have one more language attribute?

> In
>> particular, since you in practice do not only have to assign the
>> language, but in many situations also the font family, and sometimes
>> even the font height and weight.
> That makes sense, unless you have some very clever implementations.
> I want a tool that can recognise the code points, match them with glyphsets
> and find an appropriate font. Font size/weight is orthoganal to this 
> aspect.

That's again not sufficient. Applications do that instead, but the same
way as you can select the font you want to use for the ASCII characters,
you may want to be able to do so for your Asian or CTL characters.
> For that reason, ODF has different
>> attribute sets for these attribute, so that the user can set them once
>> in the style, and from than on does not have to care about them any 
>> longer.
> Do you think that is satisfactory Michael? I don't.

Well, I would be glad if xml:lang would be sufficient to represent the 
capabilities of office application regarding languages, but it 
unfortunately isn't.

> Regards

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

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
        D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Marcel Schneider, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering

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