[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

@Caolán:
I saw that your have been involved in Drawing Layer redesign. 
Please feel free to reassign if it's not your area!

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

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

Working on this.

Fixed in master with http://cgit.freedesktop.org/libreoffice/core/commit/?id=3976f78ac001ad3d14d3fdcd6c53e967ea656037

Hi Everyone,

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

Have a nice Sunday,

Carlo

@Carlo Strata:
I doubt that there will be a RC3

3.4.4-rc3 is not planed. I am sorry to say but we will not do rc3 because of this fix.

@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

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

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

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

(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

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

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