Just FYI, ä

[travger]

This may be fixed in newer versions, but I then maybe it's been well hidden.

I had an test epub that was made with old, much simpler version (0.4...) of Sigil. When I opened it in 0.5.907, there was no html file. (Other books were fine.) So I changed the name of the not showing html, deleted the part containing 'ä' - and now Sigil found it. Put ä back in Sigil, now there's no problems.

Just thought that I should mention it, as most people don't use ü & ö and this could go unnoticed for quite a while.

[Man Eating Duck]

Originally Posted by travger

Just thought that I should mention it, as most people don't use ü & ö and this could go unnoticed for quite a while.

Generally I would advise people to never use characters outside of English a-z (or spaces for that matter) in internal filenames. While all software should be using Unicode by now, a lot of it is English-centric so that errors with different charsets never show up in testing by the author(s). These bugs can be hard to track down.

On a side note I can mention that calibre still uses backslashes in links when converting an epub to zip (which generates an otherwise very nice set of html files of your book), but only on Windows. Needless to say this is also a Bad Idea

[user_none]

Originally Posted by travger

I had an test epub that was made with old, much simpler version (0.4...) of Sigil. When I opened it in 0.5.907, there was no html file. (Other books were fine.) So I changed the name of the not showing html, deleted the part containing 'ä' - and now Sigil found it. Put ä back in Sigil, now there's no problems.

The html file within the archive had 'ä' as part of the filename?

That beta had known issues with unicode characters as part of the filename. It was a beta and is no longer distributed. Try 0.7.0 and see if the problem persists. If it does then that is a bug that need to be fixed.

[travger]

Sorry, can't do it again. I have no more 4.xx installed. 5.9 and 7.0 have no problems seeing html-s that were renamed by the other.

Yes, html file within the archive had 'ä' as part of the filename. I deleted that part outside Sigil.

Just thought that there may be some several years old epubs out there where unsuspecting people may lose access to the html in Sigil and think that epub is damaged.

[Tex2002ans]

Here is an example of a massive EPUB I created this EPUB in Sigil 0.5.3 with unicode filenames:

http://www.mediafire.com/?9v891dfcbw9i87z

(Yes, yes, I know the EPUB is a huge mess and is not exactly fully EPUB compliant, these were a huge WIP that I put on hold to continue other work).

Sigil 0.5.3 allowed me to save/open/rename files with unicode characters perfectly fine (and if I recall correctly, FlightCrew said nothing about potential filename errors). I imported them into Sigil 0.5.3 using the typical Add Existing File dialog.

My Nook is able to read these EPUBs fine, even the articles with unicode in the filenames.

These HTML files were all auto generated from a website using the "ArticleNumber_Author_ArticleTitle.html" format. Here is an example of one file name:

3251_Juan.Ramón.Rallo.Julián_Economic.Crisis.and.Paradigm.Shift.html

When running the EPUB through EPUBCheck 3.0, you get this output:

File name contains non-ascii characters: óá. Consider changing filename

Now, when opened in Sigil 0.7.0 (and I believe 0.6.0+), the unicode files do not appear in the Book Browser, and if the FlightCrew check is done, it gives this error:

The <item> element's "href" attribute points to file "Text/x3251_Juan.Ram%C3%B3n.Rallo.Juli%C3%A1n_Economic.Crisis.and.Paradigm.Shift.html" which does not exist.

Perhaps there should be some way to gracefully handle Unicode filenames instead of making them disappear completely?

[user_none]

Originally Posted by Tex2002ans

Here is an example of a massive EPUB I created this EPUB in Sigil 0.5.3 with unicode filenames:

...

Sigil 0.5.3 allowed me to save/open/rename files with unicode characters perfectly fine (and if I recall correctly, FlightCrew said nothing about potential filename errors). I imported them into Sigil 0.5.3 using the typical Add Existing File dialog.

My Nook is able to read these EPUBs fine, even the articles with unicode in the filenames.

Later version of Sigil are more strict about the EPUB 2 spec. The file you've attached is invalid. The filenames in the archive must be utf-8 encoded according to the spec and Sigil tries to decode the filenames using utf-8. The filenames in this file are _not_ utf-8 encoded.

So what's happening is Sigil is getting the list of files from the OPF and they don't match what it gets from the archive. So Sigil thinks the file does not exist.

Some EPUB readers are more relaxed and don't really care about the filename encoding. These will either ignore utf-8 encoding and use the standard ZIP encoding or they will check if the utf-8 bit is set and only use utf-8 in that case. I've made a change to Sigil for 0.7.1 to check the utf-8 bit and use the standard ZIP filename encoding if it's not set instead. With this change the example file opens properly.

Originally Posted by Tex2002ans

When running the EPUB through EPUBCheck 3.0, you get this output:

File name contains non-ascii characters: óá. Consider changing filename

This recommendation is because of this very situation. These characters must be decoded properly otherwise they won't match what's in the OPF. A reading system can either A) follow the spec and expect the defined encoding. B) See what the archive has set as the encoding. With A we get into this situation. With B, well this assumes the encoding was marked properly. Either way you're going to run into this situation using non-ascii characters.

[Tex2002ans]

Originally Posted by user_none

I've made a change to Sigil for 0.7.1 to check the utf-8 bit and use the standard ZIP filename encoding if it's not set instead. With this change the example file opens properly.

Great to hear.

[travger]

Thanks, wonderful!