[Plugin] OpenDocHTMLImport - Full ODF HTML(Writer) conversion to epub

[DiapDealer]

Originally Posted by Doitsu

@slowsmile: Unless you have access to a Linux machine, you might want to remove Linux from the list of supported operating systems in plugin.xml.

I've done some testing for him on Linux, but I've not tried any of these specific scenarios.

[Doitsu]

@slowsmile: I believe that I've found cause of the Linux problem. Linux is case-sensitive and the actual file names and the manifest entries don't match. E.g., the epub contains Chapter_Three.xhtml, but the manifest lists chapter_three.xhtml.

I intercepted the temporary epub and attached it to this post. The epub contains:

Chapter_One.xhtml
Chapter_Three.xhtml
Chapter_Two.xhtml
title.xhtml
contents.xhtml
cover.xhtml

however the opf manifest lists:

    <item id="cover" href="Text/cover.xhtml" media-type="application/xhtml+xml" />
    <item id="contents" href="Text/contents.xhtml" media-type="application/xhtml+xml" />
    <item id="title" href="Text/title.xhtml" media-type="application/xhtml+xml" />
    <item id="body1" href="Text/chapter_one.xhtml" media-type="application/xhtml+xml" />
    <item id="body2" href="Text/chapter_two.xhtml" media-type="application/xhtml+xml" />
    <item id="body3" href="Text/chapter_three.xhtml" media-type="application/xhtml+xml" />

When you import the epub into Sigil with a plugin (or oṕen it directly) all files that can't be found will be silently skipped. To fix this issue, you'll have to make sure that the manifest entries exactly match the actual file names.

[slowsmile]

@Doitsu...Thanks for discovering the problem. I also have no access to Linux computers whatsoever so I really do appreciate your testing efforts.

I've checked the problem and you are right. I save the files in the zip archive as Chapter One, Chapter Two etc. But when I display them in the Book Browser they are converted to lower case including the manifest, spine and guide references in the opf file. I was also completely unaware that Linux file names are case sensitive. The other odd thing is that my plugin has been tested on Linux32 by DiapDealer and apparently works with no problems.

I will try and put in a fix as quickly as I can. The easiest way would seem to be to just revert all Sigil chapter and main heading refs to title case in Sigil. Once I think that I've fixed the problem and its OK on Windows, I will also need your help to test fix on Linux32/Linux64. I'll keep you informed on this thread or by private message if that's OK. My grateful thanks to you again for helping.

[slowsmile]

@st_albert...I'm hoping to be able to fix and test this problem within a day or so. Please keep an eye on this thread.

I would also gratefully appreciate your own test effort to confirm whether my eventual fix has solved your plugin problems or not since I have no access to any Linux computers for testing.

[st_albert]

Originally Posted by slowsmile

@st_albert...I'm hoping to be able to fix and test this problem within a day or so. Please keep an eye on this thread.

I would also gratefully appreciate your own test effort to confirm whether my eventual fix has solved your plugin problems or not since I have no access to any Linux computers for testing.

Sure, I'd be happy to test it, though my python-fu is only at the beginner's level.

One other thing I noticed, and it's related to LO's html output, not to your plugin at all, but maybe you know what's going on.

In the odt file I have defined custom character styles as well, such as "w2e_ttb-italicchar" which should be mapped to something like:

span.w2e_ttb-italicchar {
	font-style:italic;
}

however LO seems to replace them with <i></i> tags, and similarly with bold, etc. other spans for things like small caps, or drop caps simply get stripped out.

Is that the expected behavior, or is there some way to make it preserve character styles as well?

[slowsmile]

@st_albert...Unfortunately OO and LO always convert italics, bold and underline to <i>, <b> and <u> no matter how you format your text. So, as you say, this is expected behaviour from OO and LO. And unfortunately, I don't think you can do much to change that kind of formatting unless you're willing to dive under he hood to reformat all instances using html.

[slowsmile]

@Doitsu & @st_albert I've just released a new plugin version -- v0.2.9 -- with a fix for the Linux64 file name issue.

* The opf file names and Book Browser file names have been changed and are now identical and will be in the same letter case as the original headings in the ebook text.

* When the file split from html to xhtml occurs in my plugin, the created file names will now be identical in letter case format to the file names in the opf and in Sigil's Book Browser.

* I've tested this fix on Windows using 16 ebooks that are formatted differently in LO or OO and which also includes 2 Polish ebooks and st_albert's Galactic Frontiers ebook sample. In all cases, the opf and Book Browser file names were identical and correct and all generated epubs passed Doitsu's EpubCheck.

Please could you test this new version to see if it's now working properly on Linux64 ?

With thanks

[Doitsu]

Originally Posted by slowsmile

Please could you test this new version to see if it's now working properly on Linux64 ?

The new version appears to working fine on my Linux machine.

[slowsmile]

Thanks for that, Doitsu. I'm very relieved that problem is gone.

[st_albert]

Originally Posted by slowsmile

@Doitsu & @st_albert I've just released a new plugin version -- v0.2.9 -- with a fix for the Linux64 file name issue.
...
Please could you test this new version to see if it's now working properly on Linux64 ?

With thanks

Well, that was fast. The new version works fine on my kubuntu machine. It handled the full version of my test file, and the epub passed epubcheck and flightcrew "out of the box."

Great work!

Albert

[st_albert]

Originally Posted by slowsmile

@st_albert...Unfortunately OO and LO always convert italics, bold and underline to <i>, <b> and <u> no matter how you format your text. So, as you say, this is expected behaviour from OO and LO. And unfortunately, I don't think you can do much to change that kind of formatting unless you're willing to dive under he hood to reformat all instances using html.

I was guessing that would be the case. But once in Sigil, I could change them back with a little S&R slight of hand. And actually, LO seems to do a reasonably good job of preserving the intended appearance of the text, even if the use of <i> and <b> are frowned upon by purists, in favor of something more semantic.

Thanks for the info.
Albert

[slowsmile]

@st_albert...My grateful thanks for confirming that the plugin works on Linux.

I also had a re-think about your <i> <b> <u> question. You could certainly do it with S&R as you suggest. But it would also be very easy for me to change my plugin to to get rid of these <b> <i> and <u> tags and replace all of them with their <span> equivalents in the html file.

Here's a code example of how to do it using bs4

Spoiler:

html = BeautifulSoup('html_file_text', 'html.parser')

search_tags = ['i', 'b', 'u']
for tag in html.findAll(search_tags)
   if tag.name ='b':                     
       tag.name  = 'span'
       tag.span['style'] = 'font-weight: bold;'
    
   if tag.name = 'i':
       tag.name  = 'span'
       tag.span['style'] = 'font-style: italic;'
    
   if tag.name = 'u':
       tag.name  = 'span'
       tag.span['style'] = 'text-decoration: underline;'

[DiapDealer]

My TagMechanic plugin makes it pretty painless to safely switch all i, b tags to em, strong (or to spans). Same could be used to convert all u's to spans with specific class-names.

[st_albert]

Originally Posted by DiapDealer

My TagMechanic plugin makes it pretty painless to safely switch all i, b tags to em, strong (or to spans). Same could be used to convert all u's to spans with specific class-names.

That sounds like a reasonable solution to me.

Albert

[slowsmile]

I've just updated and added some new functionality to my plugin which includes the following options:

* Convert chapter text only to fiction style format
* Convert chapter text only to block text format
* Convert all ebook text to block text format.

Please read the release notes -- Re-Styling Options -- for more details.