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

Hi Patrick,

Patrick Durusau schrieb am 01-Nov-20 um 16:04:

I'm assuming the following types (from the fifth edition) are at issue:

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

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

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