epubcheck plugin for Sigil - Page 25

slowsmile · 11-01-2020, 10:47 PM

@Thasaidon...On my 64bit Windows 10, Java is normally installed on this path: C:\Windows\Program Files (x86)\Common Files\Oracle\Java\javapath

I also use the Rapid Environment Editor to set all my paths, which is a free app. It's a wonderful app because it's so easy to use and you can expand all paths with a single click into a simple vertical list so that all paths are all clearly seen and read(Oh my tired old eyes!!) and any paths that are wrong or incorrect are automatically shown in red text. Much easier and much more helpful than using the crappy Windows path interface or command line to set or check paths. You can download and install it from this link:
Rapid Environment Editor Download(free)

Thasaidon · 11-02-2020, 01:52 AM

Quote:

Originally Posted by slowsmile

@Thasaidon...On my 64bit Windows 10, Java is normally installed on this path: C:\Windows\Program Files (x86)\Common Files\Oracle\Java\javapath

I also use the Rapid Environment Editor to set all my paths, which is a free app. It's a wonderful app because it's so easy to use and you can expand all paths with a single click into a simple vertical list so that all paths are all clearly seen and read(Oh my tired old eyes!!) and any paths that are wrong or incorrect are automatically shown in red text. Much easier and much more helpful than using the crappy Windows path interface or command line to set or check paths. You can download and install it from this link:
Rapid Environment Editor Download(free)

Thanks for the tip. I will definitely follow it up.

I just have to get Globe to sort out my Internet connection problems. I cannot get through to them by phone or IM. and our lockdown for senior citizens is definitely not helping.

Thasaidon · 11-02-2020, 02:19 AM

Quote:

To quote Doitsu's response to previous messages:

Quote:

Originally Posted by Doitsu View PostYou'll have to manually specify the java.exe path_

I did try that but somehow managed to botch the job so I thought it was a new problem. Hence why I asked again. I have made myself a more explicit notes for if/when it happens again.

I had already changed the java.exe path when I first installed the current version of ePubCheck. So I had mentally crossed it off my list of possible causes.

It did not "click" when I opened the Json file and my earlier amendment to the path had been replaced by "Java". I just went ahead but botched the joh.

Your confirming it was not a new problem forced me to go back and play with the Json file again. After a bit of faffing about I saw what I was doing wrong and finally fixed the problem.

The question is what changed the java.exe path I originally put in the Json file? It has been working correctly quite a while.

DNSB · 11-13-2020, 11:39 PM

I ran into one oddity with epubcheck. I was looking at an ebook for another MobileRead member and two of the html text files lacked the <!DOCTYPE html> line. One of those files was also missing <?xml version="1.0" encoding="utf-8"?>. Epubcheck passed the book with no errors but I got xml not well formed errors when attempting several operations on the epub (delete unused media files as an example).

KevinH · 11-14-2020, 12:08 AM

Having the xml declaration/header is not required by all systems I think. That said the DOCTYPE is important for setting the allowed xhtml entity definitions, if it should be interpreted as strict or transitional rulesets, and quirks and things. Having it missing in a xhtml file is not the best idea especially when the pages are served up as xhtml/xml vs html.
I am surprised that epubcheck did not flag it with at least a warning if not an error.

Running Sigil's Mend will fix any missing xml header and fix any missing doctype automatically based on the epub version.

Thasaidon · 11-14-2020, 01:12 AM

Quote:

Originally Posted by KevinH

Having the xml declaration/header is not required by all systems I think. That said the DOCTYPE is important for setting the allowed xhtml entity definitions, if it should be interpreted as strict or transitional rulesets, and quirks and things. Having it missing in a xhtml file is not the best idea especially when the pages are served up as xhtml/xml vs html.
I am surprised that epubcheck did not flag it with at least a warning if not an error.

Running Sigil's Mend will fix any missing xml header and fix any missing doctype automatically based on the epub version.

I have Just found this out.

I Installed the latest version of Sigil this morning. Very nice.

I did some work on a book in Calibre Editor and ran ePubcheck. I got no errors.

When I opened athebook to process it in Sigil I got the message about the not not being well formed. I said no to "fix the problem" and found I got the "not well formed" message when I tried to delete unused CSS and another feature . I ran epubcheck in Sigil - again no errors.

