Description: Emphasis mark set in the Japanese vertical text shifts upward by one character. Steps to Reproduce: Option -> Default Language Setting Asian: Japanese 1. Set the page setting to "Right-to-left(vertical)". 1. Select menubar [Format] -> [Page...] 2. [Page]Tab -> [Text direction] Select [Right-to-left(vertical)] 2. Enter Japanese text. 3. Set emphasis mark. 1. Select text. 2. Select [Character...] in context menu. 3. [Font Effects]Tab -> Set Emphasis mark [Accent] Actual Results: Emphasis mark set in the Japanese vertical text shifts upward by one character. Expected Results: Emphasis mark on the character in the Japanese vertical text. Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
Created attachment 138521 [details] Screenshot
Created attachment 138522 [details] odt file
Regression introduced by: author Khaled Hosny <khaledhosny@eglug.org> 2016-12-08 03:01:14 +0200 committer Khaled Hosny <khaledhosny@eglug.org> 2016-12-10 01:57:50 +0000 commit bebee55d197176f009668628de0d9945c26af8ad (patch) tree e5e476f55f5e13e93540c475e2b34ff9a837384c parent b894104a0b02a9b074c76feb925389d7bee6a493 (diff) Use GlyphItem in more places Bisected with: bibisect-linux-64-5.4 Adding Cc: to Khaled Hosny
Which version is used for the GOOD screenshot?
(In reply to Khaled Hosny from comment #4) > Which version is used for the GOOD screenshot? @nogajun@gmail.com, could you please paste the info from Help - About LibreOffice for both screenshots? @Khaled, out of curiosity, does it really matter?
(In reply to Xisco Faulí from comment #5) > @Khaled, out of curiosity, does it really matter? I have hard time seeing how the bisected commit would have made any difference here.
Also can someone check if this happens on all platforms or on Linux only?
Created attachment 143046 [details] Not reproducible on windows indeed, it seems to be linux only. I can't reproduce it on win 6.0.4.2 or 6.1.0.0.beta2
Created attachment 143048 [details] How it looks after the commit
Created attachment 143049 [details] How it looks before the commit
(In reply to Xisco Faulí from comment #5) > (In reply to Khaled Hosny from comment #4) > > Which version is used for the GOOD screenshot? > > @nogajun@gmail.com, could you please paste the info from Help - About > LibreOffice for both screenshots? > > @Khaled, out of curiosity, does it really matter? It does not exist. GOOD screenshot is editing image. It is an ideal display of emphasis mark. https://www.w3.org/TR/jlreq/#composition_of_emphasis_dots
On pc Debian x86-64 with master sources updated today, I could reproduce this with gtk3, gtk, kde5 (with and without wayland enabled), gen. Khaled: Just for curiosity, considering https://cgit.freedesktop.org/libreoffice/core/commit/?id=bebee55d197176f009668628de0d9945c26af8ad, does it mean it may help that all places containing sal_GlyphId are converted? If yes, would it be an easyhack?
(In reply to Julien Nabet from comment #12) > On pc Debian x86-64 with master sources updated today, I could reproduce > this with gtk3, gtk, kde5 (with and without wayland enabled), gen. > > Khaled: Just for curiosity, considering > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=bebee55d197176f009668628de0d9945c26af8ad, does it mean it may help that > all places containing sal_GlyphId are converted? > If yes, would it be an easyhack? I don’t know, I don’t really know what the issue is. That commit was not supposed to cause any functional change, so someone needs to debug this and find what changed. I don’t have a LibreOffice dev setup on Linux to check this.
Dear nogajun, 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
(In reply to QA Administrators from comment #14) It reproduced in 7.1. The bug has not been fixed. Screenshot is attached. Version: 7.1.2.2 / LibreOffice Community Build ID: 8a45595d069ef5570103caea1b71cc9d82b2aae4 CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: ja-JP (ja_JP.UTF-8); UI: ja-JP Calc: threaded
Created attachment 171048 [details] Screenshot in 7.1 The condition remains the same.
Reproduced in the following environment. It seems that there are fewer position shifts than up to 7.1. Version: 7.2.0.4 / LibreOffice Community Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: ja-JP (ja_JP.UTF-8); UI: ja-JP Calc: threaded Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: 84e1c79dd7394168459a3bbdea8bd94d765708e0 CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: ja-JP (ja_JP.UTF-8); UI: ja-JP TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-09-10_21:28:22 Calc: threaded
Mark Hung committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9e6ff03454c2c554fc81b5f5d453a02edd5245d1 tdf#114556 fix vertical writing emphasis mark position. It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://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-7-5": https://git.libreoffice.org/core/commit/6de58389343d40ea9e638423967b9a845c7ef0d9 tdf#114556 fix vertical writing emphasis mark position. It will be available in 7.5.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.