Puzzling scripted HTML issue

13 posts / 0 new
Last post

Hi all. I’m developing an epub3 ebook. It’s model validates in http://validator.idpf.org/ and renders all right in my PC ebook readers. However one of its HTML files reports an error on my Android ebook reader:

error on line 37 at column 8: Opening and ending tag mismatch: Meta line 0 and head.

The Android reader showing this error line supports epub3 and was “painting” everything fine until I modified a line code in the .opf file to get the whole epub3 file validated, after discovering I had missed a declaration. The HTML now in trouble has two javascript functions and I had not added the properties="scripted" to its opf file “item” line. So it looked like this:

<item href="Text/myScriptedFile.xhtml" id=" myScriptedFile.xhtml" media-type="application/xhtml+xml"/>

And I had to modify it to get its content this way.

<item href="Text/ myScriptedFile.xhtml" id=" myScriptedFile.xhtml" media-type="application/xhtml+xml" properties="scripted"/>

It can be said now that this modification gets my file validated but causes the Android ereader to crash and show the error described above. But the properties=”scripted” declaration is mandatory according to the epub3 standard and I think it’s properly set. So I have temporarily looked back to the scripted HTML that produces the error.

On doing this I’ve begun looking for a parsing error caused by a mislead interpretation of the scripting (as the opening ending mismatch in the error message and its triggering in the opf file suggested to me there could lay the problem). However, after some successive simplifications of the HTML code I’ve come to left just this in the xhtml file:

<html>
<head>
</head>
<body>
<p>Text</p>
</body>
</html>

Just to discover that… ¡¡¡¡The error message is still there!!!! (Now saying “error on line 6 at column 8: Opening an ending tag mismatch: Meta line 0 and head.)

I feel now completely lost. There seems to be no possible syntax error in such a simple code, but, at the same time, the item line in the opf file seems right. Maybe the problem is in another part of the epub package, but I can’t even imagine where.

I hope there’s anyone able to help me out of this trouble.

Thanks in advance for it.

The only way to debug is to start with what you know:

error on line 6 at column 8: Opening an ending tag mismatch: Meta line 0 and head.

If you break down this message, it says there is a meta tag on line 6 of the html file, that is a direct child of the head element, that has most likely not been self-closed (i.e., missing '/>' at the end). That's the only reliable piece of information you have, as it's the same error from the start. Unfortunately, it doesn't match the markup you've posted.

If you've verified the file using epubcheck, as you say, there's pretty much no way an error like that could have passed quietly (it fails the most basic of xml well-formedness tests).

If you can't find the offending meta tag, I suppose there's always the possibility it's a bug in whatever android reading system you're using, possibly that only gets tripped when scripting controls are put in place. Have you tried testing one of the scripted EPUB samples in it? If those fail with the same message, that would be a good indication it's the reading system that has a bug.

It still seems odd that the scripting property would be the cause, but without seeing your actual book or knowing what reading systems you're testing in, it's hard to know what's going on.

Hi Matt. Let me first thank you for your suggestions. As you will see below they got me somewhat to the point. I wasn’t aware of those examples you linked. The ebook business is new for me and (what’s worse to me now) I was in managerial position before getting involved into this crazy project at the edge of the publishing technology.

Getting down to the point, let me, please, untangle a little bit my first post, as your reply makes me think it wasn’t clear enough. I haven’t developed code in years but, from my own (and other’s) experience, I can ensure with any doubt that all kinds of software may end up crashing and showing error messages in situations apparently unrelated to the type of error message. For example, if one forgets an ending </div> at the beginning of an html page, the parsing analysis won’t probably discover it till the end of the page, when it meets the ending </body> tag failing to match all <divs> and </divs>. Or, if one develops a software that fails to release memory after usage, memory consumption won’t ever stop and the problem will show up while running other software from a different company/developer, just when the operative system runs out of memory resources. This kind of abstruse problem is what I was fearing after seeing the error message didn’t match the simplest code posible; and I couldn’t even foresee what code / data could be relevant apart from the obvious one (that I posted). Let me apologize for not writing any more details.

However, the problem seems not to be so complex. You got it right. I’ve used the examples you linked to discover that it’s my Android software what fails. Which is a pity, because it was working fine till now and looked to me as the best to be found among the free epub3 readers. These are the test’s results:

- The cc-shared-culture-20120130.epub (Creative Commons – A Shared Culture) triggers the same error message then the reader has to render the p20.xtml file, which is the one with the scripting.
- The cole-voyage-of-life-tol-20120405.epub (Thomas Cole – The Voyage of Life) triggers the same error message with all its four scripted xtml files.

The reader is ASTRE-Bee.

Mmmm… Let me change my words. I have seen a thread where you suggest Lektz as a reasonably good epub3 reader for Android and say it appears to be a derivative of readium. And it doesn’t crash with any of the two testing books I’ve just used from your link. Still, my own epub file keeps on having the very same problem and (remember) it validates.

