There is a problem when you write in slide with mixed characters (RTL+LTR) with underlined fonts. I think the reason is height of font and also because of (especially in impress) the text node. as I thought, every group of characters of same language was taken as text node so it has own underline. so, when you write mixed characters that means every group of characters from one language will represent text node with its underline. all that with a reason of different hieght. I hope I am right with this thought.
Created attachment 84648 [details] screenshot
Created attachment 84649 [details] TestDocument
Created attachment 91081 [details] ODPs and screenshots showing underlining of various characters/fonts under v3304 and v4132. I am not sure this is a bug or if it can be fixed in LO as it would appear to be a font metric related issue. The provided example had the Arabic text set in DejaVu Sans and the English text set in Abyssinica SIL. I don't have the second font installed so the underline displayed identically for both pieces of text (refer screenshot). I have created two additional examples under Ubuntu 10.04 x86_64 using: - v3.3.0.4 OOO330m19 Build: 6 - v4.1.3.2 Build ID: 70feb7d99726f064edab4605a8ab840c50ec57a ... each with Latin, Cyrillic, Greek, Hindi, Chinese, Japanese, Hebrew, and Arabic characters. The v3.3.0.4 example uses these fonts: - Arial for Latin, Cyrillic, and Greek. - Lohit Hindi for Hindi, Hebrew, and Arabic. - SimSun for Chinese and Japanese. The v4.1.3.2 example uses the same fonts except: - Linux Libertine G for Latin, Cyrillic, and Greek. A screenshot of what I see here in each case is included. In both examples the same fonts render the underline uniformly, irrespective of characters.
Component set to Presentation. As per comment #3 Version set to Inherited From OOo.
Adding Khaled Hosny to CC list, to hopefully provide some insight into whether this is an issue LO can fix or not (and get this bug confirmed if it is possible to fix).
Currently the position and thickness of underline, overlines etc. is font dependant as LibreOffice computes it from font metrics (though fonts can specify some of those values, we don’t use it, but this is a different issue). So when different fonts are used, you can end up with different line position and thickness. I’m not sure how this can be fixed since there is probably some good reasons to make this font dependant, but I guess one way is to make this configurable so the user can override it, like we do with superscript size and position, for example.
*** Bug 95713 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.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
*** Bug 105087 has been marked as a duplicate of this bug. ***
*** Bug 102262 has been marked as a duplicate of this bug. ***
*** Bug 103508 has been marked as a duplicate of this bug. ***
*** Bug 116627 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 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
Remains an issue. Different underline placement, intra paragraph, follows font and language used--should be calculated to common baseline per paragraph, or possibly make use of the underline font metric, when specified, in individual fonts.
Dear Abdulaziz Ayed, 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
So, there are several potential problems with the underlining of adjacent characters: 1. Inconsistency of stroke width 2. Inconsistency of vertical positioning of the underline 3. Horizontal discontinuity Problems (1.) and (2.) do indeed still happen, and as Khaled explained that is as was intended in the implementation; problem (3.) is a bit more elusive, but I do believe I'm seeing it with one of the documents in the zip file. Please help me confirm that aspect. Now, about Khaled's comment: (In reply to خالد حسني from comment #6) > I’m not sure how this can be fixed since there is probably some good reasons > to make this font dependant Yes, but font-dependent does not have to mean ignorant of other text on the same line / same stretch of underlined text. For example, we can take the maximum width, the minimum width, or the average; and height-wise, it would probably make sense to choose the lowest vertical position and use that consistently. This should emulate what how real person would draw an underline (or overline etc.) when faced with text in different fonts. They would definitely not draw multiple disjoint line segments. Then you may not even need configuration for this. (But I won't say no to configurability of underlining.) That being said - one can argue that text in different fonts should perhaps not be underlined at all, since when handwriting, you don't switch fonts in the middle of a line.
Oh, and - we should not forget that an inappropriate choice of underline v-position and width can intersect the diacritics, which in some languages and with some fonts can make them unintelligible or simply hide them from view. And that is also a problem.
Created attachment 189828 [details] Screenshot Screenshot redone with "Noto Sans Arabic" and "Source Code Pro", two fonts on my system. I don't see how we can find a position below the font baseline, smaller than the descender height, not overwriting some important decoration.
In Writer, the text is drawn as expected for normal paragraphs but not using a text box. Changing the Text-to-text alignment has no effect in the text box and is always reset to Automatic. Seems as if this attribute is not implemented. I suggest to change the summary.
*** Bug 118035 has been marked as a duplicate of this bug. ***
(In reply to Heiko Tietze from comment #19) > In Writer, the text is drawn as expected for normal paragraphs but not using > a text box. Changing the Text-to-text alignment has no effect in the text > box and is always reset to Automatic. Seems as if this attribute is not > implemented. > > I suggest to change the summary. This suggests that Writer does something that Edit Engine (used in other modules as well as Writer’s text boxes) doesn’t, so the next challenge is to find what Writer does exactly and implement it in Edit Engine.