Apache OpenOffice (AOO) Bugzilla – Issue 4378
orientation of cell content gets lost if exporting as excel 97 or html
Last modified: 2013-08-07 15:14:58 UTC
in my spreadsheet I rotated the writing in one row for 90 degrees to the left. If I export the sheet as excel 97 or html the writing is not rotated anymore. Exporting as excel 95 works fine
Hi Norbert, I can't reproduce this problem. Could you please attach a sample document? Thanks and bye, Oliver
Created attachment 1698 [details] Text in calc sheet of Staroffice 5.1. Converting to MS97 shows the error (only) in the second table.
Reproduced with bugdoc only on second sheet. Weird.
Take it.
.
I too have the problem of disappearing regular and bold-regular font shapes, so I tried the workaround... (0)pern:~/lib/OpenOffice.org1.0/user/psprint% ls -l total 8 drwxr-xr-x 2 romano romano 4096 Jun 7 15:37 driver drwxr-xr-x 2 romano romano 4096 Jun 7 15:37 fontmetric -r--r--r-- 1 romano romano 0 Jun 17 17:23 pspfontcache Now I cannot run openoffice: (134)pern:~% lib/OpenOffice.org1.0/soffice zsh: 12158 abort lib/OpenOffice.org1.0/soffice (134)pern:~% ...any idea? My system is a RH7.3 one. Will try the other tricks...
I have agreed with Daniel to have a look at this. My first impression is that I can where this error occurs: xcl97rec.cxx: ExcXf8::ExcXf8() if nTrot == xlTextOrientTopBottom nTrot = 0x00FF; else if(pPattAttr) nTrot = XclTools::GetExcRotation(....); I can see that nTrot is set to 90 for sheet 1 and set to 0 for sheet 2 by the 'else' statement above despite the fact that both rows have correctly set the orientation to xlTextOrient90ccw. There is a lot I am not sure about: like why does row 0 on sheet 1 have the nTrot = xlTextOrientTopBottom. But for now I will ignore that and concentrate on why nTrot is set to 0 for sheet 2.
Hi John, You are clearly on the right way. As you can see in the documentation for XF records, BIFF2-BIFF7 supports only 0°, 90°, -90° and stacked. In BIFF8 this is replaced by a rotation angle. In Calc there is a similar thing: An (old) SvxOrientationItem, containing an enum with the values from above, and a (newer) SfxInt32Item containing an angle. The ExcXf c'tor (excel/excrecds.cxx) translates the SvxOrientationItem item to the eOri enum (for BIFF5/BIFF7). Then, the ExcXf8 c'tor translates the SfxInt32Item to the rotation, using GetExcRotation(). The cells in the second sheet do not contain the new item, only the old item (it seems to be an old file). The ExcXf c'tor sets the 90° enum, but the ExcXf8 c'tor doesn't care and looks only for the SfxInt32Item. If this item is not present, the GetItem() method returns the default value 0. The solution would be to check whether an enum is already set (something like eOri!=xlTextOrientNoRot) and translate this enum to an angle, otherwise read the rotation from the SfxInt32Item item (the existing code). I reassign this issue to you.
Created attachment 4004 [details] Proposed patch to fix this issue
Created attachment 4009 [details] Use the more readable 90 and 180 rather than the hex values
Thanks to all who contributed to this. Checked this code fix in today.
re-open to assign to QA
re-assign to QA
re-set to fixed
Verified in OOo 1.1 Beta2.
closed ...