Bug 130029 - FILEOPEN DOCX: Bad vertical text render
Summary: FILEOPEN DOCX: Bad vertical text render
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.3.3.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: DOCX-Tables Skia
  Show dependency treegraph
 
Reported: 2020-01-16 08:39 UTC by starkindustries2012
Modified: 2021-09-12 09:07 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample file for bug reproducing (13.28 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-01-16 08:53 UTC, starkindustries2012
Details
Screenshot of the original document side by side in Writer master (110.18 KB, image/png)
2020-04-08 14:20 UTC, NISZ LibreOffice Team
Details
Extended test file from Word 2013 (11.82 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-04-23 15:46 UTC, NISZ LibreOffice Team
Details
Extended test file in todays master with GL rendering (135.26 KB, image/png)
2020-04-23 15:46 UTC, NISZ LibreOffice Team
Details
Extended test file in todays master with SKIA rendering (136.71 KB, image/png)
2020-04-23 15:47 UTC, NISZ LibreOffice Team
Details

Note You need to log in before you can comment on or make changes to this bug.
Description starkindustries2012 2020-01-16 08:39:46 UTC
Description:
Text with vertical direction inside table cell isn't displayed correctly

Steps to Reproduce:
1. Create any table
2. Write any text inside any cell
3. Change text direction

Actual Results:
The resulted text crashes and looks awful (not all letters are displayed, some of them are rotated strangely)

Expected Results:
Text should be displayed normally without any artefacts


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 6.3.3.2 (x86)
Build ID: a64200df03143b798afd1ec74a12ab50359878ed
CPU threads: 8; OS: Windows 6.3; UI render: GL; VCL: win; 
Locale: ru-RU (ru_RU); UI-Language: ru-RU
Calc: CL
Comment 1 starkindustries2012 2020-01-16 08:53:58 UTC
Created attachment 157177 [details]
Sample file for bug reproducing

This file was created with MS Word 2010, but bug also exists in the same file created with MS Word 2016
Comment 2 Dieter 2020-01-16 09:07:36 UTC
I confirm it with

Version: 6.5.0.0.alpha0+ (x64)
Build ID: 350d25da375f221edfa37309324ce3c68cf297ef
CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: default; VCL: win; 
Locale: de-DE (de_DE); UI-Language: en-GB
Calc: threaded

Is No a kind of special character? How did you insert it in MS word? (I'm not so familiar with Word)
Comment 3 starkindustries2012 2020-01-16 09:17:46 UTC
(In reply to Dieter Praas from comment #2)
> I confirm it with
> 
> Version: 6.5.0.0.alpha0+ (x64)
> Build ID: 350d25da375f221edfa37309324ce3c68cf297ef
> CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: default; VCL: win; 
> Locale: de-DE (de_DE); UI-Language: en-GB
> Calc: threaded
> 
> Is No a kind of special character? How did you insert it in MS word? (I'm
> not so familiar with Word)

There are no any special characters: I just created this table (cells "№ Sample" (combined), "1" and "2") and then changed text direction inside the first cell.
Comment 4 Dieter 2020-01-16 09:23:10 UTC
(In reply to starkindustries2012 from comment #3)
> There are no any special characters: I just created this table (cells "№
> Sample" (combined), "1" and "2") and then changed text direction inside the
> first cell.

Yes, but № is different from No. If just just type No the bug doesn't occur.
Comment 5 starkindustries2012 2020-01-16 09:27:20 UTC
(In reply to Dieter Praas from comment #4)
> (In reply to starkindustries2012 from comment #3)
> > There are no any special characters: I just created this table (cells "№
> > Sample" (combined), "1" and "2") and then changed text direction inside the
> > first cell.
> 
> Yes, but № is different from No. If just just type No the bug doesn't occur.

Okay, got it, thanks! But I'm still getting "No Sampl" instead of "No Sample". Do you have it also?
Comment 6 Dieter 2020-01-16 09:36:54 UTC
(In reply to starkindustries2012 from comment #5)
> Okay, got it, thanks! But I'm still getting "No Sampl" instead of "No
> Sample". Do you have it also?

No, I don't have that problem.
Comment 7 Mike Kaganski 2020-01-16 09:52:39 UTC
(In reply to Dieter Praas from comment #2)
> Is No a kind of special character? How did you insert it in MS word? (I'm
> not so familiar with Word)

It's on sandard key "3" near "#" on Russian keyboard layout.
Comment 8 starkindustries2012 2020-01-16 10:02:13 UTC
(In reply to Dieter Praas from comment #6)
> (In reply to starkindustries2012 from comment #5)
> > Okay, got it, thanks! But I'm still getting "No Sampl" instead of "No
> > Sample". Do you have it also?
> 
> No, I don't have that problem.

Yeah, tested this on Windows 10 using same version of LibreOffice (6.3.3.2) and found that text is not cut anymore.
Comment 9 Mike Kaganski 2020-01-16 10:04:25 UTC
It's a btLr problem; Miklos: you could like to look at it possibly?
Comment 10 NISZ LibreOffice Team 2020-01-27 10:30:52 UTC
The last letter of rotated text missing problem is filed as bug #126405 - it's GL specific.

The "№" not being rotated is a different, unique problem.
Comment 11 Dieter 2020-01-27 10:47:35 UTC
(In reply to NISZ LibreOffice Team from comment #10)
> The "№" not being rotated is a different, unique problem.

So should this bug report be reduced to that problem?
Comment 12 NISZ LibreOffice Team 2020-04-08 14:20:27 UTC
Created attachment 159427 [details]
Screenshot of the original document side by side in Writer master

Looks good now in todays nightly: 

Version: 7.0.0.0.alpha0+ (x86)
Build ID: b1da67699bd05b26ee11460347ca7077d366c2fc
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win; 
Locale: hu-HU (hu_HU); UI-Language: en-US
Calc: CL

But still bad in yesterdays:

Version: 7.0.0.0.alpha0+ (x86)
Build ID: 95ec2e9b024ff12a3005777c902d7e0975460b1d
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win; 
Locale: hu-HU (hu_HU); UI-Language: en-US
Calc: CL

(was less terrible with OpenGL, though)

Perhaps the fix to bug #131490 helped this too, but I can't bibisect it right now.
Comment 13 NISZ LibreOffice Team 2020-04-23 15:46:16 UTC
Created attachment 159863 [details]
Extended test file from Word 2013

The test file was extended to contain the same table with text rotated TBLR. 
With current master the BTLR case is fixed, but the TBLR still not, since: 

https://git.libreoffice.org/core/+/a8d26a0bb40c101394ded8061d1b58048153631b

author
Miklos Vajna <vmiklos@collabora.com> Mon Apr 06 21:02:30 2020 +0200 
committer
Miklos Vajna <vmiklos@collabora.com> Tue Apr 07 09:04:09 2020 +0200 

tdf#131490 sw btlr: fix handling of vertical text
Comment 14 NISZ LibreOffice Team 2020-04-23 15:46:51 UTC Comment hidden (obsolete)
Comment 15 NISZ LibreOffice Team 2020-04-23 15:47:19 UTC
Created attachment 159865 [details]
Extended test file in todays master with SKIA rendering
Comment 16 Luboš Luňák 2021-08-30 10:16:59 UTC
This works for me now, presumably fixed by the vertical text fixes a couple of months back.
Comment 17 Dieter 2021-09-12 09:07:30 UTC
Yes, WORKSFORME with

Version: 7.2.1.2 (x64) / LibreOffice Community
Build ID: 87b77fad49947c1441b67c559c339af8f3517e22
CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: threaded

(Changed to SESOLVED WORKSFORME, because it's not sure for 100% how it has been fixed.)