Regina, I'm assuming the following types (from the fifth edition) are at issue: *****20.1.10.83 ST_TextVerticalType (Vertical Text Types)***** eaVert (Vertical Text Type Enum ( East Asian Vertical )) A special version of vertical text, where some fonts are displayed as if rotated by 90 degrees while some fonts (mostly East Asian) are displayed vertical. horz (Vertical Text Type Enum ( Horizontal )) Horizontal text. This should be default. mongolianVert (Vertical Text Type Enum ( Mongolian Vertical )) A special version of vertical text, where some fonts are displayed as if rotated by 90 degrees while some fonts (mostly East Asian) are displayed vertical. The difference between this and the eastAsianVertical is the text flows top down then LEFT RIGHT, instead of RIGHT LEFT vert (Vertical Text Type Enum ( Vertical )) Determines if all of the text is vertical orientation (each line is 90 degrees rotated clockwise, so it goes from top to bottom; each next line is to the left from the previous one). vert270 (Vertical Text Type Enum ( Vertical 270 )) Determines if all of the text is vertical orientation (each line is 270 degrees rotated clockwise, so it goes from bottom to top; each next line is to the right from the previous one). wordArtVert (Vertical Text Type Enum ( WordArt Vertical )) Determines if all of the text is vertical ("one letter on top of another"). wordArtVertRtl (Vertical WordArt Right to Left) Specifies that vertical WordArt should be shown from right to left rather than left to right. ********** 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. 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." 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? 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. Yes? Hope you are having a great weekend! Patrick On 11/1/20 7:56 AM, Regina Henschel wrote: > Hi Patrick, > > we need a decision about the way to go. > Problem is that the OOXML text vertical types "vert" and "vert270" > cannot be expressed in ODF and simple enabling bt-lr from XSL (as in > the proposal) does not solves the problem. > > Kind regards > Regina > > Patrick Durusau schrieb am 30-Oct-20 um 22:01: >> Regina, >> >> Just a light ping to see what more needs to be done for >> >>
https://issues.oasis-open.org/browse/OFFICE-4030 Bottom to top, left to >> right writing direction? >> >> I know you have a proposal on glyph-orientation as well, >>
https://lists.oasis-open.org/archives/office/201912/msg00006.html >> >> I'm sweeping the issues without current members to see if we can move >> some of them forward. >> >> Thanks! >> >> Hope you have started a great weekend! >> >> Patrick >> > -- 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