Bug 44337 - FORMATTING when FILEOPEN .sxc: border distances to cell contents differ from original distances
Summary: FORMATTING when FILEOPEN .sxc: border distances to cell contents differ from ...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Markus Mohrhard
URL:
Whiteboard: BSA target:3.6.0 target:3.5.3
Keywords: regression
Depends on:
Blocks:
 
Reported: 2011-12-30 20:43 UTC by Todd
Modified: 2012-04-02 13:28 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Tyhe original scx under Open Office (19.87 KB, application/vnd.sun.xml.calc)
2011-12-30 20:43 UTC, Todd
Details
What it should look like (rendering under Open Office) (26.95 KB, application/pdf)
2011-12-30 20:46 UTC, Todd
Details
What it looks like under LO 3.4.4 (137.40 KB, image/png)
2011-12-30 20:49 UTC, Todd
Details
What it looks like under LODEV 3.5 beta2 (41.00 KB, image/png)
2011-12-30 20:51 UTC, Todd
Details
Rendered under 3.5beta2 (41.00 KB, image/png)
2012-01-01 16:44 UTC, Todd
Details
pdf rendering under 3.5b2 (31.22 KB, application/pdf)
2012-01-01 16:44 UTC, Todd
Details
00 3.3 and LO 3.5b2 side by side comparison (289.40 KB, image/png)
2012-01-01 16:55 UTC, Todd
Details
Conversion absurdity (30.45 KB, image/png)
2012-01-20 10:00 UTC, Todd
Details
no symptom change in 3.5 (51.96 KB, image/png)
2012-02-17 11:12 UTC, Todd
Details
Test Kit (14.19 KB, application/zip)
2012-03-06 11:01 UTC, Rainer Bielefeld Retired
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Todd 2011-12-30 20:43:52 UTC
Created attachment 54990 [details]
Tyhe original scx under Open Office

Hi All,

When a customer of mine imports her *.sxc spreadsheets from Open office, the format is lost in LO 3.4.4 and doesn't show anything at all when imported into LO 3.5.0Beta2.  I will attach a test document from her and a PDF showing what the SXC looks like under Open Office.

Many thanks,
-T
Comment 1 Todd 2011-12-30 20:46:16 UTC
Created attachment 54991 [details]
What it should look like (rendering under Open Office)
Comment 2 Todd 2011-12-30 20:49:05 UTC
Created attachment 54992 [details]
What it looks like under LO 3.4.4
Comment 3 Todd 2011-12-30 20:51:24 UTC
Created attachment 54993 [details]
What it looks like under LODEV 3.5 beta2
Comment 4 Todd 2011-12-30 21:00:23 UTC
Customer reported that her version of Open Office was 3.3 for windows
Comment 5 Rainer Bielefeld Retired 2011-12-31 00:33:20 UTC
This is not a valid bug report, but a riddle

@Todd:
for me that all looks rather similar, there is a little problem with 3.5, you have to close preview and reopen to see the result.

If you want to get something fixed, please create a document comparing screenshots OOo <-> LibO for every detail that does not look as expected.
Comment 6 Todd 2011-12-31 13:10:04 UTC
Hi Rainer,

This is what the customer told me:  "I have a lot of forms that will need to be modified if we continue using Libre.  With the form I originally complained about, I ended up having to remove a couple of lines and rearrange so that everything would fit on the page.   Shrinking the margin was not enough."

I can see this with my own eye balls.  If you can not see this, I suppose I could circle all the differences in red?  You can start with the "couple of lines that have to be removed" and the "shrinking the margins".  There are two problems for you to fix.

And if 3.5 "close preview and reopen to see the result" there is the another bug for you to fix.

Oh, and in 3.5 b2, I can not find "preview" in the "View" pull down.  Another bug to fix.

Let me know if you want me to circle anything in red for you.

-T

