epubcheck plugin for Sigil

[Chang]

Originally Posted by Doitsu

I've updated the plugin again and attached the latest version.

Thank you a lot! Seems to be working like a charm

[byword]

Hi~

I found that the below error occurs in a folder where the user name is Korean. I tested Windows 10 and 11.

Status: failed
Running EPUBCheck 5.1.0... please wait.
An exception of type UnicodeDecodeError occurred.

For example, an error occurs in a folder written in Korean as shown below.

C:\Users\한국어\AppData\Local\sigil-ebook\sigil\plugins\EpubCheck

It is thought that similar errors will occur not only in Korean but also in other foreign languages.

Please check to see if this problem can be resolved.

I am always grateful for your efforts.
Thanks.

[Doitsu]

Originally Posted by byword

I found that the below error occurs in a folder where the user name is Korean. I tested Windows 10 and 11.

I'll try to fix this in the next version, but this will take a couple of weeks.

In the meantime please try the following:

Locate the following lines in plugin.py:

        stdout = result[0].decode("utf-8")
        stderr = result[1].decode("utf-8")

and change them to:

        stdout = result[0].decode("utf-8", "ignore")
        stderr = result[1].decode("utf-8", "ignore")

If you can't get it to work, download Pagina Epubchecker.

[Astroman]

I'm nearing the end of my first big e-book project, so I thought it would be a good idea to use the EpubCheck plugin. When running it, I get the same error message every time.

I followed the installation instructions in the first post, made sure I had Python (version 2.7.16), and downloaded Java (version 8 update 421) from Oracle's website and successfully installed it on my old MacBook Air running macOS Catalina. Adding the EpubCheck plugin (version 0.4.7.1) to Sigil was a very quick and easy process.

When running EpubCheck, I get the following output (see below) with an error message at the end ("Error: Expecting value: line 1 column 1 (char 0)") plus a pop-up window saying "To use the java command-line tool you need to install a JDK".

The instructions do not mention anything about installing other software packages except Java. Does the error message mean that I also need to install a JDK? If so, are there several so-called JDKs to choose from?

Output from EpubCheck:

Running EPUBCheck 5.1.0... please wait.
Traceback (most recent call last):
  File "/Applications/Sigil.app/Contents/plugin_launchers/python/launcher.py", line 142, in launch
    self.exitcode = target_script.run(container)
  File "/Users/jan-erik/Library/Application Support/sigil-ebook/sigil/plugins/EpubCheck/plugin.py", line 557, in run
    parsed_json = json.loads(stdout)
  File "json/__init__.py", line 346, in loads
  File "json/decoder.py", line 337, in decode
  File "json/decoder.py", line 355, in raw_decode
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
Error: Expecting value: line 1 column 1 (char 0)

[KevinH]

I have no idea if this is related or not but Python version 2.7.16 is very very out of date.

Python moved to Python 3 (now at Python 3.9 or higher) almost exclusively and Sigil followed. So when running epubcheck, you should be using Sigil's built in Python (ie. check the box to use Sigil's internal Python on macOS). And yes a Java virtual machine is needed. At least the JRE, but on macOS I strongly recommend the full JDK as it is the only one that properly sets the proper path for you.

[Doitsu]

Originally Posted by Astroman

When running EpubCheck, I get the following output (see below) with an error message at the end ("Error: Expecting value: line 1 column 1 (char 0)") plus a pop-up window saying [/I].

The plugin runs EPUBCheck in JSON mode. If you got this message, either no JSON file was generated at all or the JSON file was invalid, which is relatively rare. You also might want to use the Python 3 interpreter that comes with Sigil.
(I only mentioned Python 2, because some Sigil users are still using very old Sigil versions.)

Originally Posted by Astroman

plus a pop-up window saying "To use the java command-line tool you need to install a JDK".

That is a macOS error message. It looks like you'll have to install a JDK.

[Astroman]

Thanks for the info! Yes, I'm using Sigil's built-in Python. I installed JDK as well, and got EpubCheck working … although I'm not sure it's working 100%.

I have yet to add images to my EPUB (version 3), but the text is 99% finished. I was quite happy to see that EpubCheck only had one type of complaint:

"Col: 10: ERROR(RSC-005): Error while parsing file: Element "title" must not be empty."

This exact line was repeated 25 times, i.e. the same error in 25 different chapters/xhtml files. The reason is the empty title tag, i.e. <title></title>, in the <head> element at the beginning of each file.

I have two questions:

