Description: For whatever reason, furigana text always has way too much whitespace between it and the base characters it's supposed to be attached to. This is especially bad if they're set to appear above (or to the right of in vertical text) the base characters, because somehow they end up closer to the preceding line of text than the one they're on. Steps to Reproduce: 1. Produce some text with furigana on top (Alt,O,I,Enter for furigana menu) 2. Put another line of text above it 3. Remove all extra whitespace between lines (line spacing 1 etc.) Actual Results: Furigana appear closer to the wrong line of text Expected Results: Furigana should hug the text it's modifying, much like font effects in the character properties menu (over/underlines, stress dots, etc.). At the very least there should be an option (in the furigana menu?) to manually adjust furigana elevation. Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:51.0) Gecko/20100101 Firefox/51.0
Can you confirm which version of LO are you using, OS, etcetera? Similar issues have been solved recently in some other bugs ( #55469 , #103730)
Created attachment 132700 [details] Document demonstrating furigana and stress mark position I'm using version 5.3.2.2, Windows 7 64 bit. I recently upgraded from 5.1.2 in an attempt to solve this and it DID get better, but it's still an issue. I'm aware that some fonts include inordinate amounts of whitespace in their specifications, but I know that this is not the issue because stress marks can be rendered correctly where I'd expect the furigana to go. I've generated a document demonstrating this, though the font (KaiTi) was too large to embed. I'll see if I can attach it separately.
Created attachment 132701 [details] PDF of demonstration document Unfortunately the font file alone seems too big to upload as well. Windows 7 users Should get the FangSong and KaiTi fonts with the OS, so hopefully someone can reproduce this. I'm attaching a PDF showing what I see as well. Note the position of the stress marks (suspended to the right of "ミろる") as compared to the furigana (suspended to the right of "こば")
This exceeds my knowledge, I don't know if it is an issue with the font or the rendering. It would be great if Khaled Hosny could take a look at it. Not adding him to the bug CC as I don't know the "netiquette" involved in that.
Created attachment 133092 [details] Guessed examples I suppose this issue is talking about adjustment of the distance between "Ruby text" and "Base text". Attached some example files. See "Bug 107185 JO3EMC 1H".(either PNG or ODT) Ruby text "いろは" binded to Base text "まみむめも". But on the display, "いろは" positioned to almost same distance between "まみむめも" and "かきくけこ" in the above line. It is difficult to recognize which is the Base text of "いろは", from appearance. So, we want to position "いろは" more closer to "まみむめも". It is so desirable that the distance between "Ruby text" and "Base text" is manually user adjustable. Enhancement request, I think. But I'd like to set the status to "New", cause reproduced. Of course, not only horizontal text direction, but also vertical. See "Bug 107185 JO3EMC 1V". We get the same resul..... whoops...base line of the "Base text" was disturbed... This issue shold be another report. ;-) Version: 5.4.0.0.alpha1+ Build ID: 2514e38f8ebb95f51783ce321a84d6c55bba1de4 CPU threads: 4; OS: Windows 6.2; UI render: default; TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2017-05-04_00:30:46 Locale: en-US (ja_JP); Calc: group Version: 5.3.2.2 Build ID: 6cd4f1ef626f15116896b1d8e1398b56da0d0ee1 CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; Layout Engine: new; Locale: en-US (ja_JP); Calc: group
Dear y3kcjd5, 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
Confirmed relevant in version 6.4.1.2 (x64), Build ID 4d224e95b98b138af42a64d84056446d09082932. Upon trying to generate another PDF from the demo document for side-by-side comparison, I discovered that the stress dots are no longer being rendered at all.
Dear y3kcjd5, 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
Created attachment 186654 [details] Ruby (left) vs. frames (right) showing close spacing A screenshot of an experiment showing this issue with Latin text. Ruby text is spaced too far from base text and there can only be one ruby text per word (unlike HTML ruby). Using frames the text can be brought closer and you can put ruby above and below the same text. It is difficult to get frames to behave consistently though — although centred to character they are often not centred, copy & paste shifts all the anchors to the beginning of the line. By contrast ruby text is robustly positioned, but very inflexible.
Created attachment 186678 [details] Ruby close to wrong line The same text without extra spacing after paras shows how the ruby text is closer to the line above than to the line it is glossing.
Created attachment 186679 [details] Ruby distance varies between fonts Previous examples used Gentium Plus; this example contrasts Noto Serif (reasonable postioning) with Junicode (Medievalist font). An uncharitable interpretation is that this is not an LO problem, but it seems many fonts have this problem, so it would be helpful to users if the positioning could be adjusted. Sometimes the choice of font is very restricted. In this case, there are very few fonts that contains all the required characters.
*** Bug 118736 has been marked as a duplicate of this bug. ***
*** Bug 140318 has been marked as a duplicate of this bug. ***
(In reply to y3kcjd5 from comment #0) > [...] At the very > least there should be an option (in the furigana menu?) to manually adjust > furigana elevation. Duplicate bugs tdf#118736 and tdf#140318 suggest the addition of an option to control the spacing as well. Spacing was already problematic in OOo 3.3, so issue is inherited.