New Epub from ODT Not Opened When Created

[retiredbiker]

Here is a funny one. Since building 6.7.2, if I use the ODTImport plugin, I get a failure message. But it doesn't really fail, it creates the epub in the directory where the odt file is, but doesn't open it automatically. I can see nothing wrong with the created file, it is just the handling that is strange. I know I'm not on a standard build, so might this just be a transitory thing?
Here is the message, and a shot of where the file lands:

(It chokes a little on the "5.18" in the file name in this example, but that is not the problem, other files work exactly the same.) (Running Pop_OS Linux).

[KevinH]

Very strange, only the status indicates something failed. That happens when there is a non-zero return code from the plugin.py run routine or the subprocess that invokes it.

I would have to look at the plugin's code to know.

Have you thought about using our official Sigil AppImage and tryingthe same thing to rule out some issues with your build?

Could your java/jre/jdk setup be broken somehow?

[Doitsu]

I was able to reproduce the problem. It's caused by the period in the file name.
I'll try to upload a fixed version today.

Update: The plugin assumes that writer2xhtml will create an output file with the base name without an extension and .epub.

However, writer2xhtml uses this code to remove the extension:

    public static final String getFileExtension(String sURL) {
    	String sFileName = getFileName(sURL);
    	int nDot = sFileName.lastIndexOf('.');
    	if (nDot>=0) {
    		return sFileName.substring(nDot);
    	}
    	else {
    		return "";
    	}
    }

    public static final String removeExtension(String sURL) {
    	String sExt = getFileExtension(sURL);
    	return sURL.substring(0, sURL.length()-sExt.length());
    }

I don't know Java, but the code apparently generates the output file name demo 1.epub if the input file name is demo 1.4.odt instead of demo 1.4.epub. Since the plugin can't find demo 1.4.epub it assumes that the conversion has failed and returns -1.

[KevinH]

That is very strange. The lastIndexOf('.') routine should return the string position of the last "." in the string.

The **lastIndexOf()** method in Java's String class is used to find the index of the last (rightmost) occurrence of a specified character or substring within a given string. The search starts from the end of the string and proceeds backward, but the returned index is still zero-based from the beginning of the string.

So if "demo 1.4.odt" is passed in the getFileExtension routine should return the substring ".odt" and the removeExtension routine should return the original string short the last 4 ".odt" characters. which should be what you want.

How on earth does the lastIndexOf('.') find and return the first '.'?

Great detective work! But something else may be up. It is as-if like they ran it through that routine twice or in a loop and so it first hacked off the ".odt" and then hacked off the ".4" as using this routine just once should do exactly what you would want.

Perhaps they invoke that string in a loop? Or maybe that there are multiple threads that somehow invoke it twice?

[KevinH]

If I go to the github writer2xhtml site you linked and search for use of removeExtension it appears to be defined in Misc.java (your link) but invoked in both EPUBWriter.java and in Application.java (and there is one use in the UNO routine as well) so it will remove up to two extensions if 2 extensions are provided as the target on the cli interface.

So I do not know if this behaviour is planned or just an accident of using the Application command line interface. Or if this happens in the UNO interface or ...

In general, I am not a fan of using multiple "." and spaces in a file name if you want it to be supported cross platform but if that is what the github writer2xhtml seems to be doing. But I have not written java code in over two decades so I only scanned the code.

[DiapDealer]

Does writer2xhtml ever output anything other than the file the Sigil plugin needs to process (or nothing)? Just wondering if the process of opening writer2xhtml's output could be done in a more generic way that's not looking for a specific epub name.

[Doitsu]

Originally Posted by DiapDealer

Does writer2xhtml ever output anything other than the file the Sigil plugin needs to process (or nothing)? Just wondering if the process of opening writer2xhtml's output could be done in a more generic way that's not looking for a specific epub name.

The plugin basically just runs writer2xhtml and adds it to Sigil as a new epub via the default input plugin code. (Plugin users can also add additional files via plugin preference settings.)

The original plugin code was:

        epub_path = os.path.splitext(odt_file)[0] + '.epub'

(odt_file is the full .odt file path)

The current working version is:

        # handle file names with additional periods correctly
        base = os.path.basename(odt_file)

        # workaround for writer2latex file name bug
        stem = base[:-4]  # remove ".odt"
        name_without_ext = stem

        # check for file name with periods
        if '.' in stem:
            name_without_ext = stem.rsplit('.', 1)[0]

        epub_filename = name_without_ext + '.epub'

        # assemble epub path
        epub_path = os.path.join(os.path.dirname(odt_file), epub_filename)

The new code appears to be working, but I still don't understand why writer2latex apparently has problems with additional periods in file names.

[KevinH]

Originally Posted by Doitsu

The new code appears to be working, but I still don't understand why writer2latex apparently has problems with additional periods in file names.

See my earlier post. The Application.java is invoked first and it calls removeExtension to create the target name from the source file name if none is provided on the command line. Then it invokes the Converter which since the target mime is an epub invokes EpubWriter.java which again calls removeExtension. This hacks off the second "extension".

The epub converter is the only mimetype converter that hacks off the second extension if one exists that I could find.

