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: [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=82466#comment-82466 ] 

Michael Stahl commented on OFFICE-4030:
---------------------------------------

> Perhaps we should add a link to article â[How to use Unicode controls for bidi text|https://www.w3.org/International/questions/qa-bidi-unicode-controls.en]â; [4]?

i find it helpful, but it doesn't appear to be part of a specification or standard, just an "article" - is it possible to add it as non-normative reference?

> I donât know which value LibreOffice uses. Having a local of DE I get left-to-right as default. But I donât know which default is used for other locals.

i think the default should be "use superordinate object setting" wherever possible.

this leaves the top-level, in Writer and Calc the page style, which appears to be set to LTR or RTL depending on the locale (tested with LC_ALL=ar_EG.UTF-8).

it looks like Impress/Draw default everything to LTR all the time, which is probably a bug.

but: i've tested almost but not exactly the same thing - when a new document is created - but what we want to know is what happens if you load a document that somehow doesn't specify it, what's the default in that case?

> To which writing mode resolves the {{page}} value, if no container object exists, which has a writing mode value different from {{page}}?

obviously, "page" is not a valid value on a page style (do we say this somewhere? apparently yes, on page 6).

then it's the same question as above, what is the default value for page styles?

> Is in case of value {{page}} the to be used writing-mode that one of the frame, if the text box is anchored to a frame?

my guess is the anchor is just used for positioning, the "parent" is the page.

but i'm wrong and Writer actually does it, the frame anchored at RTL frame inherits RTL.

this also works the same if it's anchored in a body paragraph - switch the paragraph to RTL and the frame inherits RTL, so at least it's consistent.

> The values {{bt-lr }}and {{tb-rl90}} are not implemented for pages in LibreOffice. Corresponding values are not implemented for sections in docx in Word. Should we exclude them here?

the description says these values do not correspond to any real language but the use-case for these is given as rotated table headers and such.

so it would make sense to limit their applicability, particularly if we know that there is no implementation of these for page styles.

> The value {{page}} is excluded in text form here (OASIS-3790). Would it better to exclude it in the schema too? How can that be done in a nice way?

not sure if it's worth the effort. have you ever seen a document where this occurs?

> How are header and footer effected by the writing mode of the page?

i think they use it, same as the body text.

> It seems LibreOffice ignores the writing-mode of the source document and display the linked content in the writing-mode of the target document?

the content of the link target is copied into the section, any properties of the link target itself are ignored.

so in particular the page style of the linked document is not copied, and therefore doesn't have any effect, and any value "page" in the section content will refer to the link section itself.

(it's also possible to put a section into the link target, then the section with its properties will be copied into the section that has the link.)

> Is a section orthogonal to the page writing mode possible?

Writer appears to allow only LTR/RTL, so no?

> Do we need to specify âclosest layout objectâ?

i think it should be "closest containing layout object", and then it's the same as on page 4.

> If the attribute value is {{page}} the layout direction is inherited from the layout direction of the closest layout object in which the table is contained, and which has a layout direction other than {{page}}.

this seems redundant - it's the same for every element? except graphic-properties, where the anchor thing needs to be mentioned, as it's not obvious.

Â

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