FC and Sigil 0.5.3 ePUBcheck failure

[Hitch]

Originally Posted by user_none

FlightCrew does not currently check for un-manifested files. That's why it says it found no issues.



From the looks of it the EPUB 2 spec is saying un-manifested files should just be ignored and they are not errors.

Do I understand you to be saying that this means that even though FC isn't in synch with ePUBcheck, we're going to leave it as-is? I'm really NOT trying to be argumentative, but if the books won't pass ePUBcheck, which is what all the retailers use, then for someone like me and my company, FC is not viable, either built-in to Sigil or SA, regardless of whether it's purportedly in "paper compliance" with the ePUB2 spec or not.

Can you confirm I've correctly understood you?

Hitch

[DaleDe]

ePUBCheck has been modified for use with ePub 3 specifications. It may be that they added this check for ePub 3 and forgot to disable it if the ePub is for version 2. Just a thought.

[eping]

Originally Posted by mmat1

No!

You actually don't say, why you find epubcheck that worse.

I say, using it won't hurt.

Yes, I didn't say the details, I just drew a conclusion. It needs many words to state and describe.
Actually, I even think ePubcheck should be abolished ASAP. Its existence is absurd, a shame only reveals the awkward status of ePub and eReaders. Is there HTML validator for web browser? Is there PDF validator for PDF files? Is there mobi validator for Kindle?
The committee only dream out "standards" occasionally, but can not release any convertor or composer compatible to their own standards, and even has no ability to make all eReaders to obey their standards.

I say this not for any user who like it or not, it's for the industry.

[eping]

Originally Posted by Hitch

Do I understand you to be saying that this means that even though FC isn't in synch with ePUBcheck

Hitch

I asked a similar question in another thread:

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...

I reckon ThreePress has paused or even gave up their Preflight.
So I also worry about the future of FlightCrew.

[mmat1]

Originally Posted by eping

Its existence is absurd, a shame only reveals the awkward status of ePub and eReaders.

Ok, you vote against the standard and the way how it's "established".

That make things clearer for me.

I'm still grateful that there is a thing which tells me something about mispelled links in my books, that's a complete different point of view.

[Hitch]

Originally Posted by mmat1

Ok, you vote against the standard and the way how it's "established".

That make things clearer for me.

I'm still grateful that there is a thing which tells me something about mispelled links in my books, that's a complete different point of view.

Yes, I agree with mmat1; for me, it isn't about compliance with the spec per se inasmuch as it's a very helpful troubleshooting tool for us--but as a professional shop, our books have to pass ePUBcheck, regardless of my own view on the topic; for the purposes of this discussion, my views--or, for that matter, that of anyone else--are actually irrelevant. The question is, can it be relied upon to return results that will synch with the existing ePUBcheck being used by the industry?

For those of you free to follow your own whims, and who object to it in principal: fine--don't use it. It's not like it's foisted on you. My question is strictly about reliability and conformance with what's currently being used by the major retailers.

Hitch

[eping]

Yes, that's right, I don't deny that we must obey the current law and rules.
But we must also think about if the law is reasonable and practical at the same time. If possible we should change the law.
Maybe my thought is a little far.

[JSWolf]

Originally Posted by eping

Is there HTML validator for web browser?

Actually, there are programs that will check web sites for a number of issues.

[JSWolf]

Originally Posted by Hitch

Yes, I agree with mmat1; for me, it isn't about compliance with the spec per se inasmuch as it's a very helpful troubleshooting tool for us--but as a professional shop, our books have to pass ePUBcheck, regardless of my own view on the topic; for the purposes of this discussion, my views--or, for that matter, that of anyone else--are actually irrelevant. The question is, can it be relied upon to return results that will synch with the existing ePUBcheck being used by the industry?

For those of you free to follow your own whims, and who object to it in principal: fine--don't use it. It's not like it's foisted on you. My question is strictly about reliability and conformance with what's currently being used by the major retailers.

Hitch

There is one solution to the problem...

Run FC and get the ePub to pass. Once that's done, run the ePub through EC and then fix anything EC finds and once that's sorted, as long as the ePub looks as you want, done.

[Jellby]

Originally Posted by user_none

From the looks of it the EPUB 2 spec is saying un-manifested files should just be ignored and they are not errors.

It might issue a warning, though, as it does with "unused" files.

[user_none]

Originally Posted by Hitch

Do I understand you to be saying that this means that even though FC isn't in synch with ePUBcheck, we're going to leave it as-is?

