Issue 39518 - fontwork incorrectly displayes RTL text as LTR
Summary: fontwork incorrectly displayes RTL text as LTR
Status: CLOSED FIXED
Alias: None
Product: Writer
Classification: Application
Component: code (show other issues)
Version: 680m65
Hardware: PC Windows Server 2003
: P3 Trivial (vote)
Target Milestone: ---
Assignee: stefan.baltzer
QA Contact: issues@sw
URL:
Keywords:
: 36932 (view as issue list)
Depends on: 35203
Blocks:
  Show dependency tree
 
Reported: 2004-12-23 13:32 UTC by sforbes
Modified: 2013-08-07 14:40 UTC (History)
3 users (show)

See Also:
Issue Type: PATCH
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
exmple (8.01 KB, application/vnd.sun.xml.writer)
2004-12-23 13:33 UTC, sforbes
no flags Details
exported doc (9.50 KB, application/msword)
2004-12-23 13:40 UTC, sforbes
no flags Details
Note RTL fontwork in slide 2 (287.50 KB, application/vnd.ms-powerpoint)
2005-07-01 10:42 UTC, alan
no flags Details
The presentation as it appears in PowerPoint (173.41 KB, image/jpeg)
2005-07-01 10:45 UTC, alan
no flags Details
The imported presentation as it appears in Impress on Windows (OK) (187.23 KB, image/jpeg)
2005-07-01 10:46 UTC, alan
no flags Details
The imported presentation as it appears in Impress on Linux (not OK) (173.11 KB, image/jpeg)
2005-07-01 10:47 UTC, alan
no flags Details
Fontwork entered in a new presentation in Windows (OK) (92.51 KB, image/jpeg)
2005-07-01 10:50 UTC, alan
no flags Details
The same fontwork entered in a new presentation in Linux (not OK) (101.44 KB, image/jpeg)
2005-07-01 10:51 UTC, alan
no flags Details
proposed patch (2.88 KB, patch)
2005-08-30 13:23 UTC, alan
no flags Details | Diff
Debug output for Fontwork with Hebrew text (253.12 KB, text/plain)
2006-02-08 15:48 UTC, alan
no flags Details
Debug output witrh HDU_DEBUG enabled in vcl/source/glyphs (158.99 KB, text/plain)
2006-02-08 17:39 UTC, alan
no flags Details
pspfontcache (19.01 KB, text/plain)
2006-02-08 18:00 UTC, alan
no flags Details
Debug output witrh HDU_DEBUG enabled in vcl/unx/source/gdi (174.39 KB, text/plain)
2006-02-08 18:35 UTC, alan
no flags Details
Documents, debug output, and screenshots (118.98 KB, application/x-compressed)
2006-02-09 11:14 UTC, alan
no flags Details
found the root cause: the x11 -> outline converter didn't ignored BiDi (1.08 KB, patch)
2006-02-10 09:17 UTC, hdu@apache.org
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description sforbes 2004-12-23 13:32:38 UTC
fontwork incorrectly displayes RTL text as LTR.

to repro:
* make sure that "enable CTL" is marked under the prefrences, and that the
RTL/LTR buttons are on the toolbar.
* insert anew fontwork object
* Edit the text, and make sure it is set is RTL (have it mixed with some neutral
characters for easy recognition of directionality)

Actual result: when finished editing, the RTL text is displayed LTR in fontwork

Expected result: Fontwork shuld show the text RTL

See attached example
Comment 1 sforbes 2004-12-23 13:33:23 UTC
Created attachment 20800 [details]
exmple
Comment 2 sforbes 2004-12-23 13:39:49 UTC
it is intresting to note that when exporting the file as doc and opening in word
2003, the object displays correctly as RTL, making MS Office better then OOo in
displaying a file created in OOo...
Comment 3 sforbes 2004-12-23 13:40:51 UTC
Created attachment 20801 [details]
exported doc
Comment 4 sforbes 2004-12-23 13:41:30 UTC
last note- when exporting to PDF, the object is displayed like in OOo: incorrect LTR
Comment 5 michael.ruess 2004-12-23 15:19:33 UTC
MRU->SJ: when e.g. entering Hebrew text into a fontwork object as described,
characters like dots are erroneously placed at the right end of the text.
Compare it with text insertion in a normal Writer document.
Comment 6 sven.jacobi 2005-01-18 14:48:50 UTC
sj: This issue is double to issue 23413. And yes, it is on my plan to add the
bidi support for FontWork for OOo 2.0


