Img tag URL is resolved even when data is provided

[yholkamp]

When including an image tag with the data supplied, a URL has to be provided per the README. Instead of including the data, Caracal will attempt to resolve the URL and fail, even though data was provided.
I've included a minimal example at https://github.com/yholkamp/caracal-example/tree/img-url-resolving-issue, where an image tag is included with a placeholder URL and the data provided.

The expected behavior based on the README would be that it should include the data, with the URL only used for internal purposes.

Is there a specific format that Caracal expects to be used instead of any placeholder?

[jdugan]

So, the short answer is I'm not sure. But my guess is if the image url points to URL that actually resolves, Word will prefer that content to the data content.

Assuming the example project itself runs as expected, the main difference is I see is that my code sets the first argument as a path whereas you have set a full path. Maybe try that and see if the library works as expected?

[yholkamp]

@jdugan ah I'm sorry, my description was actually insufficient. It's not that Word is resolving the URL but Caracal is doing so. When you run the example I've linked, it is the Rails app that throws the not found exception via the lookup performed by Caracal, as a result no .docx file is generated either.

This made me wonder if there is a specific placeholder URL format that should be used in order for Caracal to not try and resolve it.

[jdugan]

Honestly I'm so far removed from writing this library, I can't answer authoritatively anymore. But my hunch is if you switch to a path instead of a full uri when you supply a data string, it will do what you want.

[yholkamp]

@jdugan that was one of my earlier guesses as well but those result in a No such file or directory @ rb_sysopen - /logo.png, those are resolved too so I'm afraid that's no workaround either. With the different steps going on between definition and output I haven't spotted an obvious location where it should be deciding between retrieval and just inclusion of the provided data. Looking at the history of the repo I can image it's been a while for you too, thanks for your help in any case.

[jdugan]

If you run the example project unadulterated, do you get the same issue? Because that runs perfectly fine for me.

[yholkamp]

@jdugan it does but that's only because the path referenced here; https://github.com/urvin-compliance/caracal-example/blob/master/app/views/examples/show.docx.caracal#L23 actually exists. If you chance anything the path while leaving the read path in place on line 22, you get the error I included in my example, even though I'd expect it to continue to function because the data was also provided.

[jdugan]

Ah, okay. Thanks for your patience. Yes, this is a bug, then. It is suppose to prefer the data attribute's contents. So, if you provide any data at all, it should ignore the url entirely. That's how I interpret the render_media method that is throwing the error...and that rings a bell in my memory.

So, what you can do is also clone Caracal and then change the gem file of the caracal-example project to include caracal from your file system via a :path setting. After you re-bundle and start the puma, you should be able to add debugging to caracal to see what's happening inside its methods.