Bug 115582 - VIEWING: Rotated Text in a Cell gets invisible (steps in comment 6 )
Summary: VIEWING: Rotated Text in a Cell gets invisible (steps in comment 6 )
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.0.0.0.alpha0+
Hardware: All All
: high major
Assignee: Armin Le Grand
URL:
Whiteboard: target:6.1.0 target:6.0.5
Keywords: bibisected, bisected, regression
: 116831 (view as bug list)
Depends on:
Blocks: Vertical-Text Regressions-borderline
  Show dependency treegraph
 
Reported: 2018-02-09 13:53 UTC by Hans-Martin Brückmann
Modified: 2018-05-29 08:24 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
Example for Issue Rotatet Text gets invisble (10.48 KB, application/vnd.oasis.opendocument.spreadsheet)
2018-02-09 13:56 UTC, Hans-Martin Brückmann
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Hans-Martin Brückmann 2018-02-09 13:53:59 UTC
Description:
Rotated Text in Cell not shown (invisible) if angel is not 0,90,180,270 deg.
Example 98 deg. 
I have isolates the content.xml with one text in A1 where it is ok, and an other Cell where it is not ok. Looks like a incompatibility between 5.x and 6.x LO.

Steps to Reproduce:
1. WITH LO 5.3.5.2 Place some random Text. Do not take A1 take a place like B3.
2. rotate it by e.g. 82 deg.
3. looks fine, even if scrolling... Save it please.
4. Open the File wit an LO 6.0.X.X. The cell wil be shown a very short time an then stay invisible, if you rotatet it to 90 deg. it is fine.
5. Take already rotated cell from an ods-file which is build by a LO 5.2.x.x version by Copy & Paste then you get this issue too.


Actual Results:  
invisible Text


Expected Results:
visible, rotatet text in cell 


Reproducible: Sometimes


User Profile Reset: No



Additional Info:
Sometimes srcolling out of screen and back or resizing the cell shows text for less a second. Look like a kind of repainting error.
Testet on Win 10 and Win 7 
Test on LO 6.0.0.3 and 6.0.1.1 failed
Test on LO 5.3.5.2 is ok
Here is a part of the content.xml where i presume the issue (locate for rotation in this snippet) :
<style:style style:name="ce2" style:family="table-cell" style:parent-style-name="Default">
            <style:table-cell-properties style:rotation-angle="79"/>
        </style:style>
        <style:style style:name="ce1" style:family="table-cell" style:parent-style-name="Überschrift_20_1" style:data-style-name="N0">
            <style:table-cell-properties style:glyph-orientation-vertical="0" style:cell-protect="protected" style:print-content="true" style:text-align-source="fix" style:repeat-content="false" fo:background-color="transparent" fo:wrap-option="wrap" fo:border="none" style:direction="ltr" style:rotation-angle="82" style:rotation-align="none" style:shrink-to-fit="false" style:vertical-align="middle" loext:vertical-justify="auto"/>
            <style:paragraph-properties fo:text-align="center" css3t:text-justify="auto" fo:margin-left="0mm" style:writing-mode="page"/>
            <style:text-properties style:use-window-font-color="true" style:text-outline="false" style:text-line-through-style="none" style:text-line-through-type="none" style:font-name="Arial" fo:font-size="10pt" fo:font-style="normal" fo:text-shadow="none" style:text-underline-style="none" fo:font-weight="bold" style:font-size-asian="10pt" style:font-style-asian="normal" style:font-weight-asian="bold" style:font-size-complex="10pt" style:font-style-complex="normal" style:font-weight-complex="bold"/>
        </style:style>
    </office:automatic-styles>

OpenGL does not matter.


