Insert>Image from URL with fake extension uses correct filter.

[Lupp]

(Of course, I don’t complain about that fact.)

If I have an image file with a fake extension, say
bmp for a jpeg file needing the import filter JPEG - Joint Photographic Experts Group, and call Insert>Image for it, LibO uses the correct filter.

I would like to know the media type, and by that the needed filter in advance extracting the information directly from the file. As a recorded macro shows by the args() it creates, the process also does it in advance of calling the import command from the slot-machine.

How can I do so?

[mikekaganski]

Do you mean you are looking for a UNO function that would report you filter name decided for a given file URL, without actually opening the file? I’m afraid there’s none. The filter choice has no external API afaik.

[Lupp]

Quoting @mikekaganski: “Do you mean you are looking for a UNO function that would report you filter name decided for a given file URL, without actually opening the file?”
Yes. In fact there will be need to open the file for looking inside, but the actual import should remain pending.
Quoting @mikekaganski: “The filter choice has no external API…”
That’s bad. Is there an idea why?

[mikekaganski]

In fact there will be need to open the file for looking inside, but the actual import should remain pending

Of course; I meant user-visible result.

Is there an idea why?

Well - most probably because that was never needed. Why doing that? LO is not a general-purpose type detection library; its type-detection machinery is specifically created to choose filters; and that machinery is tailored for different kinds of invocations (no information is available; some user preference exist as a module name; as explicit filter name; do only cheap testing; do in-depth testing; limit to something because it’s called in some specific operation…); it’s subject to frequent changes - so what good would the API do except for making it “in stone”, so hard to change?

[Lupp]

Thanks a lot for letting me know your thoughts.
I had missed to do a few more tests before asking.
If I knew the facts stated in my answer, I hadn’t asked the question. Now I hope it may be helpful for someone else feeling mislead a bit by the args() created by the recorder in this case.
By the way: I had worked in advance on image import by a script without any use of the slot-machine. It was rather frustrating.

[Lupp]

There also is good news:

The command .uno:InsertGraphic also worked correctly in a case of fake extension if the filter not was sepcified in advance. It obviously was chosen during the execution of the uno command.

However, as so often, I don’t know any specification to the effect that I can trust in this behaviour.

The devil’s advocate I am cannot but add that the “good news” is bad news on a different level: The recorder is pretending the command could be forced to use a specified filter. This is not true. .uno:InsertGraphic chose the applicable filter even if I had specified "phantasy - Lupp" as the filter to use. I have no means to decide whether or not the slot machine even read the respective arg()…