Created attachment 68410 [details] snapshot of spreadsheet containing cells containing Arabic text with diacritics and cells pointing to them Processor (CPU): Intel(R) Core(TM)2 Quad CPU @ 2.40GHz Speed: 1,596.00 MHz Cores: 4 OS: Linux 2.6.34.10-0.6-desktop x86_64 System: openSUSE 11.3 (x86_64) KDE: 4.4.4 (KDE 4.4.4) "release 3" LibreOffice 3.4.2 OOO340m1 (Build:1206) (Please refer to snapshot.) Cell J721 contains arabic دَقَِّ (d^fatHa q^shadda^fatHa) where the shadda and fatHa are stacked in correct order. Cell I721 points to cell J721 with code: "=IF(CODE(J721)=45,L721,J721)". One would expect it to display the same thing as cell J721. However, it displays دَقِِّ (d^fatHa q^kasra^shadda). Since the more or less diagonal stroke meant as a fatHa (for vowel "a") is now placed below the shadda (more or less a wiggle), it now takes the function of kasra (for vowel "i"). The same thing happens for (e.g.) cells I725 and J725, also visible on the snapshot.
Are you using a specific font? Because all the fonts I have installed show both the same way regardless of order (fatHa^shadda or shadda^fatHa), so I couldn't really test it.
(In reply to comment #1) > Are you using a specific font? Because all the fonts I have installed show > both the same way regardless of order (fatHa^shadda or shadda^fatHa), so I > couldn't really test it. I am using Arial in the columns with Arabic text. The text got there from the Insert -> Special Character menu from the "Basic Arabic" group. Just now I noticed that the "qaaf" in my example does not only have shadda^fatHa, but also kasra with it. The latter does not belong there as far as correct Arabic is concerned. I am not sure if this extra "burden" helped create the (minor) problem.
Could not reproduce on neither LibreOffice 3.5.1.2 nor LibreOffice 4.0.0.0.alpha0+. Would you mind attaching the file itself?
Created attachment 70261 [details] small file showing super- and subscripts rendered differently in pointing cell, and instances of missed laam-'alif ligatures Please refer to 56647 and 55844.
(In reply to comment #3) > Could not reproduce on neither LibreOffice 3.5.1.2 nor LibreOffice > 4.0.0.0.alpha0+. > Would you mind attaching the file itself? I will attach a strongly downsized file with the same issues in it. Column A cells point to contents of respective column B cells. -line 1: d^(a)q^(s+a)_(i) in column B rendered incorrectly as d^(a)q^(s+i); -line 2: d^(a)q^(s+a) in column B rendered correctly as d^(a)q^(s+a); -line 3: d^(a)l^(s+a)_(i) in column B rendered incorrectly as d^(a)l^(s+i); -line 4: q^(a)Ay^(h+aa)_(i)lA in column B rendered correctly (i.e. exact copy) as q^(a)Ay^(h+aa)_(i)lA; BUT column B contents were entered by first entering q^(a)Ay^(h)_(i)l^(aa)A, then putting cursor at end of text, then entering backspace twice (from which I expected that the cursor would be just behind l), and then entering double fatHa (i.e. fatHa plus nunation), so instead of on laam the double fatHa are shown on y^(h); -line 5: everything in order; -line 6: created by first entering q^(a)Ay^(h+aa)_(i)l, then hitting <return> (cursor leaves cell), then putting cursor back at end of q^(a)Ay^(h+aa)_(i)l, then entering ^(aa)A; -line 7: creation quite similar as that in line 6 (although precise order of actions forgotten). The laam-'alif presentations in lines 4, 6, and 7 are incorrectly shown without the laam-'alif ligature.
[I will attach] (see comment 5) => [I have attached] (see comment 4)
Created attachment 70266 [details] snapshot of spreadsheet containing cells with Arabic text with presentation in pointing cells different from original and with(out) missed laam-'alif ligatures snapshot of screen with spreadsheet page with lines 1-7 opened
Created attachment 70292 [details] Windows screenshot That's how your table does look on my machine.
Created attachment 70398 [details] screen print showing different displays in two columns of which one points to the other (cellwise) (In reply to comment #8) > Created attachment 70292 [details] > Windows screenshot > > That's how your table does look on my machine. That is very funny: your attachment shows things my machine does not show, not even with enlargement to 300%. That means that from the look of my screen I cannot (always) judge what is actually stored in those cells. Your attachment also shows at least some of the discrepancies between the right column and the left column (that points to the right column's contents) that I also encountered. I wonder how you made all these double(d) letters visible on your screen. If they are traces of my input, I would like to have something that really and clearly displays me what the contents of the cells are, instead of the views I get on my screen.
Created attachment 70399 [details] screenshot showing discrepancies in two columns of which left one points to contents of right one (cellwise) Excuse me: I seem to have to indicate the file type. I hope I did it in a helpful way this time. For remaining part of comment, please refer to my previous comment.
Created attachment 70432 [details] Source cells content That's what your source cells contain.
(In reply to comment #11) > Created attachment 70432 [details] > Source cells content > > That's what your source cells contain. Thanks for displaying the contents in a different way. I am still puzzled. In your opinion: 1) did I report things that relate to (a) bug(s)? 2) (how) can I have the cell contents displayed properly, i.e. a) in the "correct" way (for Arabic), and b) in a way that tells me what I entered? 3) is there a simple, "natural" way of entering Arabic text that prevents the - to me at least - strange appearance of certain pieces of Arabic text, and, if so, which is it? 4) (how) can I get the same (correct) appearance in both original and pointing cell? Up to now I have been entering Arabic text from the menu Insert -> Special Character -> Basic Arabic (in Arial). Thanks!
(In reply to comment #11) > Created attachment 70432 [details] > Source cells content > > That's what your source cells contain. As far as I can see and understand the code in your attachment, I can discover nor understand: A) why and how different sequences of entering text should result in different contents and displays of the laam-'alif sequence; B) why and how using backspace EXACTLY twice starting with a cursor at what I think is the end of a word brings me back into the word MORE than two positions; C) why and how the pointing cell displays the contents of the original cell in a different way than the latter. Is this puzzling anyone else, or just me? Thanks!
The ligatures look differently because they are composed from various fonts and cannot "ligate" with each other. The BACKSPACE key is deleting the entire graphemes for complex scripts, so it can delete several characters at the time. The functions which refer the cell contents are taking the text without applied formatting, so they display it as they should. To fix your table, try to cut the offending cells, paste them into Kate or GEdit, then cut them once again and paste in their original place.
(In reply to comment #14) > The ligatures look differently because they are composed from various fonts > and cannot "ligate" with each other. > The BACKSPACE key is deleting the entire graphemes for complex scripts, so > it can delete several characters at the time. > The functions which refer the cell contents are taking the text without > applied formatting, so they display it as they should. > > To fix your table, try to cut the offending cells, paste them into Kate or > GEdit, then cut them once again and paste in their original place. * I am not aware of having entered characters from various fonts, as I entered all from Insert -> Special Charactres -> Basic Arabic (within Arial). I understand you mean the software did this for/to me. * Deletion of several characters at a time makes sense to me in the case of a laam-'alif ligature. * I am not aware of applying any specific formatting by myself; all I was aware of is that I picked the Arabic letters one by one from the said menu. I understand you are hinting at some formatting done by the software automatically. * Thanks for the suggestion for how to improve my table! * It is still not clear to me if I reported (symptoms of) a bug, or if I have just missed some understanding of how to use LibreOffice Calc in a sensible and appropriate way.
Yes, that's the bug with "Ïnsert Special character" feature or somewhere along this line.
(In reply to comment #16) > Yes, that's the bug with "Ïnsert Special character" feature or somewhere > along this line. Thanks a lot for your explanations!
*** Bug 56647 has been marked as a duplicate of this bug. ***
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.5 or 5.1.0) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-02-21
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.2.5 or 5.3.0 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170306
Dear b.patrick, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Dear b.patrick, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
(In reply to Urmas from comment #14) > To fix your table, try to cut the offending cells, paste them into Kate or > GEdit, then cut them once again and paste in their original place. Which should be equivalent to copying then pasting as unformatted text, I imagine. Trying to isolate one example to focus on: 1. Use Noto Sans Arabic font 2. With Special Character dialog, insert U+644 ("arabic letter lam") in cell A1 3. In same cell, same dialog, same font, insert U+627 ("arabic letter alef") 4. See that they don't use the ligature 5. Copy cell A1, paste unformatted in B1 6. See that Lohit Devanagari font does use the lam-alef ligature 7. Change font in cell B1 to Noto Sans Arabic; compare A1 and A2. Result: A1 does not use the ligature, A2 does. Reproduced in: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 2cac2ee38445c19c9281f54c2b961bbc9149cc00 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
Adding some related bug reports, likely some duplication in the mix.