Created attachment 139731 [details]
Example for Issue Rotatet Text gets invisble

? Don´t understand this sha hex... ?

(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

Thank you

Steps to reproduce:
1. Open attached document
2. Double click on cell D4
3. Click somewhere else

Observed behaviour: Rotated text disappears.

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

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:

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

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

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

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?

*** Bug 116831 has been marked as a duplicate of this bug. ***

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.

Using current master, the erros when zooming are gone.
Still present is
- deactivate TextEdit
- change BG
thus debugging into it...

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.

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.

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...

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.

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.

Done in latest master

(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/

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.