p.s. how is envelope printing coming?
Comment 7 Rainer Bielefeld Retired 2012-01-01 00:27:12 UTC
(In reply to comment #6)
 
>  I suppose I could circle all the differences in red? 

Yes, please do so!
Comment 8 Todd 2012-01-01 16:44:14 UTC
Created attachment 55031 [details]
Rendered under 3.5beta2
Comment 9 Todd 2012-01-01 16:44:59 UTC
Created attachment 55032 [details]
pdf rendering under 3.5b2
Comment 10 Todd 2012-01-01 16:55:54 UTC
Created attachment 55033 [details]
00 3.3 and LO 3.5b2 side by side comparison

Hi Rainer,

I was about to start red circling on SideBySide.png, but then I saw what was easily explained as the differences.

SideBySide is both the pdf's imported into GIMP.  The one on the left is the original OO 3.3 rendering.  The one on the right is rendered under 3.5b2.
You will notice that zoom is set to 65% on both images.  I lined both up on my screen and took screen shot (also with GIMP).

Difference 1): the fonts on the 3.5b2 are larger and bold.  Take a look at the "Are you ready".  The "A" and the "R" are very different between the renderings.  They are clearly different fonts.  No red circles as I would have had to circle everything.

Difference 2):  take a look a the bottom of the page.  The page on 3.5b2 is longer.  This demonstrated the customer's comment: "I ended up having to remove a couple of lines and rearrange so that everything would fit on the page.   Shrinking the margin was not enough."

Let me know if you need more information.

Many thanks,
-T
Comment 11 Todd 2012-01-01 18:42:20 UTC
Hi Rainer,

   I just sent a request to the customer asking her if she has "Batang" font installed on both computers in question.  I do believe the default font in OO and LO are different.  This may not be an LO problem at all.  I will get back.
Comment 12 Todd 2012-01-18 11:16:56 UTC
Customer got back with me.  She has the font on both computers.  Seems that the font renders "taller" on LO than OO, which causes LO to run off the page.
Comment 13 Todd 2012-01-20 10:00:21 UTC
Created attachment 55841 [details]
Conversion absurdity

Hi Rainer,

   Guess what?  I was at the customer's site yesterday and I figured out the the conversion error.  And, I now have something rational for you to fix (no needle in a hay stack).  I have attached the error as a screen shot.  The conversion error was in the "Borders" (Format --> Cell --> Borders):

1) the conversion did not enforce the "Spacing to Contents" "synchronize" setting.  "Synchronize" can not be enabled and the "Spacing to Contents" be different values.  But, it is here.  An absurdity.

2) the conversion incorrectly set the top and the bottom "Spacing to Contents" to 1.4pt (all should have been 1.0pt)

Manually setting all the "Spacing to Contents" to 1.0pt completely corrected the run off the bottom of the page spacing problem the customer was experiencing.

Let me know if you need any further info.

Many thanks,
-T
Comment 14 Todd 2012-01-20 10:04:42 UTC
Hi Rainer,

I just created a fresh (new) spreadsheet.  The "synchronize" 1.0pt, 1.0pt, 1.4pt, 1.4pt absurdity also exists.  Maybe this is not a conversion error?

-T
Comment 15 Todd 2012-01-20 10:53:02 UTC
Hi Rainer,

I just created a fresh (new) spreadsheet.  The "synchronize" 1.0pt, 1.0pt, 1.4pt, 1.4pt absurdity also exists.  Maybe this is not a conversion error?

-T
Comment 16 Todd 2012-02-17 11:12:46 UTC
Created attachment 57224 [details]
no symptom change in 3.5

The absurdity with synchronization set and the borders being different still exists in LO 3.5  (LibO_3.5.0_Linux_x86-64_install-rpm_en-US.tar.gz)
Comment 17 Rainer Bielefeld Retired 2012-02-27 10:43:34 UTC
I wonder whether we have real bugs here. For example, "Absurdity" in Comment 13 ... 16 seems to be a simple user error. Checking "Synchronize" will not synchronize values immediately, but the next modification of any of the distance values will be transferred to and used for all 3 other distances. That works fine for Sample document cell G4 

So I mark this one as INVALID

@reporter:
I'm a little tired with your reporting. Todd, we are not intereseted in your ratings or what your customer wrote, but in clear, comprehensible bug descriptions. 

May be hints on <http://wiki.documentfoundation.org/BugReport> will help you to find out what information will be useful to reproduce your problem? If you believe that that  is really sophisticated please as for Help on a user mailing list.

If you want to submit a new bug for a real problem, please:
- Write a meaningful Summary describing exactly what the problem is for
  ONE problem (May be something like "synchronizing border distances to cell
  contents does not work for .sxc created with OOo 1.1.4)
