Sigil-1.4.0 Released - Page 3

DiapDealer · 11-16-2020, 09:26 AM

Please reduce the size of your images to comply with the forum rules. The longest side can be no more than 600px. Large images break the forum display.
Images thumbnailed

exaltedwombat · 11-16-2020, 09:45 AM

Quote:

Originally Posted by DiapDealer

I don't want or need a legacy theme. It's not up to me to exp!ain it.

Might be worth publicising the method for getting one-click access to header styles back though. The new 2-click method feels like a backwards step to me.

Tools: Clip Editor.
Move the header items (and anything else you'd like immediate access to) up to the top section.
R-click the header bar and make sure 'Clip Bar' is ticked. And you can un-tick
'Heading' now.

As you say, it's a pity many of the users who could use this information will never see it.

DiapDealer · 11-16-2020, 09:56 AM

Quote:

Originally Posted by exaltedwombat

Might be worth publicising the method for getting one-click access to header styles back though.

You just did (re)publish the method as far as I'm concerned. I'm not one that sees changing header sizes as fast (and with as few mouse clicks) as humanly possible as being remotely important. Certainly not more so than de-cluttering an already cluttered toolbar, anyway.

Quote:

Originally Posted by exaltedwombat

The new 2-click method feels like a backwards step to me.

Don't care.

StephV · 11-16-2020, 09:59 AM

Quote:

Originally Posted by DiapDealer

Please reduce the size of your images to comply with the forum rules. The longest side can be no more than 600px. Large images break the forum display.

Feel free to delete, I can't edit.

DiapDealer · 11-16-2020, 10:00 AM

I'll reattach them as thumbnails when I get a moment.

exaltedwombat · 11-16-2020, 11:00 AM

Quote:

Originally Posted by DiapDealer

You just did (re)publish the method as far as I'm concerned. I'm not one that sees changing header sizes as fast (and with as few mouse clicks) as humanly possible as being remotely important. Certainly not more so than de-cluttering an already cluttered toolbar, anyway.

Don't care.

Yes, there's a whole lot on the toolbar which individual users would consider not remotely important. I certainly apply a header style considerably more often than I change Text Direction! And my Ctrl-F reflex is ingrained well enough to make a Find button unnecessary. Other users will, of course, have their own preferences. But I think we would all agree that the Toolbar, as supplied, is cluttered.

So let's take this as a reminder that it's configurable! Thanks for prodding me into reducing mine to one line of icons.

I've just installed the latest Cubase. For once, they haven't decided that a new version requires a new 'look'. Phew!

Now I have to persuade a client that grey-on-grey is not the MOST readable colour scheme for her website...

KevinH · 11-16-2020, 11:09 AM

Just as your error message image explained. Your files are missing the DOCTYPE line at the top. Sigil up until 1.0 always added the proper doctype (they differ between epub2 and epub3).

epubcheck does not seem to catch this. But simply run Mend or allow Sigil to auto fix them and the proper DOCTYPE will be added and if you the run epubcheck again, you will see it pass if it did before.

Although calibre does not use a doctype, it can then not use named entities like "nbsp" and etc and so must replace them with the proper unicode character.

Sigil under epub2 does allow named entities and so technically requires the proper DOCTYPE be present to define them in xhtml just as the epub2 spec provides since use of named entities in many epubs is common.

So if you either add the proper DOCTYPE or allow Sigil's Mend to do it, all will be fine in Sigil then all issues should go away and epubcheck will still be happy.

This was default behaviour in Sigil up to Sigil 1.0, where it got relaxed but the caused errors when some people then used named (not numeric) entities in epub2. So detecting when it is missing and properly adding it was added back to prevent these issues (including making the default blank xhtml page fail since it used nbsp).

Hope this explains things.

KevinH

ps: Here are the appropriate doctypes for epub2 and epub3:

Code:

 epub3:

<!DOCTYPE html>


epub2:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
   "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

Quote:

Originally Posted by StephV

Hi,

I updated to 1.4.0 but it appears that this update is not working at all for me. Every book I open (that validated fine previously and contains no epubcheck errors) suddenly aren't "well-formed" (but really, there is no error at all and the headers are the same on every xhtml file within a single file).

Here is a "well-formed" header:

Attachment 183421

And here is a "faulty" header (according to 1.4.0):

Attachment 183422

Unfortunately, as I need a few tools that are blocked by the "well-formed" validation, I'm forced to revert back to 1.3 for now...

DiapDealer · 11-16-2020, 11:10 AM

Quote:

Originally Posted by exaltedwombat

Yes, there's a whole lot on the toolbar which individual users would consider not remotely important. I certainly apply a header style considerably more often than I change Text Direction! And my Ctrl-F reflex is ingrained well enough to make a Find button unnecessary. Other users will, of course, have their own preferences. But I think we would all agree that the Toolbar, as supplied, is cluttered.

So let's take this as a reminder that it's configurable! Thanks for prodding me into reducing mine to one line of icons.

I've just installed the latest Cubase. For once, they haven't decided that a new version requires a new 'look'. Phew!

Now I have to persuade a client that grey-on-grey is not the MOST readable colour scheme for her website...

Take it to a different thread please.

Doitsu · 11-16-2020, 11:12 AM

Quote:

Originally Posted by StephV

I updated to 1.4.0 but it appears that this update is not working at all for me. Every book I open (that validated fine previously and contains no epubcheck errors) suddenly aren't "well-formed" (but really, there is no error at all and the headers are the same on every xhtml file within a single file).

I was able to reproduce this issue. The problem is not caused by a missing doctype.

If the Mend On Open option is enabled and the user opens an epub2/epub3 book without the following XML declaration:

Code:

<?xml version="1.0" encoding="utf-8"?>

Sigil will display a warning and add the XML declaration to all files.

However, according to the W3C the XML declaration is only necessary if the HTML file isn't encoded as utf-8 or utf-16.

Quote:

Originally Posted by W3C

The XML declaration is only required if the page is not being served as UTF-8 (or UTF-16), but it can be useful to include it so that developers, testers, or translation production managers can visually check the encoding of a document by looking at the source.

Polyglot markup: A page that uses polyglot markup uses a subset of HTML with XML syntax that can be parsed either by an HTML or an XML parser. It is described in Polyglot Markup: A robust profile of the HTML5 vocabulary.

Since a polyglot document must be in UTF-8, you don't need to, and indeed must not, use the XML declaration.

KevinH · 11-16-2020, 11:13 AM

Where was the doctype in his image?

Are you using the latest master, as the check for the xml header was removed here:

https://github.com/Sigil-Ebook/Sigil...4b54efd6fa1a92

DiapDealer · 11-16-2020, 11:25 AM

Conversely, if you wish to create and edit epubs with no DOCTYPES (and no warnings about them being missing when opening), feel free to uncheck Mend on Open/Save in your Sigil Preferences.

There may be other instances (splitting, etc...) where you may need to tell Sigil not to fix the missing doctypes), though.