That is correct. FC isn't doing anything wrong. FC is an EPUB validation tool that checks for common (not all) errors in an EPUB file according to the (at this time) EPUB 2 spec.

Adding in a check that to generate an error based upon (what appears to be) incorrect behavior on ePubCheck part is absurd. FC isn't trying to be an ePubCheck clone and it's wrong to do things wrong simply because ePubCheck does it that way. It's also impossible to determine how ePubCheck will handle each and every situation without simply being ePubCheck.

It's unfortunate that stores require validation with ePubCheck before they will allow uploading a file but that's there possibility. However, you need to deal with their policies. Just like how it's fortunate that Apple has decided to create and require use of their own fork of EPUB.

I'll also point out that these stores are using ePubCheck 3 which is currently marked as a beta.

Originally Posted by Jellby

It might issue a warning, though, as it does with "unused" files.

I don't think warnings are appropriate in this case. With unused files you've explicitly marked (by adding them to the OPF) that you want them used. Hence the warning. In this case there are plenty of files that you would add to the EPUB and not actually want or need them listed in the manifest.

Also, lets say warning are appropriate, here is where it gets fun. ePubCheck ignores files in certain places within the EPUB. So where do we draw the line about what get's warned on and what doesn't especially when un-manifested are perfectly legitimate.

[eping]

Originally Posted by user_none

it's wrong to do things wrong simply because ePubCheck does it that way.
Ethical

It's also impossible to determine how ePubCheck will handle each and every situation without simply being ePubCheck.
impossible in practice

It's unfortunate that stores require validation with ePubCheck before they will allow uploading a file but that's there possibility.
The absurd reality.
I don't think warnings are appropriate in.

I think user_none explained this issue very well.

[Hitch]

Originally Posted by user_none

That is correct. FC isn't doing anything wrong. FC is an EPUB validation tool that checks for common (not all) errors in an EPUB file according to the (at this time) EPUB 2 spec.

Adding in a check that to generate an error based upon (what appears to be) incorrect behavior on ePubCheck part is absurd. FC isn't trying to be an ePubCheck clone and it's wrong to do things wrong simply because ePubCheck does it that way. It's also impossible to determine how ePubCheck will handle each and every situation without simply being ePubCheck.

It's unfortunate that stores require validation with ePubCheck before they will allow uploading a file but that's there possibility. However, you need to deal with their policies. Just like how it's fortunate that Apple has decided to create and require use of their own fork of EPUB.

I'll also point out that these stores are using ePubCheck 3 which is currently marked as a beta.



I don't think warnings are appropriate in this case. With unused files you've explicitly marked (by adding them to the OPF) that you want them used. Hence the warning. In this case there are plenty of files that you would add to the EPUB and not actually want or need them listed in the manifest.

Also, lets say warning are appropriate, here is where it gets fun. ePubCheck ignores files in certain places within the EPUB. So where do we draw the line about what get's warned on and what doesn't especially when un-manifested are perfectly legitimate.

Having discussed this with you elsewhere, I don't particularly disagree with you on most of this; however, please note that Apple, in specificity, is not using epubcheck for ePUB3; it's using the last version for ePUB2, FWIW.

And I still have the issue with the files having been saved with the detritus, IN Sigil.

Thanks,
Hitch

[AlexBell]

Originally Posted by JSWolf

So for now, would it be best to double check FC by running the ePub through ePubCheck after FC says all is well?

That's what I always do - see related thread FlightCrew versus ePubCheck.

[Jellby]

Originally Posted by user_none

I don't think warnings are appropriate in this case. With unused files you've explicitly marked (by adding them to the OPF) that you want them used. Hence the warning.

Adding a file to the manifest just means it is "part of the publication", whatever that means. For instance, when I have a specific CSS file that is only used by my custom epub2pdf script, I add it to the manifest, but it's otherwise unused. And if I add a cover/thumbnail image just to be used in a <meta> tag, is it used or not? is it to be manifested or not?

In this case there are plenty of files that you would add to the EPUB and not actually want or need them listed in the manifest.

Also, lets say warning are appropriate, here is where it gets fun. ePubCheck ignores files in certain places within the EPUB. So where do we draw the line about what get's warned on and what doesn't especially when un-manifested are perfectly legitimate.

True. Without wanting to bloat FC, what about an option to list all unmanifested files? Then the creator can decide whether they are intended or not.