Apache OpenOffice (AOO) Bugzilla – Issue 91465
SwTxtNode::GetLang() ignores nScript parameter
Last modified: 2013-08-07 14:43:11 UTC
While debugging my changes of issue 60591, I noticed an apparent bug in SwTxtNode::GetLang(). If pSwpHints == NULL, the function will not evaluate the nScript parameter, and eventually return a LATIN language, when CTL was requested. In my debugging case, it disrupted the kashida justification when mixing English and Arabic in a text line. I think this could also disrupt justification of other CTL or Asian languages. Attaching a patch.
Created attachment 55006 [details] patch for file sw/source/core/txtnode/thints.cxx
MRU->AMA: please have a look at this patch proposal. If you are not the correct developer for this, please reassign to proper person, thanks!
ama->fme: Please have a look!
fme->hennerdrewes: Thank you for your patch. I'll have a look.
@fme: When I was debugging the kashida justification, I had the following case: In one line I had English text followed by Arabic, separated by a blank. The formatting of the line was completely broken, words were placed beyond the page margin. This didn't happen with my kashida patches in 2.4.1 code, only in dev300_xxx. When the justification type is determined by asking for the language attribute, the nScript parameter gets ignored if pSwpHints == NULL. (Apparently there was a pSwpHints in 2.4.x, but now there is not.) As nScript was ignored, and break iterator looked only at the first character of the Arabic run (the blank), the Latin language is returned. As this will probably also happen for other special justifications (e.g. Thai), it might be a good idea to include this fix in 3.0.
fme->hennerdrewes: Thank you for your patch. Yes, I think you are right, the code needs to be changed here. But what's puzzling me is this: [...] In one line I had English text followed by Arabic, separated by a blank. [...] As nScript was ignored, and break iterator looked only at the first character of the Arabic run (the blank), the Latin language is returned. [...] I wonder why the blank that's located between the English and Arabic text is part of the Arabic portion instead of the English portion. I think the first character of a portion usually should be of the same script type as the rest for the portion. Therefore this shouldn't be much of a problem. Can you attach a document?
I worked with the kashida.odt document from the other Arabic issues, I'll attach it again. But there might be another problem involved: I deliberately changed CTL language attributes on selected text ranges (to Hebrew) in the document to see, how the justification reacts on that. Expected results: kashida justification should switch to regular blank justification. Observed results: Apparently my language choices were not always applied to the text. Sometimes I still had blank justification, although the status bar reported Arabic (Egypt) as the current language. At a certain stage, the spellchecker marked Arabic words: My conclusion: somewhere in the program the LATIN language was reported instead of the CTL (Arabic) language. (I don't have a spellchecker for neither Arabic or Hebrew installed, so it must be LATIN). Finally, I managed to get rid of this chaos by selecting all the text and applying Arabic (Jordan) to it, Arabic (Egypt) didn't work. I don't know if you will manange to reproduce my observings with the original document. Also my kashida patches might influence the results, though I doubt that the language chaos is influenced by this.
Created attachment 55051 [details] sample doc
fme->hennerdrewes: Well, I can't see a problem with the bugdoc in a current DEV300m23.
Created attachment 55053 [details] modified patch
You are right. Apparently the problems I observed are connected to the kashida changes I made. So this issue is probably less critical than I thought. Anyhow, with the modifications to the patch I just posted, everything seems to work fine with my kashida patches
@hennerdrewes: Thank you for your patch!
Verified by developer.
This issue is closed automatically. It should be fixed in a version with is available for longer than half a year (OOo 3.1). If you think this issue isn't fixed in the current version (OOo 3.2) please reopen it. But then please pay attention about the field 'target milestone'. The closure was approved by the Release Status Meeting at 22nd of February 2010 and it is based on the issue handling guideline for fixed/verified issues : http://wiki.services.openoffice.org/wiki/Handle_fixed_verified_issues