Bug 37128 - Writer saves text alignment of RTL paragraph not according to the ODF specification
Summary: Writer saves text alignment of RTL paragraph not according to the ODF specifi...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: high normal
Assignee: Not Assigned
URL:
Whiteboard: odf odf_validation
Keywords:
Depends on:
Blocks: RTL-CTL ODF-export-invalid
  Show dependency tree / graph
 
Reported: 2011-05-12 02:01 UTC by Dotan Cohen
Modified: 2023-03-31 20:57 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Dotan Cohen 2011-05-12 02:01:40 UTC 
This is an interoperability issue.

OOo writer seems to store and read text alignment not according to spec.
The fo:text-align tag gets the value 'end' for text that has a visual alignment
right and a text progression (style:writing-mode) of right-to-left.
If you look at the spec; http://www.w3.org/TR/xsl/#text-align then 'end' is
specified as;
 «Specifies that the content is to be aligned on the end-edge in the
inline-progression-direction.»

This means that for LTR paragraphs end equals right and for RTL paragraphs end
equals the visual alignment of left.
Yet OOo seems to equate 'end' with 'right' unconditionally.

Test documents and related materials can be found in the koffice bugtracker;
http://bugs.kde.org/207915

This is a critical issue preventing adoption of LibreOffice at some labs at my former university. The original OOo bug is here:
http://openoffice.org/bugzilla/show_bug.cgi?id=105270

Now that LibreOffice is becoming well-known one of the labs contacted me to see if this issue is resolved. Please, people are trying to flee MSO to LibreOffice but this issue is preventing users of RTL languages from adopting the software as it's biggest selling point (interoperability) is broken.
Comment 1 Petr Mladek 2011-05-16 08:46:18 UTC 
It seems that od started to implement this in CWS textalignment01.
Comment 2 Björn Michaelsen 2011-12-23 12:06:54 UTC Comment hidden (obsolete)
Comment 3 Dotan Cohen 2012-01-11 01:21:02 UTC 
Yes, still valid, and a very critical interoperability issue. Switching to NEW, and increasing the Importance as the whole premise of LibreOffice is interoperability and standards compliance. What is the point of having yet another proprietary office suite?
Comment 4 Michael Stahl (allotropia) 2012-01-24 03:19:32 UTC 
i agree that this is a problem.

as fixing this requires quite a bit of effort, ideally we'd
want to use the significant work that has already
been done by od in OOo CWS textalignment01.

unfortunately that work is not integrated at ApacheOO yet,
and is AFAIK only available under LGPLv3 license; we'd really
like to be able to license the whole of LO under MPL/LGPLv3+,
so it would need integrating and re-licensing at
ApacheOO first, then we could merge it from there.
Comment 5 Werner Bruns 2013-07-21 12:38:31 UTC Comment hidden (off-topic)
Comment 6 Eike Rathke 2013-07-22 10:14:40 UTC Comment hidden (off-topic)
Comment 7 Björn Michaelsen 2014-01-17 00:43:34 UTC Comment hidden (obsolete)
Comment 8 Cédric Bosdonnat 2014-01-20 08:57:19 UTC 
Restricted my LibreOffice hacking area
Comment 9 Joel Madero 2015-05-02 15:44:00 UTC Comment hidden (obsolete)
Comment 10 Shimi Chen 2015-05-02 16:02:15 UTC 
Still a big issue with 4.4.2.2 Arch Linux build-1.
Comment 11 Dotan Cohen 2015-05-03 11:51:10 UTC 
Related OOo link rotted when OOo bugtracker was moved. Here is the link on archive.org:
https://web.archive.org/web/20110301055910/http://openoffice.org/bugzilla/show_bug.cgi?id=105270
Comment 12 Dotan Cohen 2015-05-03 11:53:18 UTC 
Users confirm that the issue is not resolved in the latest LibreOffice release, 4.4 on Windows.
Comment 13 QA Administrators 2016-09-20 09:37:46 UTC Comment hidden (obsolete)
Comment 14 Shimi Chen 2016-10-31 09:16:34 UTC 
Still an issue in 5.2.2.2.0 (Arch Linux x86-64).
Comment 15 QA Administrators 2018-08-22 02:37:13 UTC Comment hidden (obsolete, spam)
Comment 16 Fahad Al-Saidi 2019-12-28 18:38:15 UTC 
Any plan to fix this in ODF 1.3?
Comment 17 Eyal Rozenberg 2020-02-29 10:28:13 UTC 
Isn't the bug here really just the fact that LO fails to distinguish between Start/End and Left/Right? These are  missing from the UI as well. I'm pretty sure there's a separate bug about that.

At the very least it should be related, if not an outright dupe.

I'll also say that while this bug is reasonably easy to ignore by casual RTL users, in some scenarios - e.g. involving automatic processing of documents in which directions are changed, or file format is converted  - this can be super-problematic.
Comment 18 QA Administrators 2022-03-18 03:43:32 UTC Comment hidden (obsolete, spam)
Comment 19 Eyal Rozenberg 2023-03-31 20:57:04 UTC 
(In reply to Eyal Rozenberg from comment #17)
> Isn't the bug here really just the fact that LO fails to distinguish between
> Start/End and Left/Right?

So, yes, but no. There is now a separate bug about properly supporting Start and End in addition to Left and Right: bug 131192.

But this really needs to be fixed! Our output files for RTL languagues are broken now already for 14 years :-O