*** This issue has been marked as a duplicate of 23413 ***
Comment 7 sven.jacobi 2005-01-28 16:17:58 UTC
sj: The bugdoc can be loaded properly with the fix of issue 23413 -> closed

Please reopen, if I mistake.
Comment 8 alan 2005-06-30 09:58:42 UTC
ayaniger -> sj:
In m109, the problem still exists. RTL fontwork text is displayed LTR.
Comment 9 sven.jacobi 2005-06-30 11:45:17 UTC
sj->ayaniger: I do not see a problem, maybe you verified this issue by loading
the fw.odt, this does now work, because the document is already corrupt. You
have to load the original (fw.doc) to see the improvement.

I would be pleased if you can affirm my assumption.
Comment 10 alan 2005-07-01 10:40:18 UTC
ayaniger -> sj:
I verified by installing m109 on Debian Linux 3.1, and:
a) entering new fontwork in Writer and Impress
b) imported a Powerpoint document with RTL fontwork (which I'm attaching to this
issue)
In both cases the RTL font work is reversed.

After your previous comment, I installed the Windows version of m109, and saw
that the problem did not exist there. However, it does exist on Linux.

I'm attaching screenshots of the various scenarios:
1) The presentation as it appears in PowerPoint
2) The imported presentation as it appears in Impress on Windows (OK)
3) The imported presentation as it appears in Impress on Linux (not OK)
4) Fontwork entered in a new presentation in Windows (OK)
5) The same fontwork entered in a new presentation in Linux (not OK)

Comment 11 alan 2005-07-01 10:42:58 UTC
Created attachment 27607 [details]
Note RTL fontwork in slide 2
Comment 12 alan 2005-07-01 10:45:28 UTC
Created attachment 27608 [details]
The presentation as it appears in PowerPoint
Comment 13 alan 2005-07-01 10:46:47 UTC
Created attachment 27609 [details]
The imported presentation as it appears in Impress on Windows (OK)
Comment 14 alan 2005-07-01 10:47:45 UTC
Created attachment 27610 [details]
The imported presentation as it appears in Impress on Linux (not OK)
Comment 15 alan 2005-07-01 10:50:06 UTC
Created attachment 27612 [details]
Fontwork entered in a new presentation in Windows (OK)
Comment 16 alan 2005-07-01 10:51:18 UTC
Created attachment 27613 [details]
The same fontwork entered in a new presentation in Linux (not OK)
Comment 17 sven.jacobi 2005-07-01 11:39:47 UTC
reopened
Comment 18 sven.jacobi 2005-07-01 11:49:53 UTC
sj->ayaniger: Many thanks for your detailed description.

sj->hdu: My first thought is that the method OutputDevice::GetTextIsRTL which is
used in svx/source/msfilter/msdffimp.cxx is returning the wrong value on
platforms other than Windows. I changed the target to OO Later, because I think
that your work load is very huge at the moment, but it would be nice if you
still could fix this for OOo 2.01.

Comment 19 alan 2005-07-01 12:34:25 UTC
ayaniger-> sj (& hdu):
I don't think that the problem is in OutputDevice::GetTextIsRTL called in 
svx/source/msfilter/msdffimp.cxx. In my build, I tested this code, and found
that it was recognizing RTL Fontwork as RTL. 
Comment 20 alan 2005-07-01 12:37:14 UTC
ayaniger-> hdu:
If you cannot get this problem soon becauseof your work load, I would be
grateful for other ideas that you have about solving this problem.
Comment 21 hdu@apache.org 2005-07-05 16:19:57 UTC
hdu->sj: Since the suspicion that OutputDevice::GetTextIsRTL() returns a wrong
value in this case has been shown to be wrong, so I'm reassigning back. I'll be
glad to assist debugging the problem in fontworks when you're attacking the problem.
Comment 22 alan 2005-08-01 10:36:02 UTC
*** Issue 36932 has been marked as a duplicate of this issue. ***
Comment 23 alan 2005-08-30 13:21:25 UTC
I'm submitting a patch which solved the problem for me. I take the string and
call the icu functions which reorder it. I imagine that you will probably not
want to leave this function as it is, particularly since it's a global function,
but this may help you towards the fix in its final form.
Comment 24 alan 2005-08-30 13:23:01 UTC
Created attachment 29166 [details]
proposed patch
Comment 25 alan 2006-01-05 11:34:33 UTC
In the power point example above, the font of the WordArt object is "Arial
Black". Arial Black is not on the machine where the screenshots above were
created. If one installs the "culmus" Hebrew fonts found at
http://culmus.sourceforge.net/download.html
and substitutes one of them for "Arial Black", the text is fine. ("Ellinia" and
"Ellinia CLM" are exceptions, and cause the text to appear backwards.) This
works whether you substitute manually, or use the font substitution table. The
problem, therefore, stems from OOo's way of choosing which font to use when the
specified font is missing. 
Comment 26 alan 2006-02-06 06:41:58 UTC
ayaniger->sj:

Could you help me understand why with certain fonts Hebrew text shows up
reversed and with other fonts it shows up correctly? 
Which properties in the font would affect this?
This is an important issue in Hebrew OOo, and I would like to work on it.

Thanks,
Alan
Comment 27 sven.jacobi 2006-02-07 09:30:09 UTC
I will have to ask HDU, why certain fonts shows up correctly and others not. He
is having more font knowledge.
Comment 28 hdu@apache.org 2006-02-07 12:11:34 UTC
Does the fontwork stuff use the layout engines in VCL but tries to do its own
thing? If yes, is the layout mode set correctly?
Comment 29 sven.jacobi 2006-02-07 12:53:35 UTC
sj->hdu:

In MS Office the text direction depends to the string that is used, in OOo this
direction is determined by the OutputDevice::GetTextIsRTL method. So can you
please tell me whats to do, to get the proper direction, I have no idea.
Comment 30 hdu@apache.org 2006-02-07 14:44:48 UTC
> Could you help me understand why with certain fonts Hebrew text shows up
> reversed and with other fonts it shows up correctly?
> Which properties in the font would affect this?

These factors determine the layout engine used:
- Font type (TTF, Type1, X11, OTF)
- Platform (Win32, UNX)
- Text (CTL, Simple)

It looks like you are seeing problems with Type1 fonts on WIN32?
Comment 31 alan 2006-02-08 15:45:43 UTC
I am having problems on Linux. I built 2.0.1, enabling HDU_DEBUG in the
GetFallback function in outdev3.cxx. When I create a fontwork object using style
"Favorite 1", OOo looks for Tahoma, doesn't find it, and falls back to "Lucida
Sans". (I am attaching debug output, which I hope I am interpreting correctly.)
When I change the text to Hebrew, the string appears reversed in the 
Lucida Sans font. However, if I then explicitly change the font to "Lucida
Sans", the string appears correct. 
Comment 32 alan 2006-02-08 15:48:34 UTC
Created attachment 33955 [details]
Debug output for Fontwork with Hebrew text
Comment 33 alan 2006-02-08 15:51:44 UTC
I am not sure of the type of the Lucida Sans being used. It is not in the OOo
share/fonts/truetype directory. It seems to have been installed as part of my
Debian testing installation.
Comment 34 hdu@apache.org 2006-02-08 16:35:17 UTC
Tahoma is available on your system, it just doesn't contain Hebrew characters.
Is Tahoma available as X11 font? (use e.g. xfontsel to find this out)
Comment 35 alan 2006-02-08 16:54:50 UTC
Tahoma does not appear in the list in xfonstsel.
Comment 36 hdu@apache.org 2006-02-08 17:16:29 UTC
Tahoma or a font with this alias must be somewhere on your system. Use e.g. the
pspfontcache file (in user settings) to find out where. Or recompile
vcl/source/glyphs/ with HDU_DEBUG enabled.
Comment 37 alan 2006-02-08 17:37:15 UTC
I compiled vcl/source/glyphs/ with HDU_DEBUG enabled, and while I can see the
full paths of many fonts, I don't see a path for Tahoma. I'm attaching the debug
output.
Comment 38 alan 2006-02-08 17:39:37 UTC
Created attachment 33960 [details]
Debug output witrh HDU_DEBUG enabled in vcl/source/glyphs
Comment 39 hdu@apache.org 2006-02-08 17:56:36 UTC
So Tahoma is aliased to another font. Check the pspfontcache file please.
Comment 40 alan 2006-02-08 17:59:37 UTC
I don't see it there either. The file is attached
(~/.openoffice.org2/user/psprint/pspfontcache).
Comment 41 alan 2006-02-08 18:00:40 UTC
Created attachment 33961 [details]
pspfontcache
Comment 42 hdu@apache.org 2006-02-08 18:21:18 UTC
Are you really sure it is not an X11 font? Please also recompile
vcl/unx/source/gdi with HDU_DEBUG 
Comment 43 alan 2006-02-08 18:34:21 UTC
I checked again in xfontsel: there's no Tahoma in the list. There's nothing
between the fonts "symbol" and "terminal". 

