[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (OFFICE-4030) Bottom to top, left to right writing direction
[ https://issues.oasis-open.org/browse/OFFICE-4030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=82724#comment-82724 ]
Michael Stahl edited comment on OFFICE-4030 at 3/23/23 5:24 PM:
----------------------------------------------------------------
regarding sections see my previous comment.
> If the attribute value is page each part of the section uses the layout direction of the page on which this part appears.
... but only if it actually applies - the section could be in a table or frame with its own writing-mode... well okay not frame because those don't split, but table cells may split.
> How are cell borders and padding applied?
> LibreOffice behaves different in Writer and Calc. In Writer a border-left is always left regardless of the writing mode of the table. In Calc a border-right is on the ride side of the cell in LTR table and on the left side in RTL table. I would treat this as bug in LibreOffice. âleftâ, âtopâ, ârightâ and âbottomâ are physical descriptions and should not be influenced by writing mode, in contrast to âstartâ and âendâ. But the latter are not available for borders. CSS has the special markup âborder-inline-startâ and âborder-inline-endâ to make borders relative to writing-mode.
i get different result for Writer: the border-right is applied on the left of RTL table.
oddly, in Writer the padding-left is always on the left? that doesn't seem consistent, which is problematic.
Calc works same as Writer.
> Do we need a rule that style:direction and style:glyph -orientation-vertical attributes have precedence over the calculated writing mode of paragraphs in the cell. Does such precedence is implemented?
not clear how this should work - these attributes only exist on table cells...
apparently this is implemented in Calc, the checkboxes Text Orientation "Vertically stacked" and "Asian layout mode" in Format->Cells.
it also looks like Calc doesn't allow formatting at the paragraph level, so in that case the issue of a paragraph level writing-mode interacting with these attributes on the cell doesn't arise.
> How are the table margins applied in case the writing mode of the table is orthogonal to the writing mode of the page? That is common in Chinese vertical texts.
i can't figure out how to do this - is there any application where this can be done at the moment?
> How are table shadows affected by writing mode?
apparently text-shadow in CSS2 (which we cite) ignores writing-mode - left is always left; both Writer and Calc implement it like this too.
was (Author: info6):
regarding sections see my previous comment.
> If the attribute value is page each part of the section uses the layout direction of the page on which this part appears.
... but only if it actually applies - the section could be in a table or frame with its own writing-mode... well okay not frame because those don't split, but table cells may split.
> How are cell borders and padding applied?
> LibreOffice behaves different in Writer and Calc. In Writer a border-left is always left regardless of the writing mode of the table. In Calc a border-right is on the ride side of the cell in LTR table and on the left side in RTL table. I would treat this as bug in LibreOffice. âleftâ, âtopâ, ârightâ and âbottomâ are physical descriptions and should not be influenced by writing mode, in contrast to âstartâ and âendâ. But the latter are not available for borders. CSS has the special markup âborder-inline-startâ and âborder-inline-endâ to make borders relative to writing-mode.
i get different result for Writer: the border-right is applied on the left of RTL table.
oddly, in Writer the padding-left is always on the left? that doesn't seem consistent, which is problematic.
Calc works same as Writer.
> Do we need a rule that style:direction and style:glyph -orientation-vertical attributes have precedence over the calculated writing mode of paragraphs in the cell. Does such precedence is implemented?
not clear how this should work - these attributes only exist on table cells...
apparently this is implemented in Calc, the checkboxes Text Orientation "Vertically stacked" and "Asian layout mode" in Format->Cells.
it also looks like Calc doesn't allow formatting at the paragraph level, so in that case the issue of a paragraph level writing-mode interacting with these attributes on the cell doesn't arise.
> Do we need to specify âclosest containing layout objectâ?
> How are the table margins applied in case the writing mode of the table is orthogonal to the writing mode of the page? That is common in Chinese vertical texts.
> How are table shadows affected by writing mode?
apparently text-shadow in CSS2 (which we cite) ignores writing-mode - left is always left; both Writer and Calc implement it like this too.
> Bottom to top, left to right writing direction
> ----------------------------------------------
>
> Key: OFFICE-4030
> URL: https://issues.oasis-open.org/browse/OFFICE-4030
> Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
> Issue Type: New Feature
> Components: Paragraph
> Reporter: Andras Timar
> Assignee: Patrick Durusau
> Priority: Minor
> Fix For: ODF 1.4
>
> Attachments: Comparison standards and implementations.odt, Proposal_writing-mode_Version_TC2.odt, Proposal_writing-mode_Version_TC3.odt, Proposal_writing-mode_Version_TC4.odt, Proposal_writing-mode_Version_TC5.odt, Proposal_writing-mode_Version_TC6.odt, overview.ods
>
>
> h1. Summary
> Proposal owner: Miklos Vajna
> Proposal short name: Bottom to top, left to right writing direction
> h1. Rationale
> *Use cases:*
> Users sometimes want to have a text direction which is similar to latin text
> (left to right, then top to bottom), but rotated 90 degrees counter-clockwise.
> Also, this improves consistency, as doing the same in the clockwise direction
> is already possible (the top to bottom, right to left direction is used for
> e.g. Japanese text).
> *Alternatives considered:*
> It is possible to rotate characters at a span level, but that only gives
> similar result as long as the content fits a single line.
> h1. Requested changes to the ODF Standard
> Text changes/additions (compared to ODF 1.2):
> 20.394.2 <style:graphic-properties> (existing section)
> Append to the end of style:writing-mode attribute value list: bt-lr.
> 20.394.3 <style:page-layout-properties> (existing section)
> Append to the end of style:writing-mode attribute value list: bt-lr.
> 20.394.4 <style:paragraph-properties> (existing section)
> Append to the end of style:writing-mode attribute value list: bt-lr.
> 20.394.5 <style:section-properties> (existing section)
> Append to the end of style:writing-mode attribute value list: bt-lr.
> 20.394.6 <style:table-cell-properties> (existing section)
> Append to the end of style:writing-mode attribute value list: bt-lr.
> 20.394.7 <style:table-properties> (existing section)
> Append to the end of style:writing-mode attribute value list: bt-lr.
> Schema changes/additions:
> {{<rng:define name="common-writing-mode-attlist">}}
> {{Â <rng:optional>}}
> {{Â Â <rng:attribute name="style:writing-mode">}}
> {{Â Â Â <rng:choice>}}
> {{Â Â Â ÂÂ<rng:value>lr-tb</rng:value>}}
> {{Â Â Â ÂÂ<rng:value>rl-tb</rng:value>}}
> {{Â Â Â ÂÂ<rng:value>tb-rl</rng:value>}}
> {{Â Â Â ÂÂ<rng:value>tb-lr</rng:value>}}
> {{Â Â Â ÂÂ<rng:value>lr</rng:value>}}
> {{Â Â Â ÂÂ<rng:value>rl</rng:value>}}
> {{Â Â Â ÂÂ<rng:value>tb</rng:value>}}
> {{Â Â Â ÂÂ<rng:value>page</rng:value>}}
> {{Â Â Â ÂÂ<rng:value>bt-lr</rng:value>}}
> {{Â Â Â </rng:choice>}}
> {{Â Â </rng:attribute>}}
> {{Â </rng:optional>}}
> {{</rng:define>}}
> In other words, allow bt-lr as a new value of the style:writing-mode
> attribute.
> h1. Impacts
> *Conformance:*
> This proposal will not add any mandatory features or behaviors.
> *Backwards compatibility:*
> This change will not impact existing ODF processors, the usage of the new
> attribute value is optional.
> *Accessibility impact:*
> This change will not impact accessibility.
> *Interoperability:*
> OOXML's wordprocessingML has a <w:textDirection w:val="btLr"/> markup to
> describe the same, this proposal allows roundtripping that feature in ODF.
> LibreOffice 6.3 implements this layout feature in its ODF extension namespace.
--
This message was sent by Atlassian Jira
(v8.3.3#803004)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]