[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]