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 nogajun
Modified: 2019-03-10 13:50 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, nogajun
Details
odt file (9.21 KB, application/vnd.oasis.opendocument.text)
2017-12-19 12:54 UTC, nogajun
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

Note You need to log in before you can comment on or make changes to this bug.
Description nogajun 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 nogajun 2017-12-19 12:53:31 UTC
Created attachment 138521 [details]
Screenshot
Comment 2 nogajun 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 (inactive) 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 (inactive) 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 (inactive) 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 nogajun 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 (inactive) 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.