|
Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
|
Description
sforbes
2004-12-23 13:32:38 UTC
Created attachment 20800 [details]
exmple
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... Created attachment 20801 [details]
exported doc
last note- when exporting to PDF, the object is displayed like in OOo: incorrect LTR 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. 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 *** sj: The bugdoc can be loaded properly with the fix of issue 23413 -> closed Please reopen, if I mistake. ayaniger -> sj: In m109, the problem still exists. RTL fontwork text is displayed LTR. 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. 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) Created attachment 27607 [details]
Note RTL fontwork in slide 2
Created attachment 27608 [details]
The presentation as it appears in PowerPoint
Created attachment 27609 [details]
The imported presentation as it appears in Impress on Windows (OK)
Created attachment 27610 [details]
The imported presentation as it appears in Impress on Linux (not OK)
Created attachment 27612 [details]
Fontwork entered in a new presentation in Windows (OK)
Created attachment 27613 [details]
The same fontwork entered in a new presentation in Linux (not OK)
reopened 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. 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. 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. 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. *** Issue 36932 has been marked as a duplicate of this issue. *** 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. Created attachment 29166 [details]
proposed patch
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. 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 I will have to ask HDU, why certain fonts shows up correctly and others not. He is having more font knowledge. 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? 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. > 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?
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. Created attachment 33955 [details]
Debug output for Fontwork with Hebrew text
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. 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) Tahoma does not appear in the list in xfonstsel. 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. 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. Created attachment 33960 [details]
Debug output witrh HDU_DEBUG enabled in vcl/source/glyphs
So Tahoma is aliased to another font. Check the pspfontcache file please. I don't see it there either. The file is attached (~/.openoffice.org2/user/psprint/pspfontcache). Created attachment 33961 [details]
pspfontcache
Are you really sure it is not an X11 font? Please also recompile vcl/unx/source/gdi with HDU_DEBUG 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. Created attachment 33962 [details]
Debug output witrh HDU_DEBUG enabled in vcl/unx/source/gdi
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. 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. 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? Please attach the sample doc that was used for the debug.out and the latest screenshots. The fw.doc provided doesn't match. 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. Created attachment 33998 [details]
Documents, debug output, and screenshots
HDU->HDU reminder: I looks like vcl/source/gdi/sallayout.cxx's ImplLayoutArgs::PrepareFallback() is mishandling RTL runs. Created attachment 34039 [details]
found the root cause: the x11 -> outline converter didn't ignored BiDi
hdu->ayaninger: please test and verify the attached od3_xoutl.patch ayaniger -> hdu Verified the fix on Linux. 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). 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 HDU->SBA: Please verify in CWS vcl54. re-open issue and reassign to sba@openoffice.org reassign to sba@openoffice.org reset resolution to FIXED 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? Sorry, this is not a problem. The text in the text editor was left-aligned instead of right-aligned. SBA: Verified in CWS vcl54. SBA: OK in 680m169. Closed. |