Thank you for working on this@sramesh750 .

The implementation looks reasonable to me, however it needs at least one test so we can be sure that the issues does not comeback.

Looking at this, I also suspect that we failing to set sub-figures (and their Axes) to be transparent. Would you be willing to also address that issue while you are working on this (and thinking about the right way to test it ;)) ?

@tacaswell Am I supposed to commit the result_images file that was created when running the tests? I am currently unsure of why I have some checks that are failing, such as the AppVeyor build.

Appveyor failing is unrelated (a new release of a jlab extension had a file who's name is too long for the windows version in the appveyor image).

@tacaswell Thank you for all the help! Is there anything else I need to do in order to get this pull request approved?

I do not fully understand the fully transparent image? I guess before you would see the outlines of the sub-figures? However, as it stands the test is notgreat because if you deleted the body of the test function it would still pass!

I believe this new test should not cause false positives since I added visible subplots.

Can you squash this down to one commit? I expect this to fail because you added and then changed the image file in this PR (we only want the good version in the history!).

If you are not comfortable doing the squashing we can do that for you.

I'm not as comfortable with squashing, so I would appreciate if you could take care of that!

I'm not too familiar with squashing. Which commits need to be squashed, or is this something that can be done for me?

Done.

Thank you so much!

Just to make sure: as mentioned in the original issue it may be that one not always would like this. Is there a way to make the "main figure" transparent, but not the inset?

Should there be a release note for this? Some users may rely on the current behavior.

(In the long run one probably would like the inset to not show content from the main axes that happens to end up inside the inset area.)

@jklymak could you please clarify in more detail what changes need to be made? I am a bit confused on the functionality that needs to be added. Do we want users to be able to make the figure transparent but not the subfigure? Also a bit confused what you mean by "this gets reversed". Thank you so much!

Thetransparent kwarg should only affect the figure during printing. Once the printing context is left, the figure should revert to whatever state it was in before the print started. Here you are losing the original state and just changing the subfigure facecolor.

I updated the code, but I will need help with squashing the commit again.

@sramesh750 I fixed this by dropping your merge commit and then cherry-picking the new commit.

The issue is that when you updated locally Antony had squashed all of your commit into one which, despite having identical changes, git viewed as different from your local branch (which to be fair it is a different history!). Because there were some commits on github and some commits on your local system, when you added your last commit and tried to push GH helpfully said "I can not do that because the histories do not match! Try running this command to fix it:git merge ... " which in general is helpful and correct. However in this case it re-introduced the commits we were trying to get rid of into the history.

What you want to do to prevent this in the future is

git remote updategit remote -v   # to check the name of your remote for the next linegit reset --hard YOUR_REMOTE/my-feature

before you do any more work.

🤦🏻 I now see that this also has to be squashed...doing that too.

I feel like I keep moving the goal posts, but I think this will only work as expected for 1 level of sub-figures (that is sub-figure that have sub-figures that have axes that have insets will not behave as expected). I think we can fix that by pulling the loops out into a (locally defined) function that looks something like

def_recursively_make_transparent(exit_stack,subfig):exit_stack.enter_context(subfig, ....)foraxinsubfig.axes:        ...forsub_subfigissubfig.subfigs:_recursively_make_transparent(exit_stack,sub_subfig)

I'm fine with this going in as-is as an improvement and opening an issue for the more general case or having it done here if you are feeling up to it@sramesh750 !

@tacaswell I am unfortunately busy in the next few weeks, so for now I think it would be best to merge these improvements and open up a new issue for the more general case. If no one gets onto that new issue, I will definitely be interested in working on it as soon as I can!

@jklymak OK! Makes sense.

I was more thinking of the case where one puts an inset over a plotted line to illustrate e.g. a detail of the plot. Currently, one can simply rely on the transparent kwarg, but with this one need to change approach (although still doable).

Considering it is recent and this does not seem to be considered a problem, I will not argue against it. (One can also argue that the current PR is probably more "correct" than the earlier behavior.)

Just wanted to make sure that the potential drawback was considered.

@oscargus fair, I see both sides, but lean towards making all backgrounds transparent as it is a simpler rule (no special cases).

I'm a little confused about the status of this one...@anntzer you approved, but its not showing as approved, so not clear if you still have questions?

This still needs a bit of revision. Moving to draft until addressed...

@sramesh750 do you still plan to work on this? If not, one of the core devs or somebody else could take over.

Pushing this to 3.8

@sramesh750 do you plan to work on this? If not, I'd like to pick up this PR to finish the work.

@sramesh750 do you plan to work on this? If not, I'd like to pick up this PR to finish the work.

@chahak13 No, you can finish the work if you'd like

This has been replaced by#24816.