Sigil-0.9.6 Released

[Mister L]

Originally Posted by DiapDealer

I guess it's possible that there's a condition where Sigil launches, but the clips ini is unavailable while everything's loading. Possibly some antivirus or antispyware program that's locking the ini file so Sigil can't access it. That's just a guess at the moment. I haven't been able to make it happen myself, yet.

Is your clip collection quite extensive, out of curiosity? Just wondering if it's maybe a size-related thing.

My sigil_clips.ini is 5ko. I also have a lot of personalised Saved Searches (sigil_searches.ini = 7ko) but I've never noticed the searches go missing (although I haven't thought to check wh.

Originally Posted by Toxaris

While reading this thread I remember having this sometimes as well, but only when I have multiple ePUB's open in different Sigil instances. The first instance always have the clips, the subsequent Sigil instances not always (never?). If I close all instances and just open a new/old ePUB, I have the clips again. So, it might be a locking issue.

I have had the clips disappear on an instance that had them just previously, however I am 99% sure it's always when I have more than one instance open. I don't think it's a problem at the initial launch but maybe when a new instance is launched the clips are momentarily unavailable for other instances. The locking issue sounds plausible to me.

Originally Posted by Tex2002ans

Both versions are just the normal EXEs that were released whenever, just installed to two different folders:

C:\Program Files\Sigil
C:\Program Files\Sigil096

Also, this problem definitely never occurred when I just had Sigil 0.8.6 installed.

