FlightCrew versus ePubCheck

[AlexBell]

This post deals with the standalone version of FlightCrew, and outlines a serious problem that FlightCrew didn't find but ePubCheck did.

In the past I used ePubCheck routinely, but now I use FlightCrew routinely with a final check with ePubCheck.

When finishing an ebook recently I added the XHTML files for several chapters to the ePub package, and edited the toc.ncx file to match. I copied and pasted several nav points which were already there, but though I changed the text headings and the src entries I forgot to change the Navpoint id numbers.

When I checked the ePub package with FlightCrew it passed it with no errors reported. When I checked the same package with ePubCheck it failed the file and indicated that there were duplicate identifiers. After editing the toc.ncx file the ePub was passed both by FlightCrew and ePubCheck.

If I hadn't done the final check with ePubCheck I would have sent off to the publisher a defective ebook in which the TOC of contents didn't work.

I'm afraid I don't know what version of FlightCrew I use, nor how to find out, nor (now that I think of it) whether I have the most up to date version.

[mrmikel]

It is not easy at all to find the version. If you are running windows, you can use Windows explorer to find the Program Files\FlightCrew folder. In the folder is a file Changelog.txt. You should be able to double-click on it to open it and firs listed in the file is the version on your computer. 0.7.2 is the latest version at http://code.google.com/p/flightcrew/downloads/list.

The following is a list of all the changes documented in that file.

FlightCrew v0.7.2 2011.08.15
- Use Inno for Windows installer.
- Add version display to GUI and CLI.
- Fix Sigil issue #813: erroneous Resource is reachable but not present in OPF detection.
- OS X minimum version bumped to 10.6.
- made the CSS resource use detection far more robust
- fixed an issue with CSS @import rules in the '@import "something.css"' format not being
recognized
- fixed an issue with links to fonts in commented-out CSS producing "not in manifest" errors
(issue #15)
- fixed an issue with "background" and "background-image" CSS rules that referenced images
having those same images marked as unreachable files (issue #21)
- fixed an issue with "src" declarations in @font-face rules that have a space before the colon
throwing error messages about unreachable files (issue #21)
- clarified what "reachable" means in the error messages

FlightCrew v0.7.1 2010.11.11.
- added an automatic update checker to the GUI app
- the GUI now displays a "No problems found" message when the epub passes all checks
(issue #9)
- fixed an issue with missing XHTML files causing the GUI to show a dialog about an
std::exception and the CLI to report that the epub itself was not present (issue #8)
- fixed an issue that was causing empty error messages for incorrect uses of XML encodings
(issue #5)
- fixed an issue with anchor links to the current file (links with fragments only)
incorrectly throwing errors in the reachability analysis (issue #3)

[eping]

I wonder how FlightCrew follows the step of ePubcheck?
Since the committee can change what to check and what no to check at their will.
Some ePubs passed ePubcheck 1.2 now can,t pass epubcheck3. So now valid ePub may be invalid for next ePubcheck...

[AlexBell]

Thanks so much MrMikel - I had 7.0, and now have 7.2

[ibu]

I compared the validation results of the internal validation of Sigil 0.7.3 (no extra plugin installed) and the stand alone validator epubcheck 3.0.1.

Epubcheck finds several errors in the OPF file, which Sigil didn't find.

I'm not at all experienced in validation.
Is it true, that Epubcheck is more reliable than Flightcrew?

If so: Is there a way to integrate epubcheck into Sigil? Or is that planned for the future?

[mrmikel]

Epubcheck finds more that Flightcrew. Flightcrew is a more basic check.

Epubcheck uses Java, Sigil is written in one of the versions of C, so integration can not be easily done.

Most people run Flightcrew while they are working on their document and then run epubcheck at the end when nearly finished.

[ibu]

@mrmikel
Thanks for the hints.
Is there (on Windows) a comfortable way to "send" the epub, which is active in Sigil, directly to ePubChecker?

[mrmikel]

epubcheck requires a file to operate, so it would not work on an unsaved version in Sigil.

This might make it difficult to automate. There are two versions, one online and the other a version which works on your own computer. The computer version requires the installation of Java, which poses too much of a security risk for some people to be comfortable with (including me.)

Since epubcheck is used at the end of the epub creation process, there really isn't a big need to have it integrated, IMO. Flightcrew and the cleaning process will do for the vast bulk of problems including everything that would make it invalid.

The main difference I have personally noticed with what I do is that epubcheck makes sure all the references to anchors and links are valid. This Flightcrew does not do.

[ibu]

Originally Posted by mrmikel

epubcheck requires a file to operate, so it would not work on an unsaved version in Sigil.

Yes, that's what I meant: sending a saved file.

Originally Posted by mrmikel

[Flightcrew]
The main difference I have personally noticed with what I do is that epubcheck makes sure all the references to anchors and links are valid. This Flightcrew does not do.

I noticed several errors in the opf file, which Flightcrew cannot detect.
Entries e.g. inside SPINE or GUIDE which are not allowed.

Thanks for your hints. It seems that that an integration in the near future is implausible.

[roger64]

Originally Posted by ibu

@mrmikel
Thanks for the hints.
Is there (on Windows) a comfortable way to "send" the epub, which is active in Sigil, directly to ePubChecker?

With Linux, I use a bash script to launch Epubcheck with a right-click. The result of the check is a plain text file, containing either "No error" or the text of the errors. There is no need for a G.U.I.

#!/bin/bash

# dependencies: zenity, j.r.e.

#Write here where is located your version of epubcheck on your comp:

REPERTOIRE_SOURCE="/home/roger/Téléchargements/Non_installés/epubcheck-3.0.1/"

name=$(zenity --entry --title "Nom EPUB" --text "Nom de votre EPUB" --entry-text=Nom?)
echo "name=$name"

java -jar "$REPERTOIRE_SOURCE"epubcheck-3.0.1.jar "${name}".epub &>"${name}".txt

echo "Terminé"
zenity --info --text "Terminé"

[DaleDe]

When Flight crew first came out it was way ahead of epubcheck and gave much clearer messages. I think it is starting to get a bit long on the tooth these days.

Dale

[mrmikel]

I agree about it being a bit behind the times. My problem with it is more often it does not point to the beginning of the issue, but to the end. It seems that epubcheck does this a little better, but the messages are still not so easy to understand.

[theducks]

The other advantage to flightcrew is many time clicking the message takes you to the error line

I don't understand why 'The ... is referenced" can't take you to the first place that referenced it instead of a n/a . It 'found the reference' in the first place.

[Notjohn]

Originally Posted by mrmikel

The main difference I have personally noticed with what I do is that epubcheck makes sure all the references to anchors and links are valid. This Flightcrew does not do.

My experience also. Most of the time (all of the time?) the error is a blank or empty href link. I have no idea where these come from, but they have turned up in several of my books. Flightcrew ignored them, Epubcheck found them, and I deleted them. Lulu happy!