Description: I am attaching a document where I repeated three words many times and set the text to be justified. Some of the words got a gap between characters that shouldn't be there. I marked those with the problem with a red color, and one can easily see what's wrong by comparing them to the other non-red words. I am also attaching a PDF that's an export of the document that shows the problem persists in the pdf. Steps to Reproduce: 1. Open my attached file 2. The red words should look similar to the black words Actual Results: gaps are introduced between characters. Expected Results: No gaps should be introduced in justified text. Reproducible: Always User Profile Reset: Yes Additional Info: User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Created attachment 132020 [details] libO introduced gaps in some words
Created attachment 132021 [details] PDF export also has the same issue
Is this another manifestation of needing floating point glyph positioning for enhancement bug 103322?
I can't reproduce it in Version: 5.4.0.0.alpha0+ Build ID: d3b5bd4a07a619db6bee1c39c32280ac3c620532 CPU threads: 4; OS: Linux 4.8; UI render: default; VCL: gtk2; Locale: ca-ES (ca_ES.UTF-8); Calc: group Khaled should be able to comment more on this...
That is a kashida issue, in the gap there should be a kashida but it moves to the wrong direction due to the presence of combining mark on the right of it. I don’t have the same font, but other fonts show the issue as well. I recall fixing this exact issue at some point, but I can reproduce with 5.3, may be it was fixed on 5.4 but I can’t test it right now.
@Khaled: Yes, I noticed the bug with many fonts including Amiri but it happens in a random way that even closing the file and reopening it could make it disappear in one place and appear in another. The current sample shows a more consistent case. Shouldn't there be a way to disable kashida justification and resort to space justification only?
(In reply to Munzir Taha from comment #6) > Shouldn't there be a way to disable kashida justification and resort to > space justification only? Probably yes, but it might require both changes to the UI and the file format, I don’t know for sure.
@Khaled: you mentioned that > the gap there should be a kashida but it moves to the wrong direction > due to the presence of combining mark on the right of it However, I can reproduce it with no marks on the right of it. Attached is an example file and a screenshot
Created attachment 132086 [details] reproduceable without marks
Created attachment 132087 [details] reproduceable without marks (screenshot)
Created attachment 134506 [details] source document
Created attachment 134507 [details] The good The good
Created attachment 134508 [details] The bad The bad
I've just attached another extreme case example, where the kashida messed up the text though I haven't even used justification! Just by changing the zoom from 351% to 352% I got the bad text. Attached is the source document and two screenshots; one shows the good, the other shows the bad.
Created attachment 150525 [details] A repeated text in Farsi with several fonts
Created attachment 150526 [details] The PDF generated by LibreOffice 6.1.5.2 from the previous file Everything is OK in this PDF
Created attachment 150527 [details] The PDF generated by LibreOffice 6.2.2.2 from the previous file Everything is OK with this PDF,too
Created attachment 150528 [details] How LibreOffice 6.2.2.2 actually displays this text- part 1 There are excessive spaces between letters of single words. I have marked this words with red ellipses or boxes. You can see the incorrect processes starts in each line and continues to the end of that line.
Created attachment 150529 [details] How LibreOffice 6.2.2.2 actually displays this text- part 2 The same as part 1
Created attachment 150530 [details] How LibreOffice 6.2.2.2 actually displays this text- part 3 The same as part 1
Created attachment 150531 [details] How LibreOffice 6.2.2.2 actually displays this text- part 4 the same as part 1
Created attachment 150532 [details] How LibreOffice 6.2.2.2 actually displays this text- part 5 Even Dejavu Sans has this problem, but not Liberation Sans.
Created attachment 150533 [details] How LibreOffice 6.2.2.2 actually displays this text- part 6 Also "Lohit Devanagari" seems OK, although it is an Indian font
(In reply to Babak Razmjoo from comment #16) > Created attachment 150526 [details] > The PDF generated by LibreOffice 6.1.5.2 from the previous file > > Everything is OK in this PDF Sorry, everything is not OK here. All fonts till Dejavu Sans can render the text perfectly, but there are Keshide (or Tatvil) marks in wrong places in texts rendered by Liberation sans or Lohit Devanagari
(In reply to Babak Razmjoo from comment #17) > Created attachment 150527 [details] > The PDF generated by LibreOffice 6.2.2.2 from the previous file > > Everything is OK with this PDF,too Sorry, everything is not OK here too. There are some incorrect Keshide or Tatvil marks in texts rendered by Liberation sans and Lohit Devanagari
Created attachment 150535 [details] How LibreOffice 6.2.2.2 actually displays this text- part 1-revised
The 6.2.x issue is different than the original issue here, and is tracked in bug 124109 (which should be fixed in the next point release).
Dear Munzir Taha, 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://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 137530 has been marked as a duplicate of this bug. ***
Created attachment 181637 [details] Gaps inside Arabic/Persian text with diacritics in justified paragraphs This problem happens when you use diacritics. To show the problem better, I attach an example from Ask LibreOffice, in which the problem is more clearly visible: Justified Persian (Farsi) paragraphs! https://ask.libreoffice.org/t/justified-persian-farsi-paragraphs/60605
Created attachment 181638 [details] Gaps inside Arabic/Persian text with diacritics in justified paragraphs This is the PNG version of the above attachment.
This is a regression, bibisected to: commit 8f2dd1df1d6cc94ebbc1149de72bc6d6dffa6533 Author: Khaled Hosny <khaledhosny@eglug.org> Date: Wed Nov 2 23:52:06 2016 +0200 Revert "Revert "Enable the new text layout engine by default"" This reverts commit 3950166877bf1308f9e449992e20b558342af825. This problem first appeared in LibreOffice 5.3, after enabling the new text engine that uses HarfBuzz as the default for rendering text on all platforms.
(In reply to Hossein from comment #30) > Gaps inside Arabic/Persian text with diacritics in justified paragraphs > > This problem happens when you use diacritics I already demonstrated that the problem happens even with no diacritics and no justification. Check comment #8. I will revert the original title since it's more accurate.
(In reply to Hossein from comment #30) > This problem happens when you use diacritics I already demonstrated that the problem happens even with no diacritics and no justification. Check comment #8. I will revert the original title since it's more accurate.
Khaled Hosny committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3d0e482df81a28e6d0eb86cda71ac49d3363ae50 tdf#106653: Try harder not to return 0 for Kashida width 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.
@Khaled: Thanks a lot for fixing my most annoying bug in libO. @Hossein: Thanks too for the bibisecting and pointing it's a regression.
Fix verified in: Version: 7.5.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: da3dd48eaf9086f8ab28d6a6655f9a638e51433a CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded