Bug Hunting Session
Bug 37083 - Position and Size change for picture anchored to cell
Summary: Position and Size change for picture anchored to cell
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.4.0 Beta1
Hardware: All Windows (All)
: medium normal
Assignee: Eike Rathke
URL:
Whiteboard: target:3.5.0
Keywords:
: 40459 42599 (view as bug list)
Depends on:
Blocks: mab3.4 53228
  Show dependency treegraph
 
Reported: 2011-05-10 13:01 UTC by Claude
Modified: 2015-09-21 17:14 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample spreadsheet with picture inserted (17.85 KB, application/vnd.oasis.opendocument.spreadsheet)
2011-05-10 13:01 UTC, Claude
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Claude 2011-05-10 13:01:09 UTC
Created attachment 46568 [details]
Sample spreadsheet with picture inserted

An inserted picture intended to be part of a header doesn´t keep its size and position when the spreadsheet is saved.
I´ve reproduced the bug consistently:
1) Create a new spreadsheet
2) Create header text
3) Set column width to fit the picture
4) Insert picture from file
5) set position and size of the picture
Initial values
position x: 17,38 cm
position y: 0,13 cm
width: 6,37 cm
height: 3,08 cm
6) OK
7) Save file

When the file is opened again the values are:
position x: 17,44 cm
position y: 0,13 cm
width: 6,38 cm
height: 3,09 cm
Saving and opening again
position x: 17,51 cm
position y: 0,13 cm
width: 6,32 cm
height: 3,09 cm
Saving and opening again
position x: 17,57 cm
position y: 0,13 cm
width: 6,26 cm
height: 3,09 cm
and so on.

Checking size and position protection boxes protects only the size.  The position drifting still happens despite being protected.  The same changes keep happening.

Bug discovered since version beta 3.4.1 asd still present in 3.4.4  DEV300m103 (Build:4)
OS: XPSP3

Trial file with header and picture attached.
Comment 1 Rainer Bielefeld Retired 2011-05-10 23:15:03 UTC
[Reproducible] with reporter's sample (and also my own sample documents) and "LibreOffice 3.4Beta4  – WIN7  Home Premium  (64bit) German UI [DEV300m103 (Build:4)]". With nearby every save - close - reopen the picture moves a little down, and a little bit more to the right, also size changes. Id does not matter what unit is selected, but with inch at least size steams to be stable (might have been accidental).

Problem is only visible if picture is anchored to cell.

Also Drawing objects are affected.

Works fine with OOo 3.1.1
Comment 2 Rainer Bielefeld Retired 2011-05-12 06:50:59 UTC
@Caolán:
I saw that your have been involved in Drawing Layer redesign. 
Please feel free to reassign if it's not your area!
Comment 3 Caolán McNamara 2011-06-21 07:20:21 UTC
right, so figured this out, it's insane.

Lets start with setting a column width, in the file we have column widths of
1.304cm, 11.183cm and 4.634cm on import these are converted from 100th of a mm to the internal twips in ScTableColumnsObj::setPropertyValue with HMMToTwips which does... (nHMM * 72 + 63) / 127; i.e. ignoring int rounding trick this is a scale of 0.566929134, (72/127). That's the classic twip of twenty in a point, where a point is 1/72th of an inch as per postscript, i.e. nHMM / 1000 / 2.54 * 72 * 20. So we are converting column widths to "normal" twips. So 1.304cm becomes 739twips internally

But when we export back to xml we get the anchor point of the drawings with ScDocument::GetMMRect and that converts from HMM to twips with * HMM_PER_TWIPS and HMM_PER_TWIPS in global.hxx uses (crazy) 72.27 points per inch. i.e. a TeX point, not a postscript point. 

So in some places we decide that a twip is 1/(72.27*20) and in others its 1/(72*20). So when we export the offset of the graphic we have its position in "postscript twips", but we have the cell position in "tex twips", and subtract the two to get the offset, so it gradually walks down and to the right per save
Comment 4 Caolán McNamara 2011-08-30 04:17:30 UTC
*** Bug 40459 has been marked as a duplicate of this bug. ***
Comment 5 Eike Rathke 2011-10-25 11:31:41 UTC
Working on this.
Comment 7 Carlo Strata 2011-11-06 03:58:23 UTC
Hi Everyone,

could we hope having this important render quality patch on Libò 3.4.4-RC3?

Have a nice Sunday,

Carlo
Comment 8 Rainer Bielefeld Retired 2011-11-06 04:14:07 UTC
@Carlo Strata:
I doubt that there will be a RC3
Comment 9 Petr Mladek 2011-11-07 07:42:12 UTC
3.4.4-rc3 is not planed. I am sorry to say but we will not do rc3 because of this fix.
Comment 10 Carlo Strata 2011-11-07 08:04:16 UTC
@Everyone: ok no RC3, none are dieing... but rendering quality will wait once more... ;-)

I will make adopt Libò to a set of high technical colleagues and print quality has to be the reference one..., imho.

@Eike: is this fix mature for release/production?

Thank you,

Carlo
Comment 11 Eike Rathke 2011-11-09 04:08:58 UTC
(In reply to comment #10)
> @Eike: is this fix mature for release/production?

I think so. However, be aware that this slightly changes the printout layout because now the sizes printed actually match what's given in the UI ... so if your production environment relies on identical (on point/pixel basis) printouts, e.g. multi-paged forms, some people may be disappointed as this may lead to page breaks being generated at different positions, a page more printed, etc. etc.
Comment 12 Carlo Strata 2011-11-09 04:44:16 UTC
(In reply to comment #11)
> (In reply to comment #10)
> > @Eike: is this fix mature for release/production?
> 
> I think so. However, be aware that this slightly changes the printout layout
> because now the sizes printed actually match what's given in the UI ... so if
> your production environment relies on identical (on point/pixel basis)
> printouts, e.g. multi-paged forms, some people may be disappointed as this may
> lead to page breaks being generated at different positions, a page more
> printed, etc. etc.

Thank you Eike, I understand.

I think that what you say IS a valid reason to adopt the fix asap before "the bad" become the reference behavior!!! Isn't it? ;-)

Effectively the (A)OOo behavior seems to be correct in the mean Libò has with this patch, so we must close the Libò release time window in which the screen rendering differ from print rendering, once more asap.

What do you think about, Eike?
Comment 13 Eike Rathke 2011-11-09 05:48:46 UTC
(In reply to comment #12)
> I think that what you say IS a valid reason to adopt the fix asap before "the
> bad" become the reference behavior!!! Isn't it? ;-)

Well, "the bad" has been the reference behavior for more than 10 years now.. the printout values never matched the actual position/size values displayed in the UI.

> Effectively the (A)OOo behavior seems to be correct

It does not have the walking effect, but the printout appears to be identical (wrongly not matching values) to what LibO had so far.

So, people will experience that their documents will print slightly different and to some that may matter, because of this I would not recommend to have this change in a micro release.
Comment 14 Carlo Strata 2011-11-09 06:07:05 UTC
(In reply to comment #13)
> 
> Well, "the bad" has been the reference behavior for more than 10 years now..
> the printout values never matched the actual position/size values displayed in
> the UI.

Ok, I didn't understand it.

> 
> > Effectively the (A)OOo behavior seems to be correct
> 
> It does not have the walking effect, but the printout appears to be identical
> (wrongly not matching values) to what LibO had so far.

So we will have three different behavior in printing with respect to UI:

- (A)OOo 3.x and TDF Libò 3.3;
- TDF Libò 3.4.x (that has yielded this bug and similar others);
- and finally that of TDF 3.5.x?

Is it correct?

> 
> So, people will experience that their documents will print slightly different
> and to some that may matter, because of this I would not recommend to have this
> change in a micro release.

If I have well understood, I agree with you.

So it's very important for who will install/adopt/make adopt/learn/teach/... Libò 3.5.x to well explain this (as a power to which make a big attention) to 3.5.x future users (from February 2012 on).

Thank you,

Carlo
Comment 15 Rainer Bielefeld Retired 2012-02-22 06:15:37 UTC
*** Bug 42599 has been marked as a duplicate of this bug. ***
Comment 16 Rainer Bielefeld Retired 2012-02-22 07:47:05 UTC
*** Bug 42599 has been marked as a duplicate of this bug. ***