Bug 95165 - FILEOPEN: X and Y Position Offset Not Working with Bitmap Filled Shapes
Summary: FILEOPEN: X and Y Position Offset Not Working with Bitmap Filled Shapes
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
5.1.0.0.alpha0+ Master
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsDevEval
Depends on:
Blocks: Object-Fill-Bitmap
  Show dependency treegraph
 
Reported: 2015-10-19 00:41 UTC by Luke
Modified: 2023-08-17 03:17 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Example of Centered Images (159.50 KB, application/vnd.openxmlformats-officedocument.presentationml.presentation)
2015-10-19 00:41 UTC, Luke
Details
File Opened in Impress vs PowerPoint (129.36 KB, image/png)
2015-10-19 01:04 UTC, Luke
Details
Sample Word Doc with a bitmap filled shape (220.21 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2015-10-19 01:26 UTC, Luke
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Luke 2015-10-19 00:41:39 UTC
Created attachment 119730 [details]
Example of Centered Images

When you use background bitmaps for shapes, you only have the option to control the X and Y Offset. This allows you to position a image, but not fully scale and position it. I propose we add a 2nd mode that allows "Left", "Right", "Top", and "Bottom" Offsets.

This would give the user greater control. It would also give us better interoperability with MSO.
Comment 1 Luke 2015-10-19 01:04:19 UTC
Created attachment 119733 [details]
File Opened in Impress vs PowerPoint
Comment 2 Luke 2015-10-19 01:26:57 UTC
Created attachment 119735 [details]
Sample Word Doc with a bitmap filled shape

I gave a presentation example, but this issue affects all file formats that contain shapes. Here is an example of a Word doc that writer cannot import.
Comment 3 Buovjaga 2015-10-20 17:32:28 UTC
Confirmed.

Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+
Build ID: 186f32f63434e16ff5776251657f902d5808ed3d
TinderBox: Win-x86@39, Branch:master, Time: 2015-10-16_09:42:47
Locale: en-US (fi_FI)
Comment 4 Yousuf Philips (jay) (retired) 2016-07-10 08:06:43 UTC
The current X and Y offset fields under the position section only work for tiling, so firstly that would need to be fixed to work in non-tiling mode.

Then the offset fields would also need to accept negative values.
"<property name="lower">-500</property>" would need to be added to adjustment2 ID in http://opengrok.libreoffice.org/xref/core/cui/uiconfig/ui/areatabpage.ui

With these two things fixed, it would provide the Left and Top offsets found in MSO, while the Right and Bottom are already controlled with the Width and Height fields found under the size section.

So if we take attachment 119735 [details] as an example, the bitmap had Left 17%, Right 20%, Top 18% and Bottom -5%. So when loading the document, instead of LO incorrectly setting both autofit and original, it should have set the Width to 63% and the Height to 85%. Also there is a bug in the Width and Height fields presently, as it dont allow a value above 100% when relative is checked, so that would also need to be corrected.
Comment 5 Luke 2016-07-10 15:10:00 UTC
We need developer to evaluate whether the issues pointed out in #c4 are an actual engine limitation or just the result of a poor UI choice. 

Armin, any thoughts on this?
Comment 6 Yousuf Philips (jay) (retired) 2016-07-10 21:39:56 UTC
(In reply to Luke from comment #5)
> We need developer to evaluate whether the issues pointed out in #c4 are an
> actual engine limitation or just the result of a poor UI choice. 

Yes rishabh is looking into this issue, as it was discussed with him for the redesign of the bitmap section of the area fill dialog. Hopefully he'll have an answer for this within a week.
Comment 7 QA Administrators 2017-09-01 11:15:29 UTC Comment hidden (obsolete)
Comment 8 Luke 2017-09-15 03:16:55 UTC
As of Version: 6.0.0.0.alpha0+
Build ID: f70e0ec6b3c61a7c7caa469949b0ac8016c89854

The  X and Y offset position settings still only work for tiling.
Comment 9 Armin Le Grand 2017-09-15 08:28:48 UTC
The X/Y Offsets are intended for tiling only and define - together with the tiling start position being relative to TopLeft/BottomRight and more - refinement for that values. It is an older concept shining through. Defining the pos and size inside the to-be-filled object is indeed not really (or easily) possible and would need new definitions.
Comment 10 QA Administrators 2019-06-01 02:49:08 UTC Comment hidden (obsolete)
Comment 11 Luke 2019-06-02 01:56:01 UTC Comment hidden (obsolete)
Comment 12 QA Administrators 2021-06-02 03:48:03 UTC Comment hidden (obsolete)
Comment 13 Luke 2021-06-02 15:12:51 UTC
Still no way to set X and Y Position in "Custom Position" or "Stretched". Only Tiling allows this. 

Tested on 7.2 1f85d178f2e
Comment 14 QA Administrators 2023-08-17 03:17:30 UTC
Dear Luke,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug