Re: [office] xml:lang settings. Confused.

["Dave Pawson" <dave.pawson@gmail.com>]

On 20/06/07, Michael Brauer <Michael.Brauer@sun.com> wrote:

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

A part of it yes. IMHO the starting point for the xml laid out on disk
is 'what language is this content in'.
  en-US is clear. I *think* the iso standards are sufficient
for an app to know what coverage they have with respect to language.

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

Agreed. As I stated, my interest is in the XML laid down on disk.
If an application offers Swedish, and changes xml:lang to se
then we are all happy. The application constrains the user from
the available language support, then maps that to xml:lang


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

That sounds a little arbitrary Michael? Was it?


 The selection of languages and other formatting properties
> based on the script type is a real feature.

I don't understand that sentance. What do you mean by a script?
15.4.21? How many other attributes are wrapped up in that label?
fo:font-family, style:font-family-asian, style:font-family-complex.
Are there any more? It does sound overly complex Michael.
That may be due to my lack of I18N knowledge.



The xml:lang attribute won't
> be sufficient to represent that feature. That's why ODF uses different
> attributes.

I'm lost again. An implementation feature driving the standard?
What happens to portability?
Quote. The attribute should be evaluated by applications that do not
support script types to select the correct script dependent
properties. Application that support script types may also evaluate
the attribute and overwrite the script type they would evaluate for a
certain character, but they don't have to. end quote.

If you support it.
may evaluate.
don't have to.






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

More alternatives?

I wonder how xsl-fo works. I know that supports languages quite fully.
AFAIK the only related attributes are font-family, writing-mode.
Why has ODF opted for so many? And so many alteratives 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.

Which I think is wrong as versions advance. Please don't let implementations
drive the standard without very good reason. We have examples of the trouble
that can cause.

 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.

Any longer?
It has never been used Michael?

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?

Please don't add it just to keep me happy.
The whole bag of attributes need to be resolved and a clean solution sought.






> >
> > In

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

I've not heard of CTL characters. I doubt you mean control 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.

It isn't at present.
You have presented reasons based on current implementations
why a number of optional attributes interact to present an appropriate
set of glyphs on the page with an appropriate left to right top to
bottom combination.

I'm not convinced that ODF has an optimal solution.

I'll not continue with this thread Michael. I've expressed my concerns
and I don't
have the expertise to offer solutions. I only wish others with that expertise
would pick up the debate without the bias of a current implementation.

regards



-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk