Created attachment 55575 [details] A screenshot showing how the Japanese Ruby characters are incorrectly placed too high above the Japanese text. They should appear much closer. Problem description: Japanese fonts have different vertical advances and it appears as if LibreOffice places Japanese Ruby characters above the vertical advance. The problem cannot be solved by changing line spacing size because this cuts off the Ruby characters. Steps to reproduce: 1. Enter several lines of Japanese text. 2. Add ruby characters to the text using Format--> Asian Phonetic Guide 3. Change the font to a Japanese font such as TakaoPMincho 4. Observe that the ruby characters appear as if they are closer to the line above them rather than closer to the characters over which they appear! (This is a big problem!) Current behavior: There is no "offset" box which allows us to specify an offset closer to (or further away from) the current ruby positioning. Expected behavior: An "offset" box should exist either in Asian Phonetic Guide, or preferably in Character Sytles so one can set different offsets for different ruby fonts and point sizes. This control will offset the ruby up (away from) or down (towards) the Japanese text. A great degree of control (up to 72 points, I'd suspect) of freedom is required for Japanese typesetting of any kind. Platform (if different from the browser): Browser: Mozilla/5.0 (Ubuntu; X11; Linux x86_64; rv:9.0.1) Gecko/20100101 Firefox/9.0.1
NOTE: I've been combing through the sources to try and figure out what is causing this problem. In the file: vcl/win/source/gdi/salgdi3.cxx around line 1800... I found out that someone has hardcoded a line size change, adding to the vertical ascent of asian fonts. I can't believe such a solution was ever approved, I am pretty sure this is the source of the problem. This needs to be placed under user control, if this is the source of the problem, it needs to be removed and users should be encouraged to use styles and format their japanese text correctly. (Default Asian/CJK styles can be added) At any rate this needs to be put under user control somehow, this problem is equivalent to having an oversized vertical ascent in the font. Wow, I am so surprised to see this. This easily breaks Japanese ruby. I'm going to try to remove this or modify it and see if it solves the problem, but I need help, I don't know how to modify the UI to allow the user to control this value. I'll post comments here as I discover more.
Ok, after digging through quite a bit I think I found out the best way to fix this problem, or at least looking at how to approach it. Unfortunately my C++ is a little rusty and while I can understand the code if it's right in front of me I estimate it would take me more than a month to understand the code well enough to fix this. I am sorry I just can't spare the time. I would so love to donate money to get this fixed (if that would help). Anyways: In the file portmulti.cxx, around line 705, it became apparent to me that LibreOffice renders ruby (furigana) using two separate lines. This is problematic on many levels, not least of all because it alters the line spacing and prevents ruby from ever touching the Japanese -- even if you alter the line spacing for the second line in portmulti.cxx it looks like you will just cut off the Japanese itself. How to fix this problem: 1. (either) Change the way furigana (ruby) is rendered so it overlays over the line (and add an offset control)... like in LaTeX (CJK overlay) or Microsoft Office (which I believe has had an offset control in Asian Phonetic Guide for at least seven years now, because of this problem!) or 2. For two-line or ruby two-line text allow the Japanese text and ruby text to be drawn on top of each other -- i.e. don't clip the Japanese or the ruby. THAT is a bit of a hack but I imagine no one will ever complain about that since line spacing is under user control. Maybe add a "clip to line size" checkbox to styles, and then allow us to set line size independantly for the japanese and the ruby (and not in total). That would be great but it won't be the same solution as other Word Processors/Typesetters. I really wish I could implement this myself. Thanks for helping if you can do this.
TO FIX this problem by hand, do NOT use the asian phonetic guide tool. Create a table with two rows and format the ruby by hand. Set table to no border and no padding. Set line spacing for asian text to the bare minimum. It's an ugly hack and it breaks the idea of using styles and asian phonetic guide, but as it stands LibreOffice cannot seem to do ruby properly and this is your only way around it. God only knows why it displays properly when using a font that does not support CJK. I have been looking for a week or two now and I just cant find where in the code to fix this.
I think the ruby implementation is just a hack in LibreOffice. It should be rewritten to be able to handle this properly. For example, in Taiwan, we used Zhuyin and it's only written on the right of the characters. It's not even possible to write anything on the right of a character in LibreOffice. Plus, we even put the tone mark in the middle, on the right of the zhuyin… (you can have a look at it there: http://rishida.net/blog/?p=494) I don't have the motivation nor the abilities to hack the code of LibreOffice but I wish someone want to do that.
Thanks for bugreport Please, attach odt document, from which screenshot made (or similar odt). Also, attach document with correct formatting of Ruby, made in MS Office
I can't produce these documents but I am sure the author of this bug will. However, I would like to point to the W3C requirement for Japanese text composition: it is full of precious informations about Japanese composition and also about Ruby characters. Here it is: http://www.w3.org/TR/jlreq/#basics_of_japanese_composition
Hi, I added a comparative result of exchanging document file ruby characters from an external mailing list discussion. Bug 50607 - FILEOPEN, FILESAVE, FOMATTING : Japanese ruby-character handling is broken I wish that posting can act as master bug entry for ruby character handling.
Created attachment 63518 [details] Example of proper rubies from microsoft office 2010 docx file. this file was created in office 2010, and shows how the rubies are properly constructed and displayed.
Created attachment 63521 [details] Ruby problem in LibreOffice Here is the problem shown in a LibreOffice 3.5 ODT file. The problem is that the rubies do not appear directly over the text, and there is no offset control to space them properly. Thank you.
(In reply to comment #5) > Thanks for bugreport > Please, attach odt document, from which screenshot made (or similar odt). > Also, attach document with correct formatting of Ruby, made in MS Office Thank you Sasha. I have made odt and docx files. I must also say that LibreOfice is ahead of Microsoft Office in one important area; LibreOffice lets us style ruby! This is important. Thank you. I think that some people care about this problem so I feel a lot better now. I was using Microsoft Office until now because of this problem and I don't like it.
Created attachment 63546 [details] PDF, produced from docx using msWord 2007 (Russian locale)
Thanks for attachments I see two main problem: 1. no control of distance between regular text and Ruby in Format->Asian phonetic guide 2. docx files opens without Ruby (but doc opens with Ruby) May by somewhere also lost aligning of Ruby (left, centred, ...)
@ Caolan Greetings What do You think about this problem (no control of distance between Ruby and main text)?
Not something I personally intend to do myself. It would be far better if implemented by someone who really knows what's needed, rather that on a purely theoretical basis of how its used which is all I have, so I'd just compound the problems that the original implementation of these wasn't done by a native CJK-using developer :-)
is this a duplicate of Bug 35301?
This is not a duplicate of Bug 35301. Japanese and Chinese can be written in various directions, commonly horizontally left-to-right, but also vertically top-to-bottom with lines of text starting at the right of the page. This bug relates to phonetic guide text for Japanese, which for horizontally written text is positioned above the main text, and for vertically written text is positioned to the right of the main text. This is possible at present. Bug 35301 relates to (Taiwanese style) phonetic guide text for Chinese, which can be placed to the right of each character even for horizontal text. I don't think there's currently even a way of specifying this in OpenDocument. See http://www.omniglot.com/writing/zhuyin.htm for an example of this side-by-side usage in horizontal text.
This is a request for a new feature/improvement -> Severity: enhancement
This seems to be the same problem already fixed in #55469 *** This bug has been marked as a duplicate of bug 55469 ***
Sorry it is not fixed at all. > This seems to be the same problem already fixed in #55469 > *** This bug has been marked as a duplicate of bug 55469 *** Bug 55469 simply lists some problem cases using the MS-WORD as a reference for the behavior. There is NO patch or anything in #55459. So the problem is not fixed. So basically there has not been a progress over the last four years. Tough. TIA
(In reply to ishikawa from comment #19) > Sorry it is not fixed at all. > > > This seems to be the same problem already fixed in #55469 > > > *** This bug has been marked as a duplicate of bug 55469 *** > > Bug 55469 simply lists some problem cases using the MS-WORD as a reference > for the behavior. > > There is NO patch or anything in #55459. > > So the problem is not fixed. > > So basically there has not been a progress over the last four years. Tough. > > TIA Before claiming that the issue is not fixed, have you actually tested with a version that has the fix in bug 55459?
I see three issues lumped together here: 1) Too much space between Ruby characters and the text below them which might be related to how line height was calculated (it would help if the operating system where these bugs are seen was indicated!) 2) Improperly importing Ruby characters from (some?) docx files. 3) Lack of offset control. I suggest reporting 2) and 3) separately, lumping different issues together is a sure recipe for not fixing any of them, and closing this issue id 1) is verified to be fixed.
Created attachment 129408 [details] Screenshot of the ODT document on master/5.3 This is how the ODT document looks on master, it looks fine to my untrained eye.
*** This bug has been marked as a duplicate of bug 55469 ***