Created attachment 108378 [details] Comparison between LibreOffice rendering and PDF. It is just as the summary. I am using Amiri font for writing RTL text.
please upload the original .odt file as well, not only screenshots.
Created attachment 108379 [details] Original files Here are the original files. BTW, I noticed also some glitches when navigating letters. For example, I can't navigate to the start of the second line, and would need to advance to three of four letters in case I want to delete the first letter in the second line. I think this is logical vs visual issue.
Created attachment 108382 [details] PDF output in 4.3.2.2 try upgrading to LibO 4.3.2.2 and export your .doc file to PDF compare with my attached PDF it seems much better than your PDF output in 4.2.6.3. do you agree or do you still see PDF export issues?
I downloaded the latest 4.3 and no longer facing the issue of navigating letters I mentioned in my second comment. However, the view is still the same. In the PDF I attached you can see the diacritics of the first line (below إ letters), however they are not visible when working on LibreOffice.
I found this question on Superuser.com, and it seems similar to my case. https://superuser.com/questions/776047/arabic-in-libreoffice-composite-character-chopped-off-at-the-top
Ok, I set status to NEW because of that website confirmation
** 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.4 or later) 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 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: 2015-12-20
Created attachment 121537 [details] Word 2013 Output It looks like either an issue with the font, or that the font is supporting advanced OpenType features that is not widely used (I have heard once about its use of various use of OpenType.) The issue manifests also with Word 2013. The issue as my obeservation is that when I fix the height of the line and they ended overlapping when they span multiple lines, the "overflow" content (especially when using diacritics) of each line is cut short. However, when it is printed, PDF seems to let them overlap without interference.
** 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.1.6 or 5.2.3 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-20170103
So this happens in Amiri (v0.107-1 on my ubuntu 16.04-based system and v0.109 from github), but doesnt in any arabic font that comes by default on Windows, so i presume its a problem with the font. I field a separate bug for the issue mentioned in comment 5 in bug 113102. Khaled: What is your take on this, as you are the font creator?
That is another clipping issue, we are clipping the text to the line height not to the bounding box as we should. This is triggered with Amiri since its vowel marks are generally high than simpler fonts, but the PDF renders fine since it does not suffer from the same clipping limitations that LibreOffice own rendering has.
MS Office has the same clipping issues as LibreOffice. Compare with web browsers (e.g. Firefox or Chrome) that have no issue: data:text/html;charset=utf8,<p style="font: 20pt/170% Amiri; width: 800px; direction:rtl;word-break: break-all;">إإٍإٍإٍإٍإٍإٍإٍإٍإٍإٍإٍإٍإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإإأأأأأًأًأًأًأًأًأًأًأًأًأًأأأأأأأأأأأأأأأأأأأأأأأأأأأأأأأأأأأأأأأ.</p>
Created attachment 136962 [details] Same text and font in Google Chrome
** 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
Dear Ghasan, 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 150439 has been marked as a duplicate of this bug. ***
*** Bug 113102 has been marked as a duplicate of this bug. ***
I think this is a clipping issue. Ideally applications should be using the clipping font metrics to determine the height and depth of the clipping region (AKA OS/2 usWinAscent/usWinDescent https://docs.microsoft.com/en-us/typography/opentype/spec/os2#uswinascent), but it seems that LO is (sometimes?) using line spacing instead.
Repro, the display of the pdf and the odt files in LibreOffice is not correct compared to what is expected: Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: bfbae5ddd52cf80af94b250b9de349f0340dbe34 CPU threads: 8; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: fr-FR Calc: threaded
Here I saw a comment oppugn the method to handle line height on MS Windows. https://github.com/ButTaiwan/genyog-font/issues/13#issuecomment-2251756173 This is his comment and my translation: 思源有收三倍長 em-dash，因為還有收直排版本。所以 ascent + descent 高達 3000。 Source Han Sans have three-em-dash, because it is also includes vertical version, so ascent + descent is up to 3000. 就算是源樣拿掉三倍長版本，但因為留下兩倍長的，理論上仍然還有 2000。 Even if GenYo Gothic removed three-em-dash, but due to two-em-dash is preserved, ideally it's still 2000. 另外如樓上所說，日文有 https://zi-hi.com/sp/uni/3031 這個符號，它的高度也是 2000。 In addition, as above comment, Japanese has the symbol 〱 (U+3031), it's height is also 2000. 當然因為直排字符去影響正常的橫排高度不太合理，所以源樣採用竄改 win descent 跟 FontBBox 的作法。 Certainly because it doesn't make sense to make vertical glyphs affect horizontal line height, so GenYo Gothic uses modifying win descent and FontBBox. 基本上這就是字型的技術債。 It's basically technical debt of the font. ascent / descent 本來應該只是 typography 上的抽象高度，用來描述理想的行高、x-height等相對位置。 Ascent/descent should be only abstract heights among typography that used to describe ideally relative position for line height or x-height. 就像 macOS 內建的 Zapfino 字型，ascent / descent 都侵略性地直接重疊到上下行，但這正式傳統歐文書法的風格。 Such as macOS built-in font Zapfino, both ascent/descent are just aggressively overlap neighboring lines, but this is traditional European caligraphy style. 然而 Windows 舊的渲染引擎卻拿 win descent 值當作渲染時的裁切邊界。完全不容許兩行發生重疊（甚至中間還被強制留一些行間）。 However Windows legacy rendering engine used win descent value as clipping boundry for rendering. Completely oppose two neighboring lines overlap each other (even forced leaves line gaps in the middle). So I think this should be fixed via integrating an independent library that makes LibreOffice jump out of system calls for glyph rendering.
BTW, this is still reproduced with Version: 24.8.0.3 (X86_64) / LibreOffice Community Build ID: 0bdf1299c94fe897b119f97f3c613e9dca6be583 CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: zh-CN (zh_CN); UI: zh-CN Calc: threaded
I saw this is still reproduced with Version: 24.8.0.3 (X86_64) / LibreOffice Community Build ID: 0bdf1299c94fe897b119f97f3c613e9dca6be583 CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: zh-CN (zh_CN); UI: zh-CN Calc: threaded -------------------------------------------------------------------------- Here I saw a comment oppugn the method to handle line height on MS Windows. https://github.com/ButTaiwan/genyog-font/issues/13#issuecomment-2251756173 This is his comment and my translation: 思源有收三倍長 em-dash，因為還有收直排版本。所以 ascent + descent 高達 3000。 Source Han Sans have three-em-dash, because it is also includes vertical version, so ascent + descent is up to 3000. 就算是源樣拿掉三倍長版本，但因為留下兩倍長的，理論上仍然還有 2000。 Even if GenYo Gothic removed three-em-dash, but due to two-em-dash is preserved, ideally it's still 2000. 另外如樓上所說，日文有 https://zi-hi.com/sp/uni/3031 這個符號，它的高度也是 2000。 In addition, as above comment, Japanese has the symbol 〱 (U+3031), it's height is also 2000. 當然因為直排字符去影響正常的橫排高度不太合理，所以源樣採用竄改 win descent 跟 FontBBox 的作法。 Certainly because it doesn't make sense to make vertical glyphs affect horizontal line height, so GenYo Gothic uses modifying win descent and FontBBox. 基本上這就是字型的技術債。 It's basically technical debt of the font. ascent / descent 本來應該只是 typography 上的抽象高度，用來描述理想的行高、x-height等相對位置。 Ascent/descent should be only abstract heights among typography that used to describe ideally relative position for line height, x-height, etc. 就像 macOS 內建的 Zapfino 字型，ascent / descent 都侵略性地直接重疊到上下行，但這正式傳統歐文書法的風格。 Such as macOS built-in font Zapfino, both ascent/descent are just aggressively overlap neighboring lines, but this is traditional European caligraphy style. 然而 Windows 舊的渲染引擎卻拿 win descent 值當作渲染時的裁切邊界。完全不容許兩行發生重疊（甚至中間還被強制留一些行間）。 However Windows legacy rendering engine used win descent value as clipping boundry for rendering. Completely oppose two neighboring lines overlap each other (even forced leaves line gaps in the middle). So I think this should be fixed via integrating an independent library that makes LibreOffice jump out of system calls for glyph rendering.