Validation errors for XPGT file and for Embedded Fonts

[GrannyGrump]

I am getting some validation error messages, and I can't find solutions.

ISSUE NBR. 1 -- I am using an "xgpt" file for some alternate formatting. I found a year-old thread here https://www.mobileread.com/forums/sho...d.php?t=214902
but I don't see a solution suggested. Can I ignore this, or must I code a fallback? If a fallback is necessary, how do I do that?

idpf.org validator says:

non-standard stylesheet resource 'OEBPS/Misc/template.xpgt' of type 'text/plain'. A fallback must be specified.

PAGINA epubchecker says:

ERROR: <book name>.epub/ops/xhtml/halftitle2.html(7,108): non-standard stylesheet resource 'ops/styles/page-template.xpgt' of type 'application/vnd.adobe-page-template+xml'. A fallback must be specified.

FlightCrew says:

The <item> element's "media-type" attribute has value "text/plain", but the file's media type is "application/vnd.adobe-page-template+xml"

ISSUE NBR. 2 -- I am using embedded fonts. Everything displays fine on Sony device, in ADE, and Calibre Viewer. But getting error messages from the W3 validator (the first time I have used this one.) The other validators do not give any messages about fonts. Can I ignore this message, and if not, how do I correct it?

W3.org jigsaw says:

Error : font-family Property font-family doesn't exist in CSS level 2.1 but exists in [css1, css2, css3] : "JFFerrule"

Error : Property src doesn't exist : url("../Fonts/JFFerrul-mod.ttf") format("truetype")

My css looks like this

@font-face {
font-family: "JFFerrule";
src: url("../Fonts/JFFerrul-mod.ttf") format("truetype");
}

So jigsaw doesn't care about the xpgt file, and the other three don't find anything wrong with my fonts.

Any words of wisdom? or even of encouragement?
Thanks.

[Jellby]

Originally Posted by GrannyGrump

Error : font-family Property font-family doesn't exist in CSS level 2.1 but exists in [css1, css2, css3] : "JFFerrule"

Error : Property src doesn't exist : url("../Fonts/JFFerrul-mod.ttf") format("truetype")

Set the validator to CSS 3.

[Doitsu]

The epubcheck developers recommend to declare a fallback as follows:

<item id="css" href="epub_css_r1.css" media-type="text/css" />
<item id="xpgt" href="page-template.xpgt" media-type="application/vnd.adobe-page-template+xml" fallback="css"/>

Unfortunately, this method doesn't work with epubcheck 3.0.1 and has been officially recognized as a high priority bug: Non-core media type stylesheet check ignores fallbacks (ePub Check 3.0.1) #271

Hopefully, this bug will be fixed in the next version.

[odedta]

Originally Posted by Jellby

Set the validator to CSS 3.

Or remove the format("truetype") part.

[GrannyGrump]

To all, thank you for responding.

@Jellby, when using the "automatic" link through Sigil, W3 does not offer options to change. When I uploaded manually, I could change that, and got a clean report. Thank you.

@odedta -- I thought the format("blahblah") was required. ???

@Doitsu -- I found the thread on google code about the bug being assigned "high priorty", but since it has been more than a year, I think their definition of high priority is a lot different than mine. I added in the fallback just for grins, and also changed the "text/plain" part; but of course no change in results. (except FlightCrew loves me better now.)

Hopefully, this bug will be fixed in the next version.

Words to live by, indeed.

[odedta]

Originally Posted by GrannyGrump

@odedta -- I thought the format("blahblah") was required. ???

CSS3 @font-face Rule

[GrannyGrump]

OK, not necessary. Good to know. Thanks!

[Hitch]

Originally Posted by GrannyGrump

OK, not necessary. Good to know. Thanks!

Granny:

Give up on this. ePUBcheck has this known error, as Doits told you. I've been getting old epubs back for weeks, as Nook and Bookbaby have both gone to ePUBcheck 3.0.1, and nothing we've tried, short of simply removing the xpgt, works. It's absolutely infuriating, and every ePUB we've ever made with an xpgt (which you really needed back in the early ADE days!!) has ALWAYS had fallback coding.

URGHG.

Hitch

[GrannyGrump]

Hi Hitch. How much do hobbyists have to worry about validation?

I don't have to pass a validation to upload a book, so my only concern is whether the book would actually fail to work. Does the validation failure actually mean the book will fail to display correctly in some devices? Or is that just the distributors being anal?

[Hitch]

Originally Posted by GrannyGrump

Hi Hitch. How much do hobbyists have to worry about validation?

I don't have to pass a validation to upload a book, so my only concern is whether the book would actually fail to work. Does the validation failure actually mean the book will fail to display correctly in some devices? Or is that just the distributors being anal?

Hey, Gran:

Just distributors being anal. But please note: depending on the place you're uploading, (say, for example, Smashwords, which uses an older validation check), they may get rejections up/downstream, when they send same book to (for example) Nook/Kobobooks.

The error isn't an error. The error is a bug. It's a bug in ePUBcheck 3.01. There's nothing wrong with the book itself, although the stuff we used to all use the xpgt for is now redundant with the upgrades made to ADE since--what, guys, 2.0? It was really needed in ADE 1.x, because otherwise, the text ran to the margins and all sorts of other peculiar stuff. So, generally speaking, you SHOULD (famous last Hitch words) be able to yank the xpgt out of your book and it SHOULD be no harm, no foul.

OTOH, as I said: no, the "error" is just a bug in the actual ePUBchecker. For whatever reason, it doesn't see the fallback CSS sheet you have in your book. We can all only hope that 3.02 will fix it, BUT, the distributors change ePUBcheck like glaciers dance, so even if 3.02 came out tomorrow, KoboBooks et al mightn't move to 3.02 for a year or more.

Does that answer your question?

Hitch

[GrannyGrump]

It does answer the question, and is only semi-depressing, as opposed to totally disgusting. I had no idea the epubcheck was under such sloooooow development!

Anyway, the xpgt I am using is for some alternate font formatting, which as far as I understand from some helpful folks here (Hi Jellby and Doitsu), does not work in ADE yet. So if it doesn't break anything, I guess I will leave it in place.

Thanks so much for the clarification.

[Hitch]

Originally Posted by GrannyGrump

It does answer the question, and is only semi-depressing, as opposed to totally disgusting. I had no idea the epubcheck was under such sloooooow development!

Anyway, the xpgt I am using is for some alternate font formatting, which as far as I understand from some helpful folks here (Hi Jellby and Doitsu), does not work in ADE yet. So if it doesn't break anything, I guess I will leave it in place.

Thanks so much for the clarification.

GG:

It's not the ePUBcheck that is under slow development (although, given what's happened with ePUB3, other than "media," it seems to me that ePUBs themselves are going backwards, e.g., having an inline TOC, for all intents and purposes, instead of an NCX, as just one example), it's that the distributors and aggregators are EXCEEDINGLY slow to adopt new ePUBchecks. Hell, one of them--I forget if it's LSI, but I think so--is still using ePUBcheck 1.x. {shrug}. If you put "author" in the metadata instead of creator, it pings and rejects the freaking ePUB. I mean...sheesh.

Hitch

[JSWolf]

I've never had a problem with an ePub without the xpgt file. I always remove it because there's no need for it. This is going as far back as ADE 1.7.x.