What does 'Well-Formed Check EPUB' actually check?

[bookman156]

I think it's okay for Sigil to mend or improve my code. The only thing in the current case is that I'm recording things for a publisher to change with 'their' EPUB while also making my own changes in 'my' EPUB. But the type errors are so many I'll send them my edited EPUB, but which will now contain all these other code changes that I didn't realise were being made. Not a problem from my perspective, the publisher will have the choice of using my file or going to the trouble of repeating my listed corrections on theirs.

Big publisher this is, releasing a Kindle of a book of mine off OCR text (they've lost the Quark file) that looks like an editor never even bothered to read through it afterwards. Publishing has somewhat gone down the drain from 'my day'.

[DiapDealer]

Just ask if you run into any problems. There's people here who've been using Sigil a long, long time. Probably since before the last captive-bred Quark file passed away.

[bookman156]

Thanks. My only other query at the moment is how I can tell whether the two .xpgt files (cover and page) are being used in the EPUB or whether the positioning is adequately taken care of by the stylesheet.css. Now I've corrected the media-type for them I'm wondering whether they aren't just dead-weight anyway. Do the .xpgt files still have some potential use today?

[DiapDealer]

I see fewer and fewer .xpgt files all the time. I'm sure ADE and RMSDK-based reading systems still honor them, but I get the distinct feeling they're falling out of fashion--a least based on the commercial EPUBs I purchase. Others may have differing opinions, of course, but I personally have very little use for them. They're handy for defining multiple-column layouts on larger screens, but on smaller screens, they're mostly used to annoyingly add more margin to already-quite-sufficient margins.

[bookman156]

That's the impression I'm getting too. I'll query it with the publisher but leave it as it is as these .xpgt files don't appear to be affecting validation of the EPUB.

The Flightcrew plugin interestingly shows up a few things that the idpf one (http://validator.idpf.org/) doesn't seem bothered about.

One can but check it in a myriad of ways.

[KevinH]

Originally Posted by bookman156

I corrected my post, managed to leave out the self-closing tag. Sorry about that.

FYI,
The self-closed version of your anchor tag is perfectly valid xml. That said, since the anchor tag is not technically a void tag (a tag that doesn't allow contents) some tool chains especially those html based will complain bitterly when they see such things. Sigil uses google's gumbo parser and serializes to polyglot xhtml/html. This means it serializes tags to versions that are correct in xml, xhtml, and html. In other words it only self-closes truly void tags, not just tags that are empty in this particular instance. For the anchor tag this means removing the self-close and adding a closing tag, making it valid no matter the toolchain used.

This happens in reverse as well. Kindlegen complained about svg image tags that are void tags and but are valid in xml if it has a closing tag but the closing tag made kindlegen complain. Their toolchain wanted the self-closed version on the image tag.

So Sigil will automatically serialize your code to try and make a version that is valid in xml, xhtml, and html5 all at the same time (ie. polyglot).

Hope this explains things.

KevinH

[bookman156]

Originally Posted by KevinH

Hope this explains things.

KevinH

Yes, very helpful. It's good to know what is going on and put these things to rest.