I don't recommend that, though. I recommend simply letting Sigil add the doctypes when it finds them missing.

Doitsu · 11-16-2020, 11:34 AM

Quote:

Originally Posted by KevinH

Where was the doctype in his image?

The commercial epub2 files that I used had indeed no doctypes (and no XML declarations), but they passed EPUBCheck.

Before mend:

Code:

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US">

After mend:

Code:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
  "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US">

I.e., epub2 files without doctypes that were opened without warnings in Sigil 1.3.0, even when Mend On Open was enabled, now trigger the warning that the OP complained about.

Of course the warning is correct since doctypes are mandatory in XHTML files. What is strange is that EPUBCheck doesn't complain about missing doctypes.

There's an issue that was closed.

KevinH · 11-16-2020, 11:42 AM

Yes, that is what my tests showed. Missing doctype does get complained about on load of epub but missing xml header but with doctype will load without warning.

Mend will properly fix this.

I have no idea why epubcheck does not detect this issue, and Sigil pre-1.0 automatically fixed this issue. The auto-fix got broken when we let people just load things with no changes in Sigil 1.0 - 1.3. The epub will still work correctly if no named entities are used (this is how calibre does it I am told). But then people stopped adding the doctypes but then started using named entities for copyright, nbsp, smart quotes, smart apostophes, etc and that broke things.

So for Sigil 1.4, we now explicitly check for the doctype and warn the user that something is broken if it is missing.

Here is the spec cited by epubcheck that says a DOCTYPE must be used.

https://www.w3.org/TR/xhtml11/confor...html#s_conform

pete6055 · 11-16-2020, 11:58 AM

Thanks, 1.4 is a very nice release.

I found a really minor glitch, though:

Some of my file names have a "+" in them. Sigil won't add the existing files and immediately exits the program. Once the files are renamed without the "+", Sigil works as expected. 1.3 and previous versions did not behave this way.

I'm running the 64-bit version on both Windows 10pro and Window10 standard.
I 'm Ok renaming my files so there is no need to execute an immediate fix.

DiapDealer · 11-16-2020, 01:02 PM

Please continue in the Sigil 1.4.1 critical release thread. It has all the features of this release plus a couple of important fixes.

Closing this one in the meantime to avoid confusion

11-16-2020, 09:26 AM	#31
DiapDealer Grand Sorcerer Posts: 28,574 Karma: 204127028 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	Please reduce the size of your images to comply with the forum rules. The longest side can be no more than 600px. Large images break the forum display. Images thumbnailed Last edited by DiapDealer; 11-16-2020 at 10:19 AM.

11-16-2020, 11:13 AM	#40
KevinH Sigil Developer Posts: 8,765 Karma: 6000000 Join Date: Nov 2009 Device: many	Where was the doctype in his image? Are you using the latest master, as the check for the xml header was removed here: https://github.com/Sigil-Ebook/Sigil...4b54efd6fa1a92 Last edited by KevinH; 11-16-2020 at 11:17 AM.

11-16-2020, 11:42 AM	#43
KevinH Sigil Developer Posts: 8,765 Karma: 6000000 Join Date: Nov 2009 Device: many	Yes, that is what my tests showed. Missing doctype does get complained about on load of epub but missing xml header but with doctype will load without warning. Mend will properly fix this. I have no idea why epubcheck does not detect this issue, and Sigil pre-1.0 automatically fixed this issue. The auto-fix got broken when we let people just load things with no changes in Sigil 1.0 - 1.3. The epub will still work correctly if no named entities are used (this is how calibre does it I am told). But then people stopped adding the doctypes but then started using named entities for copyright, nbsp, smart quotes, smart apostophes, etc and that broke things. So for Sigil 1.4, we now explicitly check for the doctype and warn the user that something is broken if it is missing. Here is the spec cited by epubcheck that says a DOCTYPE must be used. https://www.w3.org/TR/xhtml11/confor...html#s_conform Last edited by KevinH; 11-16-2020 at 12:02 PM.

11-16-2020, 11:58 AM	#44
pete6055 Connoisseur Posts: 74 Karma: 10 Join Date: Nov 2012 Device: none	Thanks... Thanks, 1.4 is a very nice release. I found a really minor glitch, though: Some of my file names have a "+" in them. Sigil won't add the existing files and immediately exits the program. Once the files are renamed without the "+", Sigil works as expected. 1.3 and previous versions did not behave this way. I'm running the 64-bit version on both Windows 10pro and Window10 standard. I 'm Ok renaming my files so there is no need to execute an immediate fix.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Sigil-1.3.0 Released	DiapDealer	Sigil	8	09-15-2020 08:03 AM
Sigil-0.9.10 Released	DiapDealer	Sigil	149	11-19-2018 10:20 PM
Sigil-0.8.900 released for testing - Wait for Sigil-0.8.901	KevinH	Sigil	106	10-04-2015 10:41 AM
Sigil 0.7.4 Released	user_none	Sigil	47	01-05-2014 02:31 PM
Sigil 0.6.0 Released	user_none	Sigil	93	11-24-2012 06:50 PM

11-16-2020, 10:00 AM	#35
DiapDealer Grand Sorcerer Posts: 28,574 Karma: 204127028 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	I'll reattach them as thumbnails when I get a moment.

11-16-2020, 11:25 AM	#41
DiapDealer Grand Sorcerer Posts: 28,574 Karma: 204127028 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	Conversely, if you wish to create and edit epubs with no DOCTYPES (and no warnings about them being missing when opening), feel free to uncheck Mend on Open/Save in your Sigil Preferences. There may be other instances (splitting, etc...) where you may need to tell Sigil not to fix the missing doctypes), though. I don't recommend that, though. I recommend simply letting Sigil add the doctypes when it finds them missing.

11-16-2020, 01:02 PM	#45
DiapDealer Grand Sorcerer Posts: 28,574 Karma: 204127028 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	Please continue in the Sigil 1.4.1 critical release thread. It has all the features of this release plus a couple of important fixes. Closing this one in the meantime to avoid confusion

Advert

Advert