(*** This bug was imported into bugs.kde.org ***) Package: kword Version: post1.1 (WYSIWYG) (using KDE 3.0.5 (CVS HEAD >= 20020327)) Severity: normal Installed from: compiled sources Compiler: gcc version 2.96 20000731 (Mandrake Linux 8.3 2.96-0.79mdk) OS: Linux (i686) release 2.4.18-rc4 OS/Compiler notes: With KDE3 and koffice we can write docs in Hebrew. Normal writing is OK but other things are still left-to-right for example: bullets and numbers automatic right alignment for hebrew paragraph increase indent should be to the left. I guess there are more examples. (Submitted via bugs.kde.org) (Called from KBugReport dialog)
On Monday 15 April 2002 14:08 oren@mindcitetech.com wrote: > Package: kword > Version: V1.1.1 for KDE3.0 (using KDE 3.0.0 ) > Severity: normal > Installed from: RedHat RPMs > Compiler: Not Specified > OS: Linux > OS/Compiler notes: Not Specified > > Unlike KMail You cannot write Right-To-Left text properly in KWord. > > You cannot set the direction of a paragraph to be right-to-left Ok I'm working on RTL right now. I have fixed all WYSIWYG-related problems but the question of paragraph direction remains. Qt has 4 alignments: Auto Left Justify Right Center. Hmm I can't count that's 5 ;-) But how should a word processor work? I don't think that having those 5 alignments as toolbar buttons would work "Auto" would be much too hard to explain to an end user particularly a LTR one. [The current problem is that we use Auto initially so it works when typing but when saving and loading the value "left" is stored so the paragraph is re-created as left-aligned instead of Auto and there's no way to come back to Auto again]. Here's the way I see this instead please tell me if that would work: the initial alignment is "Auto" and when the first char of the paragraph is typed the alignment is determined and _applied_ to the paragraph which will remember if it's Left or Right aligned and the corresponding toolbar button will be checked. This means in other words: 1- the current button is "Left alignment" 2- you start typing 3- automatically the "Right alignment" button becomes pressed and the paragraph indeed becomes right aligned. To change the alignment one can use the "Left align" button (which in this case is equivalent to an LTR user clicking the "right-align" button i.e. it's a case that happens rather rarely). Is this how other word processors do it? Any better way? -- David FAURE david@mandrakesoft.com faure@kde.org http://people.mandrakesoft.com/~david/ http://www.konqueror.org/ KDE Making The Future of Computing Available Today
On Monday 15 April 2002 17:41 David Faure wrote: [...] > Here's the way I see this instead please tell me if that would work: > the initial alignment is "Auto" and when the first char of the paragraph > is typed the alignment is determined and _applied_ to the paragraph > which will remember if it's Left or Right aligned and the corresponding > toolbar button will be checked. > This means in other words: > 1- the current button is "Left alignment" > 2- you start typing > 3- automatically the "Right alignment" button becomes pressed > and the paragraph indeed becomes right aligned. > To change the alignment one can use the "Left align" button > (which in this case is equivalent to an LTR user clicking the "right-align" > button i.e. it's a case that happens rather rarely). > > Is this how other word processors do it? Any better way? Hello Your suggestion looks OK. Here are some more topics to consider when implementing RTL (from open office page) http://sw.openoffice.org/drafts/BiDiLayout.html I forgot to mention in the problem report some topics that are mentioned in the above page (e.g tables status bar etc) Thanks Eyal
> 1- the current button is "Left alignment" > 2- you start typing If I open a paranthesis after changing the lang to Arabic and type Arabic the paranthesis direction is incorrect. 3- automatically the "Right alignment" button becomes pressed and the paragraph indeed becomes right aligned. Pressing Enter after this should leave the alignment to the right which is not the case now.
Fixed in KWord2