Apache OpenOffice (AOO) Bugzilla – Issue 83735
Within Drawing Layer, object positions are not moved correct amount when row/column is resized.
Last modified: 2017-05-20 11:27:41 UTC
Within Drawing Layer, object positions are not moved correct amount when row/column is resized. To reproduce: 1. In Calc, click Tools -> Options.... In the OpenOffice.Org Calc / General option panel, set Measurement Unit to Centimeter. 2. Select cell A1. 3. Click Format -> Column -> Width.... Set the width to 0.50cm. Click OK. 4. Enable View -> Toolbars -> Drawing. The Drawing toolbar should now be visible. 5. Within cell B2, draw a rectangle. 6. Select the Rectangle with the selection tool, then Cut it. Select cell B2, then paste it. It should now be located in the top-left corner of cell B2. 7. Right-click the Rectangle, and select Position and Size.... 8. Note 1: Position X now reads 0.48cm, NOT the expected 0.50cm (due to setting row A to 0.50cm in step 3). 9. Change Position X to be 0.50cm. Click OK. 10. Select cell A1. Click Format -> Column -> Width.... Set the column width to 12.00cm. Click OK. 11. Right-click the Rectangle, and select Position and Size.... The Rectangle *should* have an X-Position of 12.00cm, but it doesn't; it has an X-Position of 11.96cm.
The problem is the TwipsToMM() and ReverseTwipsToMM() functions in drwlayer.cxx. These functions are inherently "lossy," as they convert twips to hundredths-mm using a pre-defined constant. So a twips value of 6803 twips (from 12cm -> twips [0]) becomes 11954 HMM after the TwipsToMM() call. (Not that TwipsToMM() gets 6803, it gets 11.50cm->twips, but the point is that TwipsToMM() is still "lossy.") [0] http://www.translatorscafe.com/cafe/units-converter/typography/calculator/
Created attachment 49741 [details] Initial patch for proper computation of new row/column offsets
Using MetricField::ConvertDoubleValue() fixes the improper computation of new row/column offsets, allowing the updated X-position in step 11 to properly read 12.00cm. (MetricField::ConvertDoubleValue() is what the Format->Row->Height... and Format->Column->Width... dialogs use to determine the height/width of a dialog in cm based on the internal Twips width/height measurement. It seems to be considerably more accurate and less "lossy" than the existing TwipsToMM() code.)
Created attachment 49742 [details] Lots of aligned rectangles.
Created attachment 49743 [details] Bad rectangle/cell overlapping.
However, not all is perfect with this code. For one thing, the cut+paste in Repro step 6 places the rectangle anchor into the wrong cell -- into the cell to the *left* of the desired cell. More significantly, see rect-test-lots.ods. I created it by copying the rectangle, selecting each cell in rows 3-50, and pasting the rectangle. In theory, each rectangle should be in the upper-left corner of each pasted cell. If you scroll down, the rectangles no longer align with the cells; see i83735-bad-cell-overlap.png.
Created attachment 49744 [details] Updated patch for proper twip/hmm unit conversion.
Created attachment 49745 [details] rect-test-lots.ods after applying 2nd patch.
This updated sc-drwlayer-units.diff patch removes all use of the HMM_PER_TWIPS constant to perform twips->hmm or hmm->twips conversion and instead uses MetricField::ConvertDoubleValue(). This appears to fix the bad cell overlapping observed in i83735-bad-cell-overlap.png.
The same HMM_PER_TWIPS factor is also used for stuff like cell anchors, outside of drwlayer.cxx. With the patch, these would be inconsistent. So more changes are necessary. The changed behavior might then be unexpected in cases like old files with absolute positions (sheet anchor), etc. Unless all of that is solved, the inaccurate values in the position dialog seem like the smaller problem.
I'm adding this comment to all open issues with Issue Type == PATCH. We have 220 such issues, many of them quite old. I apologize for that. We need your help in prioritizing which patches should be integrated into our next release, Apache OpenOffice 4.0. If you have submitted a patch and think it is applicable for AOO 4.0, please respond with a comment to let us know. On the other hand, if the patch is no longer relevant, please let us know that as well. If you have any general questions or want to discuss this further, please send a note to our dev mailing list: dev@openoffice.apache.org Thanks! -Rob
Reset assigne to the default "issues@openoffice.apache.org".