After a bit of invetigation I found that Sigil fixed the problem by adding a Doctype.

I logged onto Mobile Read and found this discussion.

Not a real problem and easily sorted but it is nice to know I got it right for once

KevinH · 11-14-2020, 10:46 AM

Hmm, I guess for epub3, the DOCTYPE might not be as important since no quirks and no named entities but for epub2 it really is required for xhtml to technically work properly.

That is why I added looking for it to the well formed check in Sigil. On ImportEPUB the error message for not well-formed was expanded to include it for Sigil 1.4.0.

Did you try looking at all the warnings from epubcheck to see if at least a warning is generated?

Thasaidon · 11-14-2020, 07:38 PM

Quote:

Originally Posted by KevinH

Hmm, I guess for epub3, the DOCTYPE might not be as important since no quirks and no named entities but for epub2 it really is required for xhtml to technically work properly.

Did you try looking at all the warnings from epubcheck to see if at least a warning is generated?

Just ignore on this one Kevin. If I had bothered to read the error message properly or I would have noticed it was related to DOCTYPE.

One thing puzzles me though. If it is so important to have this in why has this not been picked up before and by others?

Every book so far, in my library, I have opened in Sigil seems to be missing DOCTYPE and appear to work fine with my readers. All my books are epub2. I am puzzled.

hobnail · 11-14-2020, 07:49 PM

Kevin said, "but for epub2 it really is required for xhtml to technically work properly" but xhtml is not the same thing as html (even though it may look the same). I have books from the library that came as epubs and their chapter files are html, and they don't have a DOCTYPE.

KevinH · 11-14-2020, 10:43 PM

Yes, technically epub is xhtml thus xml. So to be rigorous to the epub2 spec, having a doctype that specifies the version of xhtml and the named entities should be important. My guess is most ereaders are serving these pages as html or adding the doctype on the fly if missing.

To be safest it technically should specify a doctype. Sigil has always used one and added it where needed during load. Only since Sigil 1.0 where Sigil stopped moving and updating every page on initial load has there been pages without it inside Sigil. That is why I added it to our well-formed check on epub load so it can be detected and fixed automatically like it was in the past if the user wants it to be.

If a epub does not use named entities outside of those recognized by xml, and instead uses no entities or only numeric entities, then you could probably dispense with the DOCTYPE safely. But since under epub2, Sigil supports named entities (such as  ) Sigil needs and enforces the DOCTYPE.

Calibre on the other hand removes all named entities and replaces them with the correct unicode character, so it can then remove the epub2 doctype safely.

Sigil uses the doctype as specified in the epub2 (2.0.1) specification for xhtml files.

Thasaidon · 11-14-2020, 11:42 PM

Quote:

Originally Posted by KevinH

Yes, technically epub is xhtml thus xml. So to be rigorous to the epub2 spec, having a doctype that specifies the version of xhtml and the named entities should be important. My guess is most ereaders are serving these pages as html or adding the doctype on the fly if missing.

To be safest it technically should specify a doctype. Sigil has always used one and added it where needed during load. Only since Sigil 1.0 where Sigil stopped moving and updating every page on initial load has there been pages without it inside Sigil. That is why I added it to our well-formed check on epub load so it can be detected and fixed automatically like it was in the past if the user wants it to be.

