It looks like the tests fail because the function calls now take a new form for the additional parameters. This is whole point of patch, rather than a bug. I'm not sure how to update the tests to comply with the API change.

@scanny, is this still something you or someone else is working on? I'm happy to add this functionality as you described (or at least give it a go). I'm also needing this functionality, but would need some guidance on how to contribute.

Hi @fsolleza - The best place to start with new features is getting a clear statement of the behavior and scope so we can agree on the API to be added. Once added, changes to the API are very disruptive, so this is a place where trial-and-error doesn't produce good results. The implementation itself is much more forgiving in that regard.

The enhancement proposal documents are in docs/dev/analysis/features/. You can browse the ones that are there to find a good model. You'll see the key parts repeating across those pages. We need a description of the feature, an example exercising the proposed API (this is the protocol), specimen XML showing how the setting appears in the XML, the relevant XML Schema definitions, and a few other odds and ends.

If you want to take a crack at that I'll be happy to review and provide feedback. A completed page of this type will get merged immediately and does not require an accompanying implementation. In fact, it's usually better not to jump the gun on the implementation as that usually leads to quite a bit of rework.

@scanny thanks! I will take a crack at it but I'd have to familiarize myself with a bunch of things at the outset. I'll keep you updated. Should I make a pull request for the the enhancement proposal document for this particular feature once I think I've got a good working draft? Meanwhile, I did make a pull request #317 for my initial attempt at modifying the code but I'm guessing you should ignore it for now.

Yes, a PR is how you do it. First you create a branch on your fork, let's call it 'feature/imgtitle'. Then you create the PR from that branch. Subsequent commits you add to the branch then appear in the same PR when you push new commits. So it acts as a spot for the whole step-by-step process.

Probably best to close that one and open a new one using the branch I mentioned. Things get messy if you submit changes on the master branch of your fork.