The image will overflow Sheet1!B30 cell after this changes, the image with AutoFit inserted by this unit test.

I fear that this is a very complex subject which needs to be discussed, please hear me out.

First of all I just realized another issue of the current implementation and fork (at least from my point of view). If I understand you correctly you suggest, that AutoFit should add pictures into the target cell and resize the image in a way, that it is not rendered beyond the cell borders.

However the current implementation changes the from anchor if the offset leaves the area of the cell. This means that a cell insertion targeting A1 can end up starting in A2. While the initial visible result seems to be correct there is an issue: The image will be moved if Cell A1 is being enlarged. This is not correct and I think that I should fix this as well.

The starting anchor point can be outside of the cell dimensions which leads to correct anchoring and simply hides the image as long as the cell is not expanded enough. In the end this will still break your expectation, but just in another way.

AutoFit would resize the image respecting the aspect ratio to the current cell dimensions and if an offset is used which causes the image to overflow the cell, it would look cut off, but this could be changed by the user, by expading the row / col size.

However, from my understanding your expected behaviour comes along with various problematic edge cases and this is why I would like to suggest considering to review this feature:

1. If the same image is added twice with the same settings except the offset, it might be possible, that both images end up with different sizes. Should varying offsets really affect the image size?
2. Consider the case of adding multiple images or dynamically calculating cell sizes and images positions - Would it really be the expected behaviour, if there are only a few pixels left from the start anchor, that an image is added with for example 5x5, 1x1 pixels?
3. When adding multiple images dynamically, maybe even with varying native sizes, this may be not the desired behaviour like in my case and can only be fixed by calculating the required col / row size for all rows / cols in advance.

Otherwise another option like "ResizeToCell" would be required or even target size fields for the picture struct.

What are your thoughts about this?

Yes, I agree with you, offsets shouldn't affect the image size. Users using AutoFit with Offset will be affected after these changes, like user case in #1560, I accept this, we can make these changes as a breaking change and notice user in release notes.

Any update for other remaining code review issues?

Im working on it hoping to complete it today, from what I have noticed the anchoring wasnt fully correct and confused me a bit.

@xuri I think its finally done

Some explanations:

• oneCellAnchors (<=> InsertionMode Picture shall move with cell) were not fully implemented, which could lead to images not beeing shown - fixed

• oneCellAnchors have not been adjusted on col / row insertion - fixed

• insertionPositionCalculation does not modify anymore the targeted starting cell => from my point of view the targeted starting cell must not be modified, since the resulting behaviour will otherwise not be equal to the requested one:

(Images get seperated by cell overflows)

• updated some excel default values and unit conversion formulas => at least for me (a german office 365 user) these numbers seem to work a little better, but the best case would be to include some font based calculations

• row and col functions to retrieve the height / width did seem to handle the hidden row / col case incorrectly - fixed

Please notice regarding the anchoring behaviour:
Using a twoCellAnchor (default) the starting cell and its size are the most top left point of the area of insertion; A twoCellAnchor with offsets will cause headaches, since the image will start scaling based on its own size and cell sizes etc. Also it is not possible to have an offset size > the area size of the starting cell.

After these changes, add 60px x 60px image to test issue #2001, the size of the last 3 images is incorrect.

You can download this image attachment:

The result:

I will try to reproduce this issue and add a test case for it 👍 (Propably on monday)

Please set the target branch to master instead of v2. Create branch from master.

I fixed the absolute anchoring issue - the issue arised from updating the anchors since oneCellAnchors have absolute sizes.

Hopefully this covers all your questions or issues: If we are talking about oneCellAnchors, Excel starts overlapping images from last to first if the images do not fit into the column. This can be observed by resizing the column. Implementing an overflow by hand creates other issues like I have mentioned earlier (image separation; incorrect anchor cell, which causes unexpected movements on column resizing/hiding). At least currently I do not know about a property or similar to control or override this behavior of excel regarding too many images for column size X.

Does this answer your question or did I miss something?

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.23%. Comparing base (3650e5c) to head (7178a11).
Report is 10 commits behind head on master.

@@           Coverage Diff            @@
##           master    #2123    +/-   ##
========================================
  Coverage   99.22%   99.23%            
========================================
  Files          32       32            
  Lines       30114    30222   +108     
========================================
+ Hits        29882    29991   +109     
+ Misses        154      153     -1     
  Partials       78       78            

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.