1) I only use the h1 tag for chapter titles. I read a lot of guides and tips before I started producing this EPUB, and I've never read anything about the title tag. I have searched on Google, but I can't find any relevant information (except for the "title" that refers to the title of the book, which is added to the metadata).

What is the title tag for? EpubCheck lists these errors in red colour, so I assume it's serious and must be fixed.

I checked the Sigil User Guide, and often the title tag contains the same text as the h1 or h2 heading, but sometimes it's completely different. E.g. the chapter called "External Editors" has "Files" in the title tag. I'm confused.

PS: I have added my book's title to the metadata using the Metadata Editor, but I assume the book's title is not related to the title tag that appears near the top of every single chapter/xhtml file?

2) EpubCheck lists the above-mentioned error only for 25 chapters. However, all of my approximately 80 chapters have empty title tags.

Why is EpubCheck only reporting this error for less than 1/3 of the chapters?

PS: There is one file that has something written in the title tag: the file nav.xhtml has "ePub NAV" in the title, which I believe is something Sigil inserts automatically.

[KevinH]

Title tags in head are not seen be normal viewers of your epub. That said, when people are blind or have vision issues, they often use Accessibility software to help them navigate the page. This Accessibility software does use these title tags to help identify where in the book they are.

I personally fill them in with the Chapter title or short chapter description.

[Doitsu]

Originally Posted by Astroman

This exact line was repeated 25 times, i.e. the same error in 25 different chapters/xhtml files. The reason is the empty title tag, i.e. <title></title>, in the <head> element at the beginning of 2) EpubCheck lists the above-mentioned error only for 25 chapters. However, all of my approximately 80 chapters have empty title tags.

Why is EpubCheck only reporting this error for less than 1/3 of the chapters?

That's a limitation of the JSON output code. It'll only report the first 25 occurrences of frequently occurring problems.
I don't know why the EPUBCheck devs decided to implement this "feature."

[Astroman]

Thank you, KevinH and Doitsu, for your quick and helpful replies!

[philja]

In the thread about Sigil's error messages, I said I was surprised that a single mismatched quote in a class identifier caused the EpubCheck plugin to record numerous errors related to "unidentified fragments" in the HTML Contents and the NCX files. Errors which vanished once the original mismatched quote was corrected. BeckyEbook explained this in a reply:
https://www.mobileread.com/forums/sh...9&postcount=19.

I recently saw another example where an accidentally erased '<' at the end of an early paragraph in one of the files caused EpubCheck to produce 26 error statements for that file, none of which was the actual error.

If the plugin identifies an error in a chapter, the user has to rerun the plugin after correcting the error so the validation process is always likely to involve several iterations of the use of epubcheck.

To avoid the listing of numerous non-errors, would it be possible for the plugin to log the first error and then exit that file and progress to the next file?

Just a thought from a comparatively non-techie user.

[KevinH]

Actually FWIW, I like it the way it works now... just like a compiler reports every error, even though some are ripples caused by the first. Fixing the first and lookng at the second and so on. In the cases where multiple independent erros exist, this is much faster.

[Doitsu]

Originally Posted by philja

To avoid the listing of numerous non-errors, would it be possible for the plugin to log the first error and then exit that file and progress to the next file?

Unfortunately, this can't be easily done. All the plugin does is generate a temporary EPUB file, verify it using EPUBCheck, and then reformat the JSON output from EPUBCheck for display in the Validation Results window.

[philja]

Originally Posted by KevinH

Actually FWIW, I like it the way it works now... just like a compiler reports every error, even though some are ripples caused by the first. Fixing the first and looking at the second and so on. In the cases where multiple independent errors exist, this is much faster.

I understand your point of view. But, one could spend a lot of time trying to understand what is wrong with the 'non-errors' without fixing anything because they were not the problem.

Originally Posted by Doitsu

Unfortunately, this can't be easily done. All the plugin does is generate a temporary EPUB file, verify it using EPUBCheck, and then reformat the JSON output from EPUBCheck for display in the Validation Results window.

.

Sad - but there you go, life's like that. It was just an idea.

[st_albert]

Well, forgive an old man for intruding into this thread, but man o man! does this remind me of my early days of programming Algol on a B5500, where we ran informal contests to see who could generate the most compiler error messages with a single typo. (hint: try omitting the final ";" on a statement, or the "end;" of a "for" loop).

Turns out it was good practice for detecting such errors in the wild. You had to think like the compiler when it was parsing the statements to see where it jumped the rails.

Albert