I confirm, this problem is recent. Also I checked my program files, I had 3 previous versions of Sigil still installed along with the current one (none portable, but in different directories like Tex2002ans), but all of their preferences locations pointed to the same directory (and my file associations point to the latest version so I haven't used any previous versions lately).

Originally Posted by Tex2002ans

This disappearing Clips problem occurs only when I open the second/third instances of EPUBs in Sigil. (I typically open up a previous EPUB to copy/paste some CSS from it, or see how I coded a certain thing).


Hmmm... would Sigil lock itself out of opening the Clips file if it was loading multiple EPUBs at the same time?


I have been working on a few massive EPUBs that take a while to open. Could one instance of Sigil be locking the other one from opening the .ini?

Saved Searches all still seem to be there, and all other preferences seem to carry over fine.* (Although again, I haven't looked super-in-depth when the error occurs).


I personally have found no correlation between which version of Sigil/Calibre created the file initially and this bug. It happens in Sigil 0.9.6 with any and all EPUBs (super old, super new, whatever). The only thing is multiple instances being open at once.

Just did an experiment:

Working on one file, clips are there.

- Without closing 1st instance, open a 2nd epub. Clips still there for both.
- Open a 3rd file: clips disappeared from the first and second files but are there on the 3rd one.
- Close 3rd and 2nd file: clips came back on the first file.
- Open 2nd and 3rd files again: clips disappeared on 1st and 2nd files but are there on 3rd.
- Closed 3rd and 2nd, clips still missing on 1st instance.
- Saved searches are all there, nothing else seems to have changed.

- Had to close and open again my original file to restore the clips but they are back now.


These are all recent files so I also now think this problem is linked to the number of instances open and not to do with the version used to created the files.

[DiapDealer]

I simply haven't been able to replicate this yet. I've had as many as eight epubs (some very large, some very small) open at once, and none of those eight Sigil instances had my custom clips revert to the default ones. Granted ... I normally don't use clips all that much, so my sigil_clips.ini file is pretty small. I'll try experimenting with a larger clips database when I get time.

[KevinH]

All I can think of is that this may be related to one instance of Sigil writing to the Settings and somehow locking it which prevents others from reading it successfully. Mixing versions of Sigil may also be an issue if new settings have been included and old settings removed.

We have had a number of changes to the settings in recent releases.

I can not recreate this on a Mac at all, but there are never multiple instances of Sigil running on a Mac, there are just multiple main windows all from the same main process all sharing the same settings file so the problem case simply can not trigger in this type of environment.

KevinH

[KevinH]

Did a little reading on how QSettings objects (Sigil's SettingsStore inherits from QSettings).

I see the following:

QSettings can safely be used from different processes (which can be different instances of your application running at the same time or different applications altogether) to read and write to the same system locations. It uses advisory file locking and a smart merging algorithm to ensure data integrity. Note that sync() imports changes made by other processes (in addition to writing the changes from this QSettings).

Having large clips to read (or saved searches or paste histories) may result in this advisory file locking to keep the ini file locked longer helping to show any problem.

This advisory file locking and "smart" merging appears to not be so "smart" on some systems! My guess is DiapDealer was 100% correct in that the ini file is locked when doing a long read just when another process needs it and so it returns the default value for clips (or anything) when it can not read the file because it is locked.

That said I think DiapDealer is testing with a newer version of Qt (for our next release) than the current releases do, so this bug may have already been fixed in later versions of Qt.

I think all we can do is check the status() of the last setting retrieval and then run a sync() and try again but this would require a complete rewrite of the Sigil SettingsStore code. Perhaps we should simply see if this bug in QSettings goes away with the newer Qt releases.

KevinH

[Tex2002ans]

This is also on Windows 7 64-bit.

I attached my sigil_clips.ini in a ZIP file if that helps... although there aren't many clips beyond the defaults.

I also have the Clips window attached in the corner of my Sigil (which is how I can easily tell the Clips disappear into thin air when I open an EPUB).



I haven't used a fresh install of Sigil in a very long time, so I forget if that window exists by default.

Originally Posted by KevinH

That said I think DiapDealer is testing with a newer version of Qt (for our next release) than the current releases do, so this bug may have already been fixed in later versions of Qt.

We could hope.

At least everyone is aware of it now. Thanks again for bringing it up Mister L.

Now speaking of bugs, I ran into a very obscure one. I sent the details in a PM to KevinH many moons ago but never got a response. I will fish that one out and see why I didn't post it publicly, and see if it still is buggy in the latest version.

If I remember correctly it had to do with Exporting/Importing Saved Searches, and differences between Windows/Mac's files with Carriage Returns + Line Feeds.

I am probably the only person in a thousand years who actually tried/used/knew about that functionality.

[Doitsu]

Originally Posted by Tex2002ans

I attached my sigil_clips.ini in a ZIP file if that helps... although there aren't many clips beyond the defaults.

I tested your clips with multiple Sigil instances with the latest Linux build (with Qt 5.7.0) and couldn't reproduce this issue.

Are there any specific steps on Windows 7 machines that I need to follow to cause the disappearing clips bug?

[KevinH]

Originally Posted by Tex2002ans

Now speaking of bugs, I ran into a very obscure one. I sent the details in a PM to KevinH many moons ago but never got a response. I will fish that one out and see why I didn't post it publicly, and see if it still is buggy in the latest version.

If I remember correctly it had to do with Exporting/Importing Saved Searches, and differences between Windows/Mac's files with Carriage Returns + Line Feeds.

I am probably the only person in a thousand years who actually tried/used/knew about that functionality.

Sorry I just that missed that in my PM. Just responded. Not a bug. Your hand-crafted ini file included a utf-8 BOM which it should not have.

No proper utf-8 file needs a BOM (byte order mark) as 8-bit bytes do not have a byte order!

A BOM really makes sense when using an encoding such as utf-16 as it will clearly demonstrate if the the utf-16 (16 bit values) values were written in Big Endian or Little Endian byte order. (ie. utf-16-le vs utf-16-be)

When you export your saved searches, Sigil properly handles the cr/lf issues and properly creates a utf-8 encoded file that can be read in on any platform that Sigil runs on.

If you hand-create an ini file using a text editor, make sure it outputs utf-8 **without** a BOM (as they are meaningless for a utf-8 encoded text file) or post process it to remove the BOM mark if you want it to load on any platform (Mac, Linux, Windows) running Sigil

KevinH

[Tex2002ans]

Originally Posted by Doitsu

Are there any specific steps on Windows 7 machines that I need to follow to cause the disappearing clips bug?

Nope... I think Mister L covered it. I don't suspect we are really doing anything special besides having 2 or 3+ instances open at the same time.

Sometimes I have had the clips disappear when opening the 2nd EPUB, sometimes the 3rd, and sometimes it doesn't happen at all.

Originally Posted by KevinH

Just responded. Not a bug. Your hand-crafted ini file included a utf-8 BOM which it should not have.

Ahh I must have missed that when trying to look at differences between the 3 test cases!

But Windows Sigil was able to Import those test files (even the ones with the BOM), but the Mac Sigil failed. Is that still the case in 0.9.6? (I don't have a Mac so I can't test).

[DiapDealer]

I'm still trying to get it to happen (the disappearing clips) with the stock v0.9.6. Can't determine whether the newer version of Qt fixes it until I can get it to mess up with current version.

[JustinThought]

Originally Posted by DiapDealer

Yes, the CSS centering issue has been resolved and the fix will be in the next release. There's not however, going to be an intermediate/unofficial release that fixes only that issue. We are rapidly approaching the time for a 0.9.7 release, though, so hopefully it won't be too long of a wait.

I guess I better quit procrastinating, in that case. I have been formatting all my Dean Koontz books in "my preferred format," and I noticed one funny little thing occurring on a couple of books.

I have to preface this by saying, Dean Koontz structures his books differently nearly every time. Almost always he has "Part 1 (or I)" "Part 2 (or II)" etc.; and often he'll break those parts down into subsections. The particular books I've seen this anomaly on are those that have Roman Numeral sections, which I coped with by using a monospace font only on the sections within my Table of Contents.

The coding may well not be perfect; I'm a novice, as some of you know already. However, with some of the sections in the TOC, each time I do a save, Sigil adds one more blank line between the sections. I have included screenshots of the results of three saves. Because I tend to save at the slightest provocation, this has caused a rather large space between those sections, when I go back and look at it.

If the problem is because of something I have coded badly, I'd appreciate your feedback.


I'm also including the e-book itself, with the text stripped out so I don't step on anyone's copyright.

edit: book removed, apparently I didn't cut enough out of it to prevent problems with copyright. My bad.

It's not a life-changing problem, but I just thought you should know.

And I have to add to the sentiment expressed by others here, THANK YOU VERY MUCH FOR GIVING US THIS TOOL! I spend a lot of my time looking at the Sigil window on my computer screen.

[DiapDealer]

Originally Posted by JustinThought

However, with some of the sections in the TOC, each time I do a save, Sigil adds one more blank line between the sections. I have included screenshots of the results of three saves. Because I tend to save at the slightest provocation, this has caused a rather large space between those sections, when I go back and look at it.

The blank line being added in Code View doesn't affect the rendering in Book View. It shouldn't really be happening, but I haven't had a chance to see WHY the line is being added each time (but I can replicate it). It's got something to do with the non-breaking space entity being used outside of a block-level element.

[JustinThought]

Originally Posted by DiapDealer

The blank line being added in Code View doesn't affect the rendering in Book View. It shouldn't really be happening, but I haven't had a chance to see WHY the line is being added each time (but I can replicate it). It's got something to do with the non-breaking space entity being used outside of a block-level element.

Yup, that cleared the problem up. I placed each of the sections within an unformatted <div>, and the problem disappeared. It's probably better discipline anyway, since there are the Part descriptions outside of a block-level element too.

Because it doesn't affect the book itself, I would think you'd put that on your priority list at "Well, everything else is perfect, I think I'll take a look at it now." :-)

Thank you!

[KevinH]

FWIW,
loose text and entities are technically not allowed inside the body tag (ie. having the body tag be its immediate parent). They should properly be wrapped inside of some other tag like div, p, blockquote, etc, etc.

KevinH

[JustinThought]

Originally Posted by KevinH

FWIW,
loose text and entities are technically not allowed inside the body tag (ie. having the body tag be its immediate parent). They should properly be wrapped inside of some other tag like div, p, blockquote, etc, etc.

KevinH

These actually were inside a <div> block, but it wasn't very immediate. My first <div> immediately followed the <body> with the termination preceding the </body>. (Well, actually there was an <h3> block before the <div>.) So it was technically correct. Just wasn't working. So placing that specific block of activity within additional divisions seems to have cleared the problem up.

The patient seems to be perfectly healthy. We don't know why he died.

I'm re-upping a stripped-out version with only the Contents page where the problem exists. Maybe you can tell me what I might have done wrong. (Or at least you might get a laugh about how I accomplished my desired results )

[theducks]

Looks fine to me (and Validates in Calibre sans the missing links)

Block Level tags can not be split. Check your nesting ( pretty formatting visually helps)

<p>
<div> x</p> 
</div>

You went to a lot of trouble to make a narrow TOC.
Then you have the 'PART <timestamp>' which made it wide.
Another <br /> needed?

<div>

  <a href="../Text/102-004-001.xhtml">PART TWO</a><br /> Wednesday, 5:30 P.M.-11:00 P.M.<br/>

...
</div>