One way to workaround this issue that might work is according to Application.java, you can pass the full path/name of the target file immediately after the source file in the command line.

        System.out.println();
        System.out.println("Usage:");
        System.out.println("   java -jar <path>/writer2xhtml.jar <options> <source file/directory> [<target file/directory>]");
        System.out.println("where the available options are:");
        System.out.println("   -xhtml");
        System.out.println("   -xhtml11");
        System.out.println("   -xhtml+mathml");
        System.out.println("   -html5");
        System.out.println("   -epub");
        System.out.println("   -epub3");
        System.out.println("   -template[=]<template file>");
        System.out.println("   -stylesheet[=]<style sheet file>");
        System.out.println("   -resource[=]<resource file>[::<media type>]");
        System.out.println("   -cleanxhtml");
        System.out.println("   -config[=]<configuration file>");
        System.out.println("   -<configuration option>[=]<value>");
        System.out.println("See the documentation for the available configuration options");

If you pass in that target full path on the command line, then Application.java will not remove the extension which will get passed to EpubWriter where the ".epub" extension will be removed and a new ".epub" should be added.

[KevinH]

So hopefully the following change is a bit simpler and should make things work too (but I have not tested this). It just adds the desired output epub path/name as the final argument to the jar.

    # process ODT file                                                                                                          
    if odt_file:

        # assemble w2l command line                                                                                             
        args = ['java', '-jar', w2l_path, '-' + output_format]
        if os.path.isfile(w2l_config_path):
            args.append('-config=' + w2l_config_path)
        if os.path.isfile(w2l_css_path):
            args.append('-stylesheet=' + w2l_css_path)
        args.append(odt_file)
        epub_path = os.path.splitext(odt_file)[0] + '.epub'
        args.append(epub_path)

        # run w2l                                                                                                               
	result = w2lWrapper(*args)

[Doitsu]

Originally Posted by KevinH

So hopefully the following change is a bit simpler and should make things work too (but I have not tested this). It just adds the desired output epub path/name as the final argument to the jar.

    # process ODT file                                                                                                          
    if odt_file:

        # assemble w2l command line                                                                                             
        args = ['java', '-jar', w2l_path, '-' + output_format]
        if os.path.isfile(w2l_config_path):
            args.append('-config=' + w2l_config_path)
        if os.path.isfile(w2l_css_path):
            args.append('-stylesheet=' + w2l_css_path)
        args.append(odt_file)
        epub_path = os.path.splitext(odt_file)[0] + '.epub'
        args.append(epub_path)

        # run w2l                                                                                                               
	result = w2lWrapper(*args)

Thanks for the code!!!
I've just tested it and it works fine.

Since the current version is looking for custom user files only in the plugin folder, I'll try to update the plugin to also look in the preferences folder for these files.

[Doitsu]

@retiredbiker I attached a new plugin version to the first post in the [Plugin] ODTImport thread. You should no longer get any Failed error messages with this version.

I also changed the plugin behavior so that it copies two configuration files (config.xml and epub.css) from the plugin preferences folder to the plugin folder. I.e., you can now uninstall and re-install the plugin without losing your customized configuration files as long as you save them in the plugin preferences folder.

If you want to test the new version and have customized config.xml and/or epub.css make sure to copy them from the plugin folder to the plugin preferences folder.

Pretty much everyone else can skip this update, because it doesn't offer any new features.

[philja]

Originally Posted by Doitsu

I also changed the plugin behavior so that it copies two configuration files (config.xml and epub.css) from the plugin preferences folder to the plugin folder. I.e., you can now uninstall and re-install the plugin without losing your customized configuration files as long as you save them in the plugin preferences folder.

If you want to test the new version and have customized config.xml and/or epub.css make sure to copy them from the plugin folder to the plugin preferences folder.

Pretty much everyone else can skip this update, because it doesn't offer any new features.

That's great news, Doitsu. Last time I updated the plugin, I forgot to make a backup of my config.xml file which was highly customised, and I had to re-invent it all again.

[retiredbiker]

Originally Posted by Doitsu

@retiredbiker I attached a new plugin version to the first post in the [Plugin] ODTImport thread. You should no longer get any Failed error messages with this version.

I also changed the plugin behavior so that it copies two configuration files (config.xml and epub.css) from the plugin preferences folder to the plugin folder. I.e., you can now uninstall and re-install the plugin without losing your customized configuration files as long as you save them in the plugin preferences folder.

If you want to test the new version and have customized config.xml and/or epub.css make sure to copy them from the plugin folder to the plugin preferences folder.

Pretty much everyone else can skip this update, because it doesn't offer any new features.

Thanks all for your responses and efforts!

So I got the new version and did the config/css copies, and tried it from both my 6.7.2 build and also from the latest 6.7.0 appimage. The result is the same for both versions. I still get an error message, different now, although the epub name is correct as saved in the source folder:
Any other info I can provide?

[KevinH]

I think it needs the line:

resource_files = None

someplace *before* the conditional "if" that creates it so that this variable is in outer scope to be available in later conditional "if" statements.

[Doitsu]

Originally Posted by retiredbiker

The result is the same for both versions. I still get an error message, different now, although the epub name is correct as saved in the source folder:
Any other info I can provide?

KevinH was right, the plugin was missing a line.
The new version should finally work.