Created attachment 102517 [details] Attached is a sample document containing the bug. The same sample has been used for bug 80788 to demonstrate slowness in typing. When typing in Chinese, we normally use full-width punctuation which do not follow with a space before the next character. Writer curiously renders most of these correctly, but some tend to align more to the right, making the document look ugly. I have tried changing the font, which does alter certain punctuation positions, but did not help solve the problem. I believe this to be a bug specific to LibreOffice because the same situation doesn't happen in Word. In the sample document below, problematic punctuation positioning are highlighted and given in red (not exhaustive). Compare with the normal ones to get a gist of how the bug is affecting full-width punctuation display.
Confirmed. This bug exist for a long time, every Chinese user can observe this.
Is there a plan to debug it? This bug makes working in Chinese frustrating.
(In reply to comment #2) > Is there a plan to debug it? This bug makes working in Chinese frustrating. Could you find a way (step by step) to reproduce this issue?
No. The bug seems to occur randomly. What I did when I got hit by the bug, though, was to open a .doc file which was created on Word 2003 in Writer. Converting the .doc file to a .odt format did not help.
One part of what is wrong with this file appears to be the issue in bug 82018 - specifically the "CharacterCompressionType" property being set to "1" within settings.xml inside the document. This causes some of the characters in the document to be rendered on top of one another. However, when this is eliminated, there are still visible issues with the highlighted "。", so there's clearly a separate problem with punctuation here. I will attach a series of files after this comment which illustrate the issue more minimally. (1) An image showing buggy rendering of one paragraph in the original document. Note the overlapping characters at the end of the second line after the "。" (2) An ODT of the same paragraph after the "CharacterCompressionType" issue is removed (3) An image of the above (2). Note the misplaced "。" (4) A stripped and minimised version of the above ODT (5) An image of the above (4). Note that the last two characters overlap (images rendered on OSX/LO 4.3.0.4) Given that in the last version of the document, there is no page, paragraph or character formatting at all apart from the fact that a non-existent font has been set, perhaps this remaining issue is with the font fallback mechanism? Setting the font of the text to one that exists appears to eliminate the rendering problem.
Created attachment 104084 [details] Before.png (1) An image showing buggy rendering of one paragraph in the original document. Note the overlapping characters at the end of the second line after the "。"
Created attachment 104085 [details] RenderingBug.odt (2) An ODT of the same paragraph after the "CharacterCompressionType" issue is removed
Created attachment 104086 [details] RenderingBug.png (3) An image of the above (2). Note the misplaced "。"
Created attachment 104087 [details] RenderingBugMinimised.odt (4) A stripped and minimised version of the above ODT
Created attachment 104088 [details] RenderingBugMinimised.png (5) An image of the above (4). Note that the last two characters overlap
Created attachment 104727 [details] Images showing rendering in 4.4 master and MS Word (2011, Mac) A couple of unrelated bugs have been fixed in 4.4 master, so the originally reported bug can now be seen more clearly. Please disregard the test documents and images I previously attached. A workaround for the reported problem is to set "Options – Language Settings – Asian Layout – Character Spacing" to "No compression". The images in the attached zip show some of the originally attached text rendered with and without character compression in 4.4 master in various fonts, and in MS Word (2011, Mac). As I see it, the images show three issues remaining: 1) Only when "Character Spacing" is set to something other than "No compression", the compressed punctuation is not always properly aligned within its space allocation. This occurs in some fonts but not others 2) The compression applied seems much stronger than in MS Word. For instance, in the attached sample images, punctuation in Word is compressed from 26 screen pixels variously down to a minimum of 22 (~85% size), whereas in Writer the same punctuation is compressed from 30 pixels down to as few as 15 (50% size). Although I'm not an expert in Asian typography, this seems like too much. 3) A consistent fallback font isn't being selected for the missing font in the original document. The characters have a higgledy-piggledy look as though selected from several different fonts.
Created attachment 119833 [details] Punctuation that crowded together. Space at the right side of ideographic comma (、, unicode 3001) and ideographic fullstop (。,unicode 3002) are removed when compressed. The width of removed space is fix proportion of the font height. In the extreme case, they crowded with the following characters ( see uploaded example. ) I guess the algorithm was originally designed for Japanese. Ideographic fullstops in most Chinese fonts are centered. Removing space from one side make it visually unbalaced. But how about Japanese font?
Created attachment 119911 [details] Comparison of font design, showing difference between Japanese and Chinese font for ideographic comma and fullstop Comparison explains why punctuation compression perform badly for some font but not the others. Ideographic comma and period in Japanese font are aligned closer to the left. Removing the space at the right just make the next character closer. For those in Chinese font, removing the space at the right make remaining space unbalanced, sometimes crowd the symbol with next character.
Mark Hung committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=281be263619a8e513a26e6a9165d1d77cf6524ea tdf#81144 Chinese full-width punctuation does not align properly It will be available in 5.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mark Hung committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f5ed3a29e995152b80bf1adc888094d735a0882c&h=libreoffice-5-0 tdf#81144 Chinese full-width punctuation does not align properly It will be available in 5.0.4. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Hello, Is this bug fixed? If so, could you please close it as RESOLVED FIXED?