If a epub does not use named entities outside of those recognized by xml, and instead uses no entities or only numeric entities, then you could probably dispense with the DOCTYPE safely. But since under epub2, Sigil supports named entities (such as &nbsp

Sigil needs and enforces the DOCTYPE.

Calibre on the other hand removes all named entities and replaces them with the correct unicode character, so it can then remove the epub2 doctype safely.

Sigil uses the doctype as specified in the epub2 (2.0.1) specification for xhtml files.

Thank you for the explanations KebinH and Hobnail.

I understand now. That is something new I learned today.

My knowledge of XML, html and xml has been acquired by trial and error and editing ePubs and a little reading. It is usually sufficient for my needs but I know my knowledge is limited which is why I am a "Hedge Wizard" and not a Grand High Sorcerer like KevinH and some others on these forums.

FDPuthuff · 11-15-2020, 01:20 PM

Thank you kindly.
This will save some time.

hobnail · 11-15-2020, 02:26 PM

For our potentially nascent Grand High Sorcerer, the reason for my statement, "but xhtml is not the same thing as html (even though it may look the same)" is because a lot of software uses files with an xml syntax, but if those files were fed to a validating xml parser it would reject them. So they're using what you could think of as a faux or pseudo xml.

The xml syntax is very rigorous; for example, it's used for data transport by the stock exchanges, banks, etc. You definitely wouldn't want them using yaml or json for that.

Leonatus · 11-28-2020, 02:59 AM

Hi, Doitsu, it's me again, because ... you know why.
Win 32 bit, Sigil v. 1.4.2, EpubCheck v. 0.4.1.4.
I receive following message at running the plugin:

Code:

Status: failed

Traceback (most recent call last):
  File "C:\Program Files\Sigil\plugin_launchers\python\launcher.py", line 142, in launch
    self.exitcode = target_script.run(container)
  File "C:\Users\Juerg\AppData\Local\sigil-ebook\sigil\plugins\EpubCheck\plugin.py", line 388, in run
    opf_name = bk._w.opfname
AttributeError: 'Wrapper' object has no attribute 'opfname'
Error: 'Wrapper' object has no attribute 'opfname'

What I did is to save the epub erroneously first in OneDrive, and then on a USB stick, but the error message is the same. What should I do, please? Some software missing?

Doitsu · 11-28-2020, 03:05 AM

Quote:

Originally Posted by Leonatus

What should I do, please? Some software missing?

Please re-install the latest version of the EpubCheck plugin.

11-01-2020, 10:47 PM	#361
slowsmile Witchman Posts: 628 Karma: 788808 Join Date: May 2013 Location: Philippines Device: Android S5	@Thasaidon...On my 64bit Windows 10, Java is normally installed on this path: C:\Windows\Program Files (x86)\Common Files\Oracle\Java\javapath I also use the Rapid Environment Editor to set all my paths, which is a free app. It's a wonderful app because it's so easy to use and you can expand all paths with a single click into a simple vertical list so that all paths are all clearly seen and read(Oh my tired old eyes!!) and any paths that are wrong or incorrect are automatically shown in red text. Much easier and much more helpful than using the crappy Windows path interface or command line to set or check paths. You can download and install it from this link: Rapid Environment Editor Download(free) Last edited by slowsmile; 11-01-2020 at 11:36 PM.

11-13-2020, 11:39 PM	#364
DNSB Bibliophagist Posts: 46,582 Karma: 169712392 Join Date: Jul 2010 Location: Vancouver Device: Kobo Sage, Libra Colour, Lenovo M8 FHD, Paperwhite 4, Tolino epos	I ran into one oddity with epubcheck. I was looking at an ebook for another MobileRead member and two of the html text files lacked the <!DOCTYPE html> line. One of those files was also missing <?xml version="1.0" encoding="utf-8"?>. Epubcheck passed the book with no errors but I got xml not well formed errors when attempting several operations on the epub (delete unused media files as an example). Last edited by DNSB; 11-13-2020 at 11:50 PM.

11-14-2020, 10:43 PM	#370
KevinH Sigil Developer Posts: 8,841 Karma: 6120478 Join Date: Nov 2009 Device: many	Yes, technically epub is xhtml thus xml. So to be rigorous to the epub2 spec, having a doctype that specifies the version of xhtml and the named entities should be important. My guess is most ereaders are serving these pages as html or adding the doctype on the fly if missing. To be safest it technically should specify a doctype. Sigil has always used one and added it where needed during load. Only since Sigil 1.0 where Sigil stopped moving and updating every page on initial load has there been pages without it inside Sigil. That is why I added it to our well-formed check on epub load so it can be detected and fixed automatically like it was in the past if the user wants it to be. If a epub does not use named entities outside of those recognized by xml, and instead uses no entities or only numeric entities, then you could probably dispense with the DOCTYPE safely. But since under epub2, Sigil supports named entities (such as  ) Sigil needs and enforces the DOCTYPE. Calibre on the other hand removes all named entities and replaces them with the correct unicode character, so it can then remove the epub2 doctype safely. Sigil uses the doctype as specified in the epub2 (2.0.1) specification for xhtml files. Last edited by KevinH; 11-14-2020 at 11:15 PM.

11-15-2020, 02:26 PM	#373
hobnail Running with scissors Posts: 1,589 Karma: 14328510 Join Date: Nov 2019 Device: none	For our potentially nascent Grand High Sorcerer, the reason for my statement, "but xhtml is not the same thing as html (even though it may look the same)" is because a lot of software uses files with an xml syntax, but if those files were fed to a validating xml parser it would reject them. So they're using what you could think of as a faux or pseudo xml. The xml syntax is very rigorous; for example, it's used for data transport by the stock exchanges, banks, etc. You definitely wouldn't want them using yaml or json for that. Last edited by hobnail; 11-15-2020 at 02:29 PM.

11-28-2020, 02:59 AM	#374
Leonatus Wizard Posts: 1,058 Karma: 11391181 Join Date: Mar 2013 Location: Guben, Brandenburg, Germany Device: Kobo Clara 2E, Tolino Shine 3	Hi, Doitsu, it's me again, because ... you know why. Win 32 bit, Sigil v. 1.4.2, EpubCheck v. 0.4.1.4. I receive following message at running the plugin: Code: Status: failed Traceback (most recent call last): File "C:\Program Files\Sigil\plugin_launchers\python\launcher.py", line 142, in launch self.exitcode = target_script.run(container) File "C:\Users\Juerg\AppData\Local\sigil-ebook\sigil\plugins\EpubCheck\plugin.py", line 388, in run opf_name = bk._w.opfname AttributeError: 'Wrapper' object has no attribute 'opfname' Error: 'Wrapper' object has no attribute 'opfname' What I did is to save the epub erroneously first in OneDrive, and then on a USB stick, but the error message is the same. What should I do, please? Some software missing?

11-14-2020, 12:08 AM	#365
KevinH Sigil Developer Posts: 8,841 Karma: 6120478 Join Date: Nov 2009 Device: many	Having the xml declaration/header is not required by all systems I think. That said the DOCTYPE is important for setting the allowed xhtml entity definitions, if it should be interpreted as strict or transitional rulesets, and quirks and things. Having it missing in a xhtml file is not the best idea especially when the pages are served up as xhtml/xml vs html. I am surprised that epubcheck did not flag it with at least a warning if not an error. Running Sigil's Mend will fix any missing xml header and fix any missing doctype automatically based on the epub version.

11-14-2020, 10:46 AM	#367
KevinH Sigil Developer Posts: 8,841 Karma: 6120478 Join Date: Nov 2009 Device: many	Hmm, I guess for epub3, the DOCTYPE might not be as important since no quirks and no named entities but for epub2 it really is required for xhtml to technically work properly. That is why I added looking for it to the well formed check in Sigil. On ImportEPUB the error message for not well-formed was expanded to include it for Sigil 1.4.0. Did you try looking at all the warnings from epubcheck to see if at least a warning is generated?

11-14-2020, 07:49 PM	#369
hobnail Running with scissors Posts: 1,589 Karma: 14328510 Join Date: Nov 2019 Device: none	Kevin said, "but for epub2 it really is required for xhtml to technically work properly" but xhtml is not the same thing as html (even though it may look the same). I have books from the library that came as epubs and their chapter files are html, and they don't have a DOCTYPE.

11-15-2020, 01:20 PM	#372
FDPuthuff Avid Learner Posts: 39 Karma: 10 Join Date: Sep 2020 Location: Charleston, SC Device: Kindle Fire, iPad	Thank you kindly. This will save some time.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
[Plugin] PunctuationSmarten Sigil plugin	DiapDealer	Plugins	143	07-30-2025 06:58 AM
[Plugin] KindleImport Sigil plugin	DiapDealer	Plugins	187	07-04-2022 10:11 AM
Sigil Plugin Index	Thasaidon	Plugins	0	10-04-2014 07:41 AM
FC and Sigil 0.5.3 ePUBcheck failure	Hitch	Sigil	32	04-17-2012 02:56 AM
Web-based epubcheck upgraded to epubcheck 1.0.5	kjk	ePub	4	02-09-2010 09:53 PM