User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0
Comment 1 Hans-Martin Brückmann 2018-02-09 13:56:29 UTC
Created attachment 139731 [details]
Example for Issue Rotatet Text gets invisble
Comment 2 raal 2018-02-09 15:46:03 UTC Comment hidden (obsolete)
Comment 3 Hans-Martin Brückmann 2018-02-09 17:26:58 UTC
? Don´t understand this sha hex... ?
Comment 4 raal 2018-02-09 18:32:12 UTC
(In reply to Hans-Martin Brückmann from comment #3)
> ? Don´t understand this sha hex... ?

Hello,
status NEW means I confirmed your bug and "sha hex" is result from bisecting: https://wiki.documentfoundation.org/QA/Bibisect
Comment 5 Hans-Martin Brückmann 2018-02-10 10:50:38 UTC
Thank you
Comment 6 Xisco Faulí 2018-02-26 13:15:11 UTC
Steps to reproduce:
1. Open attached document
2. Double click on cell D4
3. Click somewhere else

Observed behaviour: Rotated text disappears.
Comment 7 Xisco Faulí 2018-02-26 13:17:21 UTC
Regression introduced by:

author	Armin Le Grand <Armin.Le.Grand@cib.de>	2017-07-20 15:11:30 +0200
committer	Armin Le Grand <Armin.Le.Grand@cib.de>	2017-07-28 17:51:56 +0200
commit e32c12a444e5bd0c6735db8e8008340c29a7e25e (patch)
tree 50262efd53047ee92f5f39f9a1fd6c9e00917fc7
parent 1118e5b986e4df8a417edcd4ee23a40fb64a0a38 (diff)
borderline: adaptions to primitives
Handling and paint of borderlines greatly adapted
to primitive usage. Solved the double paint mechanisn
to no longer use the sc-local special cases. The
svx tooling for borderline paint is now the only one
and was extended to also handle diagonal lines.
Big cleanups/removals of old paint to OutputDevice
and sc-specific rendering. All other app-usages
of borderline also adapted. Preparations for careful
line-start/end adaption prepared and possible due to
unified coordinate-system usages and basegfx class-usage

Bisected with: bibisect-linux64-6.0

Adding Cc: to Armin Le Grand
Comment 8 m_a_riosv 2018-03-21 18:51:13 UTC
Works fine for me.
Version: 6.0.2.1 (x64)
Build ID: f7f06a8f319e4b62f9bc5095aa112a65d2f3ac89
CPU threads: 4; OS: Windows 10.0; UI render: default; 
Locale: es-ES (es_ES); Calc:
Comment 9 Xisco Faulí 2018-03-28 15:33:13 UTC
Still reproducible in

Version: 6.1.0.0.alpha0+
Build ID: 8329f4541e27402d19729ae1588af8bfe61f7b49
CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group
Comment 10 Xisco Faulí 2018-03-28 15:36:58 UTC
Same in

Version: 6.1.0.0.alpha0+
Build ID: 751191ed2d7d6af6eddc3d738e8c45b0a2ab2572
CPU threads: 1; OS: Windows 6.1; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-03-21_23:24:05
Locale: es-ES (es_ES); Calc: group
Comment 11 Armin Le Grand 2018-03-28 16:23:45 UTC
Just a repaint problem: Press CTRL+SHIFT+R to repaint and it wil reappear. This means not a problem in files or exports. But definitely ugly - triggering a repaint is missing somewhere
Comment 12 Armin Le Grand 2018-04-05 09:46:43 UTC
Adding Eike to CC.
It's a repaint problem, I have no idea where calc repaints a Cell when TextEdit ends. Or what exactly goes on on repaint.
I added a unrotated text in the Cell left to the rotated one, that works. So definitely has to do with rotation being active.
Also happens when cursor on Cell and changing Background: Unrotated Text gets painted, Rotated Text not.
@Eike: Do you have a code pointer where that text paint happens in Calc?
Comment 13 Xisco Faulí 2018-04-05 15:21:17 UTC
*** Bug 116831 has been marked as a duplicate of this bug. ***
Comment 14 Eike Rathke 2018-04-07 12:45:03 UTC
So it appears to be painted shortly and then over-painted by the background again. Some code pointers:
Drawing things happens in
sc/source/ui/view/gridwin4.cxx ScGridWindow::DrawContent()
called from 
sc/source/ui/view/gridwin4.cxx ScGridWindow::Draw()
after having obtained cell infos from
sc/source/core/data/fillinfo.cxx ScDocument::FillInfo()

Hope that helps.
Comment 15 Armin Le Grand 2018-04-19 12:30:58 UTC
Using current master, the erros when zooming are gone.
Still present is
- deactivate TextEdit
- change BG
thus debugging into it...
Comment 16 Armin Le Grand 2018-04-19 13:50:34 UTC
Array::HasCellRotation() is wrong in these cases, thus no paint of rotated txt. Seems like not all creators of svx::frame::Array are correct yet.
Comment 17 Armin Le Grand 2018-04-19 14:18:52 UTC
Start is gridwin4.cxx:469 where a ScTableInfo is filled. In :476 goes to ScOutputData constructor, and there calls ScOutputData::SetCellRotations. Unfortunately the indices seem to be wrong, the sc/source/ui/view/output.cxx:666 call to Array::SetCellRotation *wants* to se the CellRotation, but in CELLACC (framelinkrarray.cxx:532) accesses (using mxImpl->GetCellAcc) the Cell aDummy (see framelinkrarray.cxx:256). Thus, the value is LOST.
@Eike: All this indices are strange - could you have a look? Just open the bugdoc, select the cell (I think 4,4) with rotated text, change BG color using Sidebar, set BP as described above.
Comment 18 Armin Le Grand 2018-04-19 14:27:23 UTC
Looks like I have to substract nVisX1/nVisY1 in ScOutputData::SetCellRotations line 666 ?!? This seems to make it work, these are zero at full repaint (CTRL+SHIFT+R) and 0, 2 when only invalidating the single cell by changing the color...
Comment 19 Commit Notification 2018-04-20 09:55:42 UTC
Armin Le Grand committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=0185e65bcd73dbad2205a39369e1e06b33a2ca51

tdf#115582 Correct coordinate usage for sc's ::Array

It will be available in 6.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.
Comment 20 rosma 2018-05-07 11:41:51 UTC
Using the latest daily build (-master~2018-05-07_00.34.00_LibreOfficeDev_6.1.0.0.alpha1_Linux_x86-64) incorporating the bug fix cured the problem for me. Thanks for your efforts in fixing this problem.
Comment 21 Armin Le Grand 2018-05-19 18:08:08 UTC
Done in latest master
Comment 22 Xisco Faulí 2018-05-28 12:10:46 UTC
(In reply to rosma from comment #20)
> Using the latest daily build
> (-master~2018-05-07_00.34.00_LibreOfficeDev_6.1.0.0.alpha1_Linux_x86-64)
> incorporating the bug fix cured the problem for me. Thanks for your efforts
> in fixing this problem.

Thanks for checking. Setting to Verify!
Cherry-picked to 6.0: https://gerrit.libreoffice.org/#/c/54922/
Comment 23 Commit Notification 2018-05-29 08:24:46 UTC
Armin Le Grand committed a patch related to this issue.
It has been pushed to "libreoffice-6-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=08e45e11a0e74cdb4a17ec29df9d03ad03b7f7c0&h=libreoffice-6-0

tdf#115582 Correct coordinate usage for sc's ::Array

It will be available in 6.0.5.

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.