Apache OpenOffice (AOO) Bugzilla – Issue 105270
Writer saves text alignment of RTL paragraph not according to the ODF specification
Last modified: 2017-05-20 11:15:55 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
MRU->OS: I can confirm this. But I do not know, if the "text-align" interpretation should depend on the value of the "writing-mode"; if writing mode is rl, should right-align mean "start" then?
The text formatting interpretes the alignment as right and left independent from the writing direction. The text-align attribute specification knows right and left as values but declares them as [Interpreted as "text-align='start'"/"text-align='end'"] As the align attribute is stored/loaded independent from the writing direction of a specific paragraph the value can not be changed at reading/writing time. The only way to fix it would be to change the text formatting. At the time of the implementation of the RTL support this was decided otherwise by the User Experience team. It would also break compatibility to older documents.
> It would also break compatibility to older documents. True, but now it means nobody writing in RTL can interoperate with OOo if they get proper ODF docs from other apps. And vice versa.
> The only way to fix it would be to change the text formatting. At the time of > the implementation of the RTL support this was decided otherwise by the User > Experience team. So apparently the User Experience team made a bad decision. It happens, but fix it. > It would also break compatibility to older documents. So put a flag in newer documents that they are compliant, and use the old method when loading documents without the flag. Or one of a hundred other workarounds. But past wrong behaviour should not prevent future correct behaviour, especially where interoperability is concerned. RTL users (about a fifh of the world's population) cannot use OOo to interoperate with other office suite users.
>> The only way to fix it would be to change the text formatting. At the time of >> the implementation of the RTL support this was decided otherwise by the User >> Experience team. > > So apparently the User Experience team made a bad decision. Not necessarily. Seems to me that this is not a "User Experience" issue at all (user should not care about the internal structure of saved documents - just that they load up as saved). But: it is possible, for example, that due to technical reasons (code separation etc. as far as I understand from os's response), implementation required some major rewrite which competed against other issues, and was de-prioritized... This way or that, I agree with the comments re: interoperability with other apps, and would like to add that compliance to standards (ODF & CSS) also has "political" value, because ooo is nowadays the flagship of ODF.
It seems that OOo 3.2 has the facility of detecting if the document conforms to the ODF spec and handling non-compliance: http://www.openoffice.org/dev_docs/features/3.2/rc1.html#general_odf From that page: """ The document integrity check now proves whether an ODF document conforms to the ODF specification (this mainly affects ODF 1.2 documents). If an inconsistency is found, the document is treated as a broken one, and OpenOffice.org offers to repair the document. """ Therefore, OOo can now treat both the wrong behaviour (current code behaviour) and the correct behaviour. Therefore, the argument that the fix would break compatibility to older documents is no longer valid.
"Therefore, OOo can now treat both the wrong behaviour (current code behaviour) and the correct behaviour. Therefore, the argument that the fix would break compatibility to older documents is no longer valid." Is it possible to export/save document in the correct behavior?
> Is it possible to export/save document in > the correct behavior? That is exactly what this Issue requests. Until this issue is fixed, the answer is no.
""" The document integrity check now proves whether an ODF document conforms to the ODF specification (this mainly affects ODF 1.2 documents). If an inconsistency is found, the document is treated as a broken one, and OpenOffice.org offers to repair the document. """ just for the record: this is badly written; actually OOo 3.2 only checks some very specific things in a document (such as that it does not contain files that are not listed in META-INF/manifest.xml). when it comes to the actual XML content, OOo 3.2 will still treat invalid content mostly by simply ignoring it. thus the quoted note has no effect on this issue.
Set target to 3.3. It will be a tough goal as there are many changes to be done. We have to change all paragraph styles or apply hard attributes in all documents containing text parts in RTL writing direction at import time. A simple compatibility switch won't work. We also will lose backwards compatibility to older OOo versions. Once saved with OOo3.3, all documents with RTL text will be displayed wrongly in older version. We also must change our user interface for paragraph attributes and remove the terms "left" and "right" and use something else instead (as paragraph styles can be applied to paragraphs with both writing directions). Exactly this was what the UX team wanted to avoid (as os mentioned). I assign this task to od as os currently is very busy with other things.
> Set target to 3.3. Thanks, this will please many people! > We also will lose backwards compatibility to older OOo versions. Once > saved with OOo3.3, all documents with RTL text will be displayed wrongly > in older version. I do not think that will be much of a problem as current OOo-created ODT files are in-house only in the organizations that I am familiar with. In fact, this issue is one of the reasons for that. However, labs (and households) with multiple computers will have to update all machines to OOo 3.3 together. Again, this should not be a problem. > We also must change our user interface for paragraph attributes and > remove the terms "left" and "right" and use something else instead (as > paragraph styles can be applied to paragraphs with both writing > directions). Exactly this was what the UX team wanted to avoid (as > os mentioned). Why remove the terms "left" and "right" from the UI, or have any other UI changes? As it is, it is very understandable and works exactly as expected (it is very intuitive) other than the fact that OOo is not compatible with other office suits. I understand that the code needs to be changed, but the UI is very intuitive and in my opinion should be left as is, and the user experience should remain exactly as it is.
Ok, I have just started working on this issue. First, I want to remark, that we need to change the user interface - namely pane "Alignment" of the various Format dialogs for paragraphs, paragraph styles, table cells ... The reason for this change is that regarding XSL-FO on which the ODF attribute fo:text-align relies on the text alignments "left" and "right" are the same as "start" and "end". Thus, if there is a paragraph style whose text alignment attribute is "left" is applied on a paragraph whose text direction is right-to-left, the text of this paragraph is aligned on the right side. If the same paragraph style is applied to a paragraph whose text direction is top-to-bottom, the text of this paragraph is aligned on the top side. This means that the terms "left" and "right" does not make sense in the user interface, if want to solve this issue complete and consistent. Second, this issue occurs in all OOo applications.
The UI issue you speak of is rather trivial to solve as far as I can see; in KWord the only change was to swap the icons for left-align and right-align based on the directionality of the locale the application is started in. In other words; the action is internally called 'leading-align' or 'trailing-align' and based on directionality the icon it shows can be the left-align or right-align icon in a way that its visually consistent.
Thomas, yes that could be also a possible solution for the user interface. Currently, I am more in favor of the general solution which also serves "mixed environments" - e.g. editing an Arabic text document in an German OOo version on a German operating system or creating a bilingual text document containing English and Hebrew text. I think we should stay with the current toolbar button to left- or right-align the paragraph at the cursor of the selected text. But the functionality of these button needs to be adjusted to applied the correct value for fo:text-align according the text direction.
> Currently, I am more in favor of the general solution which also serves "mixed > environments" - e.g. editing an Arabic text document in an German OOo version on > a German operating system or creating a bilingual text document containing > English and Hebrew text. > As a user and one who supports multiple OOo installs, the OS environment should only affect the default directionality of new documents. The OOo UI should not affect directionality at all. The whole purpose of having OS locale settings is to set user preferences for these things, regardless of which UI language is choosen. However, for opening existing documents, directionality should be as per the document. No matter what OS settings or UI settings, document objects that are RTL should be displayed RTL and document objects that are RTL should be displayed RTL.
Adjusting target, because OOo 3.3 is already on its way. We are currently working on a solution. Our challenge is that OOo has "real" left and right as text alignments. Such "real" left and right does not exist in ODF respectively XSL. Thus, the solution has to cover the handling of documents from already released OOo versions and existing macros and extensions which are using the text alignment via the UNO-API.
> We are currently working on a solution. Thank you. There are a few labs at my university who are waiting for this! They are already sold on the other fine aspects of OOo.
Ok, I have worked out a solution. Please have a look at OOo's wiki page http://wiki.services.openoffice.org/wiki/TextAlignment. Feedback is welcome.
CC ufi
implementation of proposed solution in progress in cws textalignment01
fix is making progress, but a couple of things are still missing: - Adjustment of Calc's UNO-APIs for com::sun::star:style::ParaAdjust in order to handle new paragraph text alignment values <START> and <END> - Adjustment of Calc's UNO-APIs for com::sun::star::style::ParaTextAlignment in order to handle paragraph text alignment values <LEFT> and <RIGHT> - Implementation of com::sun::star::table::CellTextAlignment - Adjustment of UNO-APIs for com::sun::star::table::CellHoriJustify in order to handle new cell content text alignment values <START> and <END> - Adjustment of UNO-APIs for com::sun::star::table::CellTextAlignment in order to handle cell content text alignment values <LEFT> and <RIGHT> - Adjustment of all filters which are using the <SvxAdjustItem> and/or <SvxHorJustifyItem> in order to consider the new attribute values <START> and <END> As OOo 3.4 release branch off is near and the quality assurence tasks (code review, testing, etc.) will take also same time, I postpone this issue to the next release.
Now that the 4.0 release is tagged, this is a good time to get these types of changes in.
Reset assigne to the default "issues@openoffice.apache.org".