Apache OpenOffice (AOO) Bugzilla – Issue 73707
Preview of Autoformatted table incorrect in RTL
Last modified: 2013-08-07 14:43:03 UTC
If a user inserts a table in a document whose text direction of a document is RTL, the preview in the autoformat window has the wrong direction. See attached screenshots.
Created attachment 42350 [details] How it looks in LTR
Created attachment 42351 [details] How it looks in RTL (note that the black column in the preview is misplaced)
Confirming with build 9107 on WinXP.
The Table.Autoformat dialog does not seem to be RTL ready.
I'm attaching a patch which pretty much fixes the Autoformats for RTL. However, after applying the patch, there are still two problems, which the attached screenshots illustrate: 1.The vertical line in the lavender autoformat is on the wrong side of the left column. 2.The rightmost digit in the currency strings go slightly out of the cell. Is this because the Israel currency symbol is slightly larger than other symbols that the designer of the autoformat had in mind? I'm not sure how to go about fixing these two minor problems.
Created attachment 44612 [details] Proposed patch
Created attachment 44613 [details] The vertical line is incorrectly to the left of the leftmost column
Created attachment 44614 [details] Note that the rightmost digits are slightly out of the cell area
I'll have a look at it next week
->ayaninger: The borders are painted in svx/source/dialog/framelink.cxx and framelinkarray.cxx (This will influence the Calc-AutoFormat dialog, too!) The table orientation does not necessarily meet the setting of Application::GetSettings().GetRTLLayout(). The right way to find the RTL/LTR setting is to call SwFEShell::IsTableRightToLeft() and propagate this information to the dialog. The currency problem does not occur with the relatively small EUR sign.
ayaniger->os: Thank you for pointing me to the code in framelink.cxx and framelinkarray.cxx. Re: table orientation: SwFEShell::IsTableRightToLeft() will give me the orientation of an existing table. However, if I am using AutoFormat to create a table, this won't help, since the table doesn't exist yet. In that case, wouldn't I have to use Application::GetSettings().GetRTLLayout()?
Created attachment 45463 [details] New patch, works for Calc-Autoformat dialog, too
ayaniger->os: Could you review this patch before I change the status to "FIXED"?
->dr: Please have a look at the Calc-patch. ->ayaniger: Regarding the table orientation you are right. If it is a to-be-created table then Application::GetSettings().GetRTLLayout() will do.
- In all patches, please use spaces instead of tabs. - In svx::frame::Array::GetCellIndex(), please replace the outdated 'BOOL' by the builtin 'bool' type, and of course, 'FALSE' -> 'false'. - In sc/source/ui/inc/autofmt.hxx, please replace 'BOOL bRTL' by 'bool mbRTL' (leading m for new class members).
->dr: I'm attaching a revised patch with the fixes you requested. I made those fixes only in my new code, not elsewhere in the file, so the context lines still contain tabs and "BOOL".
Created attachment 45512 [details] tabs removed, BOOL->bool, bRTL->mbRTL
Nothing to complain anymore from my side ;-)
Oliver, Daniel: could you please comment the status. Is it ready for integration? That would allow us to change the target to 2.3.
Yes, no problem
Target changed to 2.3 Reassigning to me to integrate the patch
Created attachment 46133 [details] misaligned dialog in Calc
->ayaniger: I've attached a screenshot of the Calc AutoFormat dialog. The Writer dialog is o.k.
Created attachment 46307 [details] Also fixes misaligned dialog in Calc
In class AutoFmtPreview (file sc/source/ui/miscdlgs/autofmt.cxx), please pass the parameter "pDoc" from the c'tor to the Init() function. This saves the "ugly" steps to get the document from the SfxObjectShell::GetFirst() call.
->dr: I also use those steps to get the current tab, so that I can check if it's RTL. Is there another way of checking if the current tab is RTL?
Right, I missed that, sorry. So your way is the way to go. An alternative is to additionally pass the RTL flag to the c'tor, or to pass the ScViewData instead of the ScDocument, which may be the "cleaner" solution.
So I'll leave the patch as is. If someone wants to implement one of the alternatives you suggested, I'll reassign the issue. For now, I'll mark the issue as "Fixed".
ayaniger->dr, os: I'd like this to be integrated in to a cws. What should I do?
If dr aggrees I'll create a cws next week to integrate the patch. Target changed to 2.4 and reassigned.
Sorry, I missed this issue. As it was set to fixed it was not part of the usual queries :-( Target changed to 3.0 Applied in cws os112
Reassigned for verification
Verified fix in CWS os112.
*** Issue 77870 has been marked as a duplicate of this issue. ***
SBA: Verified in DEV300m19. Closed.