RE: SVG 1.2 Comments: I18N comments on section 4.12 and its friends...

Hi Chris,

Thanks for the response. Some notes in response follow.

> APw> We would like to figure out the best method of working with
> APw> you to resolve this problem. Would cross-posting email or forming a
> APw> Task Force make the most sense to you?
> 
> Either of those wold work depending on the anticipated scope and
> duration.

Why don't we start with cross-posting and plan a task force if this mushrooms.

> >>   a. The default will be 'auto', which MAY be implementation 
> >> defined and SHOULD be conformant with UAX#9 and UAX#14 (i.e. the 
> >> idea is that it should be more, rather than less, capable to use 
> >> 'auto').
> 
> I agree that 'more rather than less' is key here. I would like to see
> wording that, if nothing better can be provided, then its the same as
> the 'other' (reproducible graphics) mode. I don't want it to be used as
> a loophole for doing less.

The problem being that it is somewhat difficult to determine if one's local graphics library is more capable or less capable. I think the key here is that all SVG implementations will have to implement 'other'. 'auto' is not guaranteed to be anything in particular and may be junk, but if you want quality line breaks you won't use auto and an SVG implementation is non-conformant unless it implements at least the most basic form of 'other'. On the other hand, 'auto' will probably give you the highest performance, at least on some platforms.

> That sounds pretty suboptimal. However,
> 
> >>> CSS3 Text maps vertical scripts' character directionality based on
> >>> the paragraph's block progression.
> 
> SVG has included vertivcal as well as horizontal text from the beginning
> and thus, has modelled on XSL property values with before/after and
> start/end. It does not, in consequence, have legacy 'left means down
> except when it means up' type issues.

The real issue here is text rotation for non-vertical scripts embedded into a vertical layout. It might be complex to describe well. The use of before/after and start/end is very commendable and saves us all sort of grief, but that isn't what has me concerned wrt complexity.

> That sounds good. I will forward it to a developer who is implementing
> this; hopefully we can have running code to test it out.

If the developer gets stuck or has questions, you can write to the I18N-IG list or to me directly. Mark Davis has also offered to help answer questions that may arise (he's copied on here).

> APw> Special considerations:
> APw> 1. If soft hyphens are used to form breaks, then implementers
> APw> should specifically consider UAX#14 section 5.2 "Use of soft
> APw> hyphen". In particular, breaking on a soft hyphen may result in
> APw> spelling or form changes in certain languages and scripts.
> 
> In the 'auto' mode, or in both modes? (This is about  line breaking to
> s s, for example?)

Actually, 'auto' mode probably has a better chance of working here. We have to describe this for implementers of 'other'...

I assume your example used to have an es-tszet (ß U+00DF) in it. Actually, German spelling rules prohibit this character from forming across syllable boundaries. And you'll never get a soft hyph into the middle of a Unicode character anyway :-). No, the examples in section 5.2 are much more insidious, since they are not exhaustive and suggest that you need a dictionary or grammar engine to deal with some cases (i.e. you need some knowledge of the language). I think noting the issue using something like this might be sufficient:

--
Forming breaks using soft hyphen in some languages requires adjustments to the spelling of words across the break. Implementations of this specification may not be able to provide language-specific text adjustment in these cases. Refer to UAX#14 S5.2 for more information...
--

> APw> 5. "Emergency breaking" may be required if some line of text
> APw> is too long to fix any of the remaining strips. The form this takes
> APw> is ?????
> 
> procrustean????

I'm not going to lie down on that bed. What *should* the rules be for emergency breaking? Perhaps it should be tailorable. It must at least insist on breaking on glyph boundaries, although it is unclear whether this can be applied to texts like Arabic or various Indic texts which are shaped or in which the text is conjoined into words.

The real base case here is when a single break segment will not fit into the line. The options might be "force break on", which wraps (appropriately or not) on a "logical" glyph boundary and "force break off", which results in a blank line in the display.

---
In any case, our WG looks forward to helping you solve this problem, which doesn't look intractable and does look interesting.

Best Regards,

Addison

Addison P. Phillips
Director, Globalization Architecture
http://www.webMethods.com

Chair, W3C Internationalization Working Group
http://www.w3.org/International

Internationalization is an architecture. 
It is not a feature.

> -----Original Message-----
> From: Chris Lilley [mailto:chris@w3.org]
> Sent: 2004年12月9日 19:26
> To: Addison Phillips [wM]
> Cc: www-svg@w3.org; mark.davis@jtcsv.com; w3c-i18n-ig@w3.org
> Subject: Re: SVG 1.2 Comments: I18N comments on section 4.12 and its
> friends...
>

Received on Friday, 10 December 2004 18:13:26 UTC