Created attachment 116186 [details] Plain-text sentence with diacritics to try out (UTF-8 charset) it can not possible to navigate in our document and read them character by character when we read persian or arabic document and it has diacritics. i mean open office and libreoffice dont consider diacritics in arabic and persian one of the character to be read and edit by left and arro keys. for example when we want to read and edit txt, if we move in the document by arro key and we want to edit it when it has diacritics its not easy. for example we read txt and we want to remove ّ tashdid from document completely when we use control h, in the first part we type ّ and the second part we dont type anything for replacement to remove ّ in all documents, its like sometime we dont have any ّ in our documents. it problem is true about all our diacritics َ، ُ، ِ، ّ، ًْ، ٌ، ٍ، ْ. i appreciate you if you solve these problems in libreoffice 4.5 or at least 5.
Hey Zahra - Can you explain the issue a bit clearer (preferably in numbered steps). Example: 1. Open attached document; 2. Place cursor.... 3. Do step Z . . . etc... Very hard to follow a paragraph of text - explain how to reproduce the issue with the document that you have attached. Also just FYI - almost guaranteed this will not be resolved by 5.0 or even 5.1 - we are a team of volunteers, if a volunteer finds that bug to be interesting, they will fix it, else, it will not be fixed. If you or someone you know is a developer, we'd happily help you understand the code so that you can get this issue resolved :) Setting to NEEDINFO - once you describe the issue clearly please set to UNCONFIRMED. Thanks!
> i appreciate you if you solve these problems in libreoffice 4.5 or at least 5. For the record, there will be no LibreOffice 4.5. Our next release will be called 5.0.
All bugs with priority=highest should have a Version set. As this has been waiting in NEEDINFO for a while, bumping priority down to 'high' until we can reproduce and triage.
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team Sun, 11 Sep 2016 12:29:16 +0200
(In reply to Joel Madero from comment #1) > Hey Zahra - > > Can you explain the issue a bit clearer (preferably in numbered steps). > > Example: > 1. Open attached document; > 2. Place cursor.... > 3. Do step Z > > . . . etc... > > Very hard to follow a paragraph of text - explain how to reproduce the issue > with the document that you have attached. > > Also just FYI - almost guaranteed this will not be resolved by 5.0 or even > 5.1 - we are a team of volunteers, if a volunteer finds that bug to be > interesting, they will fix it, else, it will not be fixed. If you or someone > you know is a developer, we'd happily help you understand the code so that > you can get this issue resolved :) > > Setting to NEEDINFO - once you describe the issue clearly please set to > UNCONFIRMED. Thanks! hi. i realy appreciate your efforts. my bug is duplicate of the bug. 100854 https://bugs.documentfoundation.org/show_bug.cgi?id=100854 its the same problem. its a very critical problem for me. because most of times, i use diacritics and cant use libreoffice easily. because libreoffice and openoffice dont recognize diacritics independently. they count diacritics as part of letter and when i want to navigate letter by letter, nvda reads only letter and not diacritics. for example: steps to reproduce: 1/copy this sentences in libreoffice writer and save it in docx or any format like docx. 2/ press control+h to activate find and replace. 3/ in the first fild, type ّ when your keyboard is set to persian. 4/ in the replace with type nothing. 5/ click okay for replace all. there are three ّ in this sentence. actual result: openoffice libreoffice say search key not found. expected behaviour: openoffice libreoffice should recognize the diacritics and behave them like normal letters. they should say three ّ was found and replace them as i mentioned. here you are the text for testing. ائمّه عليهم السّلام چراغهاي هدايت و كشتي نجات براي سعادت همه انسانها و تقرّب آنها به خداوند هستند.
[This is an automatic message] Changing version to 3.5.7.2 in order to get rid of 'preBibisect' version as 3.5.7.2 looks to be the last version not covered by bibisect-43all.
Setting to duplicate of 100854 per comment 5. *** This bug has been marked as a duplicate of bug 100854 ***
It is not a dup of #100854, as the latter deals with keyboard navigation, and this one with searching. Arabic diacritics indeed cannot be found via search/replace.
(In reply to Urmas from comment #8) > It is not a dup of #100854, as the latter deals with keyboard navigation, > and this one with searching. > > Arabic diacritics indeed cannot be found via search/replace. hello. its a duplicate of bug 100854 which i reported. both problems are about diacritics in farsi and arabic and i know that if one bug is solved, the other one is solved too!
hello again all. here you are another steps to reproduce: 1- copy شُكر in to writer. 2- go to the beginning of this word. 3- press left arrow key to navigate letter by letter and go to the end by left arrow key. 4- copy this word in wordpad or ms word and do the same in steps 2 and 3 and compare the result. 4 expected result: شُكر has four characters and libreoffice should consider ُ a seperate letter like other characters. actual result: ُ is not consider as a separate letter and we cant find it and edit it using left arrow key. there is no problem in using diacritics in wordpad and ms word. ُ is one example of diacritics and the problem is true for all diacritics including َ ِ ُ ّ ْ ً ٌ ٍ
*** Bug 100854 has been marked as a duplicate of this bug. ***
Created attachment 134028 [details] Document showing problem with arabic characters with diacritics This new attachment shows there is clearly some problem with arabic characters with diacritics under LibreOffice. Opening this document in MS Word 2010 shows that selecting the second line and clicking on the Words button on the Status bar (to show the Word Count dialog) will report 5 characters and selecting line 4 will report 6 characters. Doing the same in LibreOffice (any version) will report "3 characters selected" on both lines. This explains why opening the document attached to Bug#106161 in MS Word returns 332030 characters but opening in LibreOffice only returns 323360 characters.
Another bit of important information: 1) Open the document in attachment 134028 [details] 1) select and copy the word in line 2 2) paste it in the Find field (Ctrl+F) 3) click on the white space to the right of the word in the Find field 4) navigate in the word using the Right cursor key (because this is a Right to Left script language) 5) you need to press the Right key 5 times to get to the end of the word (which ends at left) This proves that the Find field can separate the expected number of characters (5)
So lets limit this bug to the find & replace issue of arabic diacritics and bug 54494 will deal the keyboard navigation between letters issue. steps: 1. open attachment 134028 [details] 2. open find toolbar or find & replace dialog 3. type ُ (dumma) and it will appear as a dotted-lined circle and a dumma 4. find will result in no results though the document has 3 dummas 5. type كُ (kaaf + dumma) and it will find 2 results Version: 6.0.0.0.alpha0+ Build ID: 3672cdd35985201ea87463cf032fedd02c052f4d CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2; Locale: en-US (en_US.UTF-8); Calc: group
Notice that the advanced options of the search & replace dialog have "ignore diacritics" and "ignore kashida" on by default (bug #52204 and bug #77123). Please verify if either of these options helps with this issue.
(In reply to Lior Kaplan from comment #15) > Notice that the advanced options of the search & replace dialog have "ignore > diacritics" and "ignore kashida" on by default (bug #52204 and bug #77123). Disabling these didnt solve the issue.
** 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 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
bug is STILL PRESENT Version: 6.0.7.3 Build ID: 1:6.0.7-0ubuntu0.18.04.10 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: kde4; Locale: en-US (en_US.UTF-8); Calc: group
(In reply to Lior Kaplan from comment #15) > Notice that the advanced options of the search & replace dialog have "ignore > diacritics" and "ignore kashida" on by default (bug #52204 and bug #77123). > > Please verify if either of these options helps with this issue. Hello. i tried unchecking ignoring diacritics in other options of find-replace dialog, and for example: i tried to remove ّ from an html file. the result was not found! however, when i reported this bug, i did not know that ignoring diacritics is intentional! why libreoffice and even microsoft office, ignore diacritics by default? about microsoft office, i only tested with office 2007!
This bug occurs with Hebrew diacritics as well - seemingly, in exactly the same fashion, so I won't attach another example. To reproduce: 1. Create a new document 2. Type in אבא הלך לעבודה 3. Enter a Dagesh character into the first ב. (On Linux: Place the cursor after the ב; Enable Num Lock; Press Right-Alt + ד) 4. Search for ב without a Dagesh 5. Search for just Dagesh, i.e. for ּ 6. Search for ב with a Dagesh, i.e. for בּ You'll get no matches for just Dagesh, and two matches for either ב. This is quite problematic, since ב and בּ are different consonants (V and B in English). Now, it's true that most people don't use diacritics when writing in Hebrew, but some do, e.g. users * with impaired hearing or sight * who are editing text to be read out loud automatically * who are working on poetry or religious texts * who are working on reading material for children I assume it's the same for Arabic.
Version: 7.0.1.2 Build ID: 00(Build:2) CPU threads: 4; OS: Linux 5.6; UI render: default; VCL: kf5 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded This bug is still present. I would like this bug to be fixed too. Thanks for your hard work.
GOOD NEWS EVERYONE I just tested this and I can say that it is FIXED the diacritics can now be found and replaced. Version: 7.1.0.3 / LibreOffice Community Build ID: 10(Build:3) CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: kf5 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
(In reply to Safeer Pasha from comment #22) > GOOD NEWS EVERYONE > I just tested this and I can say that it is FIXED Not quite. The behavior has changed, but it isn't what we would expect. With the same reproduction instructions I gave in my last comment: * Searching for ב without DAGESH finds both ב's. * Searching for ב with DAGESH _also_ finds both ב's. * Searching for just DAGESH doesn't find anything. So, the current behavior is that searching ignores diacritics (at least in Hebrew). Is this intentional? I'm not sure. Is this the best behavior to have? I'd say it isn't, but then - we should really have a "policy discussion" about this. preferably on the LO RTL channel.
(In reply to Eyal Rozenberg from comment #23) it works for Arabic, did not test with Hebrew.
(In reply to Safeer Pasha from comment #24) > (In reply to Eyal Rozenberg from comment #23) > > it works for Arabic, did not test with Hebrew. Could you please explain the steps that are fixed ? I can investigate when it got fixed and maybe it helps with the hebrew problem
(In reply to Xisco Faulí from comment #25) > Could you please explain the steps that are fixed ? I can investigate when > it got fixed and maybe it helps with the hebrew problem Oh, I'm sorry, I misspoke. Current behavior is exactly the same as what I described in my reproduction instructions for Hebrew. There is no change. However, if you make your search diacritics-sensitive, then searching for either BET or BET+DAGESH will find just one occurrence. Now, on to Arabic. First, if I follow Yousef Phillips's instructions - I get the exact same problematic behavior: Finding a DAMMA fails, finding a KAF + DAMMA finds two results. This is true whether your search is marked "diacritics-sensitive" or not (which can only be done with the dialog BTW). If on that same document, you you type a third KAF letter, without a DAMMA - it will be found when searching for KAF + DAMMA in non-diacritic-sensitive mode, and will not be found when searching for KAF + DAMMA, in diacritic-sensitive mode (which is a good thing). So, the behavior for Arabic and Hebrew seems to be exactly the same. Marking my earlier comment obsolete.
(In reply to Xisco Faulí from comment #25) the testing is done on the document that is in the attachments, open the S&R dialog and type "کُ" the letter KAF with DAMMA in the "Search BOX" type KAF with FATHA "کَ" in the "Replace BOX" press "Find" or "Find all" or "Replace" or "Replace All" you can even search & replace for FATHA or DAMMA alone, without it being attached to another letter.
https://newsbinding.com/today-deals/ https://newsbinding.com/news/entertainment/ https://newsbinding.com/news/sports/
Khaled Hosny committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2a78fbf4e4a49f2b52aa1352aac41ee024d0cf72 tdf#91764: Combining marks from “complex” scripts can’t be searched for It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Searching for standalone combining marks works now, as long as “Diacritic sensitive” option is checked.
Khaled Hosny committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/a8ba4ed2966a6f39b9aea6ce9deaed63db2023f2 tdf#91764: Combining marks from “complex” scripts can’t be searched for It will be available in 7.4.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.