Bug 114556 - Emphasis mark set in the Japanese vertical text shifts upward
Summary: Emphasis mark set in the Japanese vertical text shifts upward
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.0.0.0.beta2
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: CJK-Japanese
  Show dependency treegraph
 
Reported: 2017-12-19 12:51 UTC by Jun Nogata
Modified: 2021-09-12 18:37 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot (187.83 KB, image/png)
2017-12-19 12:53 UTC, Jun Nogata
Details
odt file (9.21 KB, application/vnd.oasis.opendocument.text)
2017-12-19 12:54 UTC, Jun Nogata
Details
Not reproducible on windows (75.18 KB, image/png)
2018-06-22 16:14 UTC, Xisco Faulí
Details
How it looks after the commit (73.57 KB, image/png)
2018-06-22 16:21 UTC, Xisco Faulí
Details
How it looks before the commit (74.82 KB, image/png)
2018-06-22 16:21 UTC, Xisco Faulí
Details
Screenshot in 7.1 (24.76 KB, image/png)
2021-04-09 05:09 UTC, Jun Nogata
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jun Nogata 2017-12-19 12:51:45 UTC
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
Comment 1 Jun Nogata 2017-12-19 12:53:31 UTC
Created attachment 138521 [details]
Screenshot
Comment 2 Jun Nogata 2017-12-19 12:54:05 UTC
Created attachment 138522 [details]
odt file
Comment 3 Xisco Faulí 2018-06-12 11:16:26 UTC
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
Comment 4 Khaled Hosny 2018-06-14 04:33:47 UTC
Which version is used for the GOOD screenshot?
Comment 5 Xisco Faulí 2018-06-14 09:31:28 UTC
(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?
Comment 6 Khaled Hosny 2018-06-14 14:32:05 UTC
(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.
Comment 7 Khaled Hosny 2018-06-16 00:55:50 UTC
Also can someone check if this happens on all platforms or on Linux only?
Comment 8 Xisco Faulí 2018-06-22 16:14:03 UTC
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
Comment 9 Xisco Faulí 2018-06-22 16:21:31 UTC
Created attachment 143048 [details]
How it looks after the commit
Comment 10 Xisco Faulí 2018-06-22 16:21:56 UTC
Created attachment 143049 [details]
How it looks before the commit
Comment 11 Jun Nogata 2018-06-30 11:50:49 UTC
(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
Comment 12 Julien Nabet 2019-03-10 13:03:58 UTC
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?
Comment 13 Khaled Hosny 2019-03-10 13:50:23 UTC
(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.
Comment 14 QA Administrators 2021-03-10 04:04:05 UTC Comment hidden (obsolete)
Comment 15 Jun Nogata 2021-04-09 05:08:36 UTC
(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
Comment 16 Jun Nogata 2021-04-09 05:09:50 UTC
Created attachment 171048 [details]
Screenshot in 7.1

The condition remains the same.
Comment 17 Shinji Enoki 2021-09-12 18:36:06 UTC
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