- Contribute a step by step instruction containing every key press and every 
  mouse click how to reproduce your problem (due to example in Bug 43431). 
  Everything regarding more than 1 cell might be no good report.
– if possible contribute an instruction how to create a sample document 
  from the scratch
- add information 
  -- what EXACTLY is unexpected
  -- and WHY do you believe it's unexpected (cite Help or Documentation!)
  -- concerning your OS (Version, Distribution, Language)
  -- concerning your LibO version and localization (UI language, Locale setting)
  –- Libo settings that might be related to your problems 
    (video hardware acceleration ...)
  -- how you launch LibO and how you opened the sample document
  –- If you can contribute an OOo Issue that might be useful
  -- everything else crossing your mind after you read linked texts
Comment 18 Todd 2012-02-27 15:18:30 UTC
(In reply to comment #17)
> I wonder whether we have real bugs here. For example, "Absurdity" in Comment 13
> ... 16 seems to be a simple user error.

The user did not do this.  It was that way when she got to it.  Under
the old OO the cell borders were all 1.0 pt.  When she opened it in LO, it was changed to: 1.0, 1.0, 1.4, 1.4 and synchronized.  She did nothing other than open the document in LO.

You can simulate this yourself by opening a new spreadsheet and checking the cell borders.  You will find the same "1.0, 1.0, 1.4, 1.4 and synchronized" peculiarity.  (I think I offended by calling it an "Absurdity" -- none was intended.)

> Checking "Synchronize" will not
> synchronize values immediately, but the next modification of any of the
> distance values will be transferred to and used for all 3 other distances. 

This is true.  The problem lies with "1.0, 1.0, 1.4, 1.4 and synchronized" being the default.  Probably best to turn off the "synchronized" if the default is "not synchronized".  I do think changing the default back to 1.0 all around would solve this issue.

Many thanks,
-T
p.s. I will work on my technical writing.
Comment 19 Rainer Bielefeld Retired 2012-03-06 10:57:33 UTC
Now [Reproducible] with reporter's sample or empty spreadsheet from OOo 1.1.4 (see attached mysampleOOo114.sxc) and "LibreOffice Portable 3.3.0  - WIN7  Home Premium (64bit) German UI [OOO330m19 (Build:6) tag libreoffice-3.3.0.4]"

OOo shows all distances 0,35mm, LibO left/right 0,35 and topTbottom 0,48mm
This happens with sample documents also from OOo 3.3 and even from LibO 3.3.0 (other LibO versions not tested).

Problem still visible with 3.5.1 RC1 

Please check with documents from my test kit created with various different versions

@Todd:
For other problems you see please submit additional separate Bugs
Comment 20 Rainer Bielefeld Retired 2012-03-06 11:01:01 UTC
Created attachment 58068 [details]
Test Kit

For details please see Comment 19!

@Kohei:
Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug
Comment 21 Rainer Bielefeld Retired 2012-03-27 10:45:31 UTC
Related to "Bug 47954 - FILEOPEN: VIEWING of picture anchored as character with unexpected distance to border"?
Comment 22 Markus Mohrhard 2012-03-31 18:49:24 UTC
I'll look into the border bugs.
Comment 23 Not Assigned 2012-04-02 08:34:46 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=843dd3f75e4d35b8ae5fd3be6804e54233292948

this hack in no longer needed, fdo#44337
Comment 24 Not Assigned 2012-04-02 08:35:14 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=149650b087ab5b15ef23e4ac6af5368b2820af1e

show synchronized checked only if all margins are the same, related fdo#44337
Comment 25 Not Assigned 2012-04-02 13:16:31 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "libreoffice-3-5":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=b2a20dad907bfd6ca14847d548b44ad8b9ee5321&g=libreoffice-3-5

show synchronized checked only if all margins are the same, related fdo#44337


It will be available in LibreOffice 3.5.3.
Comment 26 Not Assigned 2012-04-02 13:28:23 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "libreoffice-3-5":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=643fd5a6d2f72e55b243290b85be25f77dcf7be8&g=libreoffice-3-5

this hack in no longer needed, fdo#44337


It will be available in LibreOffice 3.5.3.