I also compiled vcl/unx/source/gdi with HDU_DEBUG. The output is attached.
Comment 44 alan 2006-02-08 18:35:54 UTC
Created attachment 33962 [details]
Debug output witrh HDU_DEBUG enabled in vcl/unx/source/gdi
Comment 45 alan 2006-02-08 18:58:14 UTC
Another bit of info : I tried copying a Tahoma ttf file from Windows and
installing it on OOo using spadmin. After I did that, the Hebrew Fontwork string
was not reversed.
Comment 46 hdu@apache.org 2006-02-09 07:55:17 UTC
For some reason the X11 font helvetica is used instead of Tahoma. See these
lines in the debug output:
   SetFont(lvl=0,"Tahoma", 0*94, naa=1,b=5,i=0) => "Helvetica"
   XLoadFont "-adobe-helvetica-medium-r-normal--34-*-*-*-p-*-iso10646-1" => 1

For some reason the glyph fallback request in vcl/unx/source/gdi/xfont.cxx's
X11FontLayout::LayoutText() method seems to have problems with RTL.
Comment 47 alan 2006-02-09 08:10:56 UTC
Helvetica appears in xfontsel. However, it does not appear in the list of fonts
in OOo. Is this behavior of OOo correct?

Regarding xfont.cxx's problem with RTL, will you be able to look into this? Is
there something that I can do to help?
Comment 48 hdu@apache.org 2006-02-09 10:31:32 UTC
Please attach the sample doc that was used for the debug.out and the latest
screenshots. The fw.doc provided doesn't match.
Comment 49 alan 2006-02-09 11:13:08 UTC
I'm attaching two documents, one which displays the Hebrew fontwork correctly,
and one which displays it reversed. I'm also attaching a debug output file and a
screenshot for each document.
Comment 50 alan 2006-02-09 11:14:19 UTC
Created attachment 33998 [details]
Documents, debug output, and screenshots
Comment 51 hdu@apache.org 2006-02-09 17:17:18 UTC
HDU->HDU reminder: I looks like vcl/source/gdi/sallayout.cxx's
ImplLayoutArgs::PrepareFallback() is mishandling RTL runs.
Comment 52 hdu@apache.org 2006-02-10 09:17:05 UTC
Created attachment 34039 [details]
found the root cause: the x11 -> outline converter didn't ignored BiDi
Comment 53 hdu@apache.org 2006-02-10 09:20:18 UTC
hdu->ayaninger: please test and verify the attached od3_xoutl.patch
Comment 54 alan 2006-02-12 06:34:38 UTC
ayaniger -> hdu
Verified the fix on Linux.
Comment 55 hdu@apache.org 2006-02-13 08:51:25 UTC
Thanks.

The program shouldn't get into this part of the code for CTL or BiDi stuff, but
"partial glyph fallback" is not implemented yet for text outlines (issue 35203).
Comment 56 hdu@apache.org 2006-02-13 12:33:16 UTC
Fixed in CWS vcl54.

Testing instruction:
- Load the bugdocs.
- Select a font that is only available as X11 font for the text.
=> The outline is reversed
Comment 57 hdu@apache.org 2006-02-22 10:17:14 UTC
HDU->SBA: Please verify in CWS vcl54.

re-open issue and reassign to sba@openoffice.org
Comment 58 hdu@apache.org 2006-02-22 10:17:18 UTC
reassign to sba@openoffice.org
Comment 59 hdu@apache.org 2006-02-22 10:17:22 UTC
reset resolution to FIXED
Comment 60 alan 2006-02-22 21:08:10 UTC
There is a problem on the Windows version. RTL text alone looks fine, but mixed
RTL and LTR text does not. If my string has LTR text between two RTL texts, the
RTL texts get switched. That is, if the string contains English between two
Hebrew words, such as:
2WERBEH ENGLISH 1WERBEH
I will see:
1WERBEH ENGLISH 2WERBEH
On Linux, this problem does not happen.
Should this be filed as a seperate issue?
Comment 61 alan 2006-02-22 21:18:54 UTC
Sorry, this is not a problem. The text in the text editor was left-aligned
instead of right-aligned. 
Comment 62 stefan.baltzer 2006-03-24 15:49:57 UTC
SBA: Verified in CWS vcl54.
Comment 63 stefan.baltzer 2006-05-19 13:19:49 UTC
SBA: OK in 680m169. Closed.