Do you have any further idea about what may be happening here?

I need at least one Android epub-reader working fine (to carry out tests and ensur the book will be readable), or, at least, understanding and avoiding what makes my book-rendering fail, even if its code is formally right.

Thanks in advance for your help.

PS: If you need any more info, please feel free to ask. I’ll try to put here that part of my code.

Another interesting thing is that the PC-based version of Astri-bee renders the Cole book fine, but the Android version throws that error.

I can't be 100% certain what is going on, but I would guess that the reading system interface itself is adding html meta tags into the source which then croaks the interface when rendered as xhtml. Readium, for example, renders content within an iframe within the page, and imports a number of helper javascript libraries and a meta charset tag. Its reading interface is also html, with only your content rendered in the iframe as xhtml. If these others are doing similar, but incorrectly rendering the full interface as xhtml, that could explain the error. Unfortunately, I haven't been able to find a way to get at the full interface html source in astri app to see what is happening (the crash occurs before any scripts can run).

You're right in the case of the astri reader that it's tied to setting the scripted property in the package file, so bizarre things do happen! If I remove the declarations, it no longer has a problem with the file, but javascripts are also blocked.

The odd thing is that there are no specific behaviours associated with these properties in the EPUB specs, so I'm not sure why you'd get the same issue in Lektz but not with the other files. The properties are there as hints to the reading system developers, as they were intended to allow dynamic module loading (to kep implementations lightweight), to simplify processing epub:case elements without having to first inspect each file, etc.

It doesn't appear that there's anything you can do to solve this problem, though, short of reporting it to the developers. If you want to contact me offline, I'd be interested to see if there's another reason why Lektz is only be misbehaving with your file (I can't reproduce the issue, so can't even try to test). You can reach me at matt (.) garrish (at) gmail (you know the rest).

 

PC-based version of Astri-bee renders the Cole book fine, but the Android version throws that error.

Blech, I was assuming you were testing different reading systems on different platforms, but if you've been testing the same for all just ignore this comment!

Your assumption about the readers I’m using was all right. I’m using different reading systems in different platforms. On my PCs I first use Sigil (which is the epub editor I’m using most of the time), then I test the epub file with the Calibre reading module. However there’s a difference between the result of your tests and mine. My javascripts don’t get blocked if I eliminate the properties=“scripted” declaration. They still work. All they do is show / hide a set of divs and keep on doing it all right.

Having in mind what you describe on how Redium works, your explanation makes perfect sense to me. Probably it’s a bug (another one in the e-readers world, as I’m learning the hard way). So I guess the best way to solve it is to report it to the developers. I’ll do it just after posting this.

It’s sad to come to suspect that there’s possibly nothing that can be done but wait to see the issue solved. In addition I’m not into debugging readers code. But I’ll contact you offline to try to help you check the details in Lektz.

Thanks a lot for everything.

That's interesting. I was trying to generate an alert to get at the source, but got no result in the astri app after removing the property to get the page to render (but did in others). Could have been another limitation.

Removing the scripted designator may have no effect depending on the reading system, as there's no requirement that scripting only be enabled when it is present. It's just a hint that scripting does need to be enabled for the document, but one that's currently enforced by error by epubcheck, so if your content must validate in order to distribute you're kind of stuck at this time. The value of these hints is up for discussion in the 3.0.1 revision going on now, so there may be changes on the spec front, as well.

But the nuisance of creating EPUB 3s at this time is that reading systems are still in development, so waiting for the bugs to be fixed often times is all you can do. Developers do tend to be pretty responsive to issues, especially ones as glaring as this, so I would hope you'd get a timely patch released.

What is VitalSource Bookshelf and let me know to use the same for ePub3

Thanks for your help in advance.

This book of mine won’t probably need of validation for being sold. At least I assume that at this time. But it’s definitely kind of a good quality mark to use in my own job’s benefit. And this may be important sometimes. Especially when one deals with people without a tech background.

I have already emailed the developers with a link to the testing epubs and this thread, so that they can get a good picture of the problem. They haven’t answered, so I don’t know what they may do or don’t do about this. Let’s hope they react as responsively as you estimate. The ASTREE-Bee Android app looks like a good one to me.

Cheers.

Sekar, I don’t believe I understand what you mean.

Ok. Please suggest and prefer the best conversion tool for PDF to ePub 3

Sekar, that’s a different issue. You should open a new thread for it. That way you’ll contribute to keep this forum neat and clean and will get visibility for your problem.

In addition I may not be the person to help you out of this problem. I’ve never needed of a pdf to epub conversion.

Anyway, there I go:

As far as I know the best way to make an epub from a pdf is using calibre, but they say the results aren’t that good, so you will probaly have to tweak it a little bit. If you can afford the effort you can convert the pdf to text and then build the epub layout from the scratch. The result will surely be better this way.

May any others help you further beyond, follow their indications.

I hope what I tell you helps, anyway.

Secondary menu