Dictionary: fix missing images

[TnS-hun]

Pass the directory that contains the dictionary's ifo file to Mupdf.openDocumentFromText to allow MuPDF to display images referenced by HTML dictionaries.

Depends on: koreader/koreader-base#2002
Fixes: #12628

---

This change is 

[TnS-hun]

I was not sure to which directory to use: the current working directory or the directory that contains the dictionary's ifo file. I went with the latter.

With the former all dictionaries need a custom lua file to rewrite the resource paths. Based on the sample in the bug report this was the original behavior.

With the latter dictionaries can simply use res/image.jpg to resolve the images, so it is easier for the users. The only downside of this method that it does not allow combining entries from different dictionaries, but because the dictionaries are always displayed separately, I don't think this is a problem.

What do you think?

[Frenzie]

I'm not sure I entirely follow what you're saying. Relative directories and absolute directories are no longer functional at all?

[TnS-hun]

I'm not sure I entirely follow what you're saying. Relative directories and absolute directories are no longer functional at all?

Images with absolute paths won't resolve in dictionaries. After this change paths must be relative to the dictionary's directory (that contains the ifo file).

But why would be absolute paths in the dictionaries?

I can change the code to use the current directory as the base directory, to not break existing custom lua dictionary scripts. But I think paths that are relative to the dictionary's directory are more logical.

[Frenzie]

After this change paths must be relative to the dictionary's directory (that contains the ifo file).

Is that the correct behavior? Shouldn't it be relative to the dictionary's res folder?

But why would be absolute paths in the dictionaries?

This is HtmlBoxWidget we're talking about, dictionary is merely something using it. :-) But as per koreader/koreader-base#2002 (comment) the old behavior is available simply by not passing anything in html_resource_directory.

Nonetheless there's still a very simple answer to the question as written: to keep the gigantic res folder with gigabytes of images on the SD card rather than internal storage.

If you feel motivated you could add an optional html_resource_directory argument to the customization function, along the lines of local ok, fixed_definition, fixed_html_resource_directory = pcall(ifo.fix_html_func, result.definition, dict_path). But then again the user simply updating to ../../../../etc will also do the trick.

[TnS-hun]

Is that the correct behavior? Shouldn't it be relative to the dictionary's res folder?

You are right, the res is the correct base directory.

This is HtmlBoxWidget we're talking about, dictionary is merely something using it. :-) But as per koreader/koreader-base#2002 (comment) the old behavior is available simply by not passing anything in html_resource_directory.

Unfortunately, no. The fz_read_archive_entry function will not resolve any images if there is no archive handler specified.

I think MuPDF supports custom archive handlers , so we could make one that handles absolute paths if that is needed.

[Frenzie]

You can turn any absolute path into a relative path so it's probably not the biggest deal, but I would expect to be able to use either one at will from a standalone HTML file or string/stream, just like how it worked previously. In any case it's not important here unless you want it to be. ^_^

[TnS-hun]

I made the requested changes. Paths are now relative to the res directory (Nice catch! I did not know that the res directory was a standard in StarDicts.), and ReaderDictionary stores the res directory's path instead of the ifo file's path (It is indeed clearer this way. Thanks benoit-pierre!).