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] Bottom to top, left to right writing direction


Regina,

I didn't mean to imply the problem isn't complex but only that it is one
the TC, relying in part on W3C work, can solve.

Hope you are having a great weekend!

Patrick

On 11/1/20 11:24 AM, Regina Henschel wrote:
> Hi Patrick,
>
> Patrick Durusau schrieb am 01-Nov-20 um 16:04:
>> Regina,
>>
>> I'm assuming the following types (from the fifth edition) are at issue:
>>
>> *****20.1.10.83 ST_TextVerticalType (Vertical Text Types)*****
>
> Yes, it is about mapping to those types.
>>
>> **********
>>
>> Reading the definitions, yes, enabling bt-lr from XSL doesn't solve the
>> problem of peculiar definitions in OOXML but it would solve the issue
>> for such languages more generally. At least until more guidance is
>> issued from the W3C on rendering of CJK languages in texts.
>
> The problem is complex. W3C has specified
> https://www.w3.org/TR/css-writing-modes-3/ about that topic.
>
>>
>> Noting that eaVert and montolianVert are too vague to be meaningfully
>> mapped, "where some fonts are displayed as if rotated by 90 degrees
>> while some fonts (mostly East Asian)" makes no sense. I have no way to
>> know or specify "some fonts."
>
> The above mentioned recommendation has information about it.
>
>>
>> As far as vert top-bottom, left to right and vert270 bottom-top, right
>> to left, should we take guidance from 7.29 Writing-mode-related
>> Properties, https://www.w3.org/TR/xsl/#writing-mode-related (XSL 1.1)
>> and not invent new terminology for it?
>
> It is not enough to add additional values for writing-mode. We would
> need style:glyph-orientation-vertical (20.297 part 3) too. That is
> currently restricted to <style:table-cell-properties> (17.18) and
> values "0" and "auto".
>
> "writing-mode" alone has no means to distinguish between "eaVert" and
> "vert". XSL 1.1 and SVG have "glyph-orientation-vertical" and
> "glyph-orientation-horizontal" in addition
> https://www.w3.org/TR/SVG11/text.html#GlyphOrientation
> https://www.w3.org/TR/2001/REC-xsl-20011015/slice7.html#glyph-orientation-vertical
>
>
>>
>> Thinking that if we add writing-style elements sufficient to define
>> character styles (perhaps within the standard) that represent common
>> character orientations, leaving odd cases to user to define, wouldn't
>> that give a target for mapping OOXML vert and vert270?
>>
>> Realize the present proposal may be inadequate but if the larger issue
>> is solving style mappings from OOXML, let's gather those requirements up
>> and define them. >
>
> OOXML vert270 is a problem in css-writing-modes-3, because the
> actually needed style:glyph-orientation-vertical="270" has no mapping
> there and style:glyph-orientation-vertical from SVG is considered
> obsolete by W3C.
>
> Therefore I see these ways:
> (A) extend writing-mode with own values which include
> glyph-orientation, or
> (B) extend glyph-orientation in values and usage.
>
> Kind regards
> Regina

-- 
Patrick Durusau
patrick@durusau.net
Technical Advisory Board, OASIS (TAB)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau 



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