Sigil-1.7.0 Released
 

Sigil-1.7.0

Sigil-1.7.0 represents a mix of bug fixes and new features for both epub2 and epub3.

Bug Fixes

• Workaround to ensure the Saved Searches Controls editor widget is movable on all platforms
• Make the External Xhtml Editor Button/Feature work with both PageEdit and non-PageEdit editors again
• Fix Preview sync when CV transitions from xhtml to css and back to xhtml
• Fix Preview sync when Find and Replace opens new tab with search target
• Fix Preview sync when Validation error clicked on
• Fix Preview sync when mathml is being used (compensate for mathjax changes)
• Fix mathml use when external MathJax directory is specified in builds on Linux
• Prevent Sigil from loading any manifested mimetype file from bad epubs, give load warning
• Make Spellcheck dialog use double-click to control search in CV, to speed paging word list.
• Prevent duplicate translated semantic names
• Fix heading tool issues after self-closed BLOCK tags
• Prevent stack overflow crashes in pcre lib due to recursion with some valid regex
• Fix second window opening on macOS when first launching app with file
• Remove [other.] semantic indicators for epub2
• Fix crash in CSS Selectors Report when using Filters

New Features:

• added Find Replace Regular Expression validator
• added SIGIL_DISABLE_VERSION_META environment variable to control writing of Sigil Version
• enable JIT compiler for pcre library to improve regex look-up performance
• update the pcre library to version 8.45 (Final EOL)

Notes:

Sigil 1.7.0 can be downloaded from Sigil's website: https://sigil-ebook.com/blog/sigil-1.7.0-released.

The latest version of the Sigil User Guide can always be downloaded from the Sigil website, or from its own GitHub repository.

Three new e-Reader plugins for Sigil have been built to help users see what their ebook might look like in real e-readers while still inside Sigil. See this post for descriptions and links.

Please check the Sigil website for important Sigil support links, additional resource downloads, and platform-specific trouble-shooting tips/requirements.

Mac users should still download and install ActiveState’s ActiveTcl Community Edition to utilize plugins that use Tk/Tcl GUIs. More here.

Mac users should also check out the website entry on the New Release File Format.

PGP Fingerprint (for signed tags and source archives): All binary (and source) downloads can also be found as assets at the bottom of The Sigil-1.7.0 Github Release page.

Post reserved for future use.

Thank you. And a much more friendly web page too! What you came for, clearly visible, right at the top. Nice!

:thanks: for 1.7.0!
Love the new website!

Thanks for all your hard work with Sigil - it is very much appreciated.

Like the others I think the new website is a huge improvement. As exaltedwombat said the download links are right there just where you need them.

Well done team! :2thumbsup

Am I the only person who prefers the github page, particularly since it went light text on a dark ground. And its log first, links second layout 'forces' me to read the log ;)

What's next?

BR

Github didn't "go" light text on black background. You chose their dark theme at some point after it was offered. The default is light.

And no... Sigil's new website will not offer a similar user choice. Though I may choose to change the theme's skin from time to time. ;)

Besides... no one's forcing you to use the new website. You're free to use github's dark-theme, log-first, traditional Sigil release pages for just as long as you like. :D

Out of curiosity: did you ever utilize the old Wordpress sigil-ebook.com website this new one replaced?

Seems like apples and oranges to me.

The new website isn't meant to be a replacement for GitHub (I don't think). It's a replacement for the old Wordpress site that didn't seem to have too many fans.

I'll continue going to GitHub out of habit and familiarity, but I think the new website is a nice option for new users and those who find GitHub too technical.

Exactly right. We traded one light-themed Wordpress sigil-ebook.com (which--let's face it--was fairly worthless) for a new light-themed sigil-ebook.com that we can better integrate/automate with Github. Sigil's GitHub code repository stays exactly as it is/was. We couldn't really change that if we wanted to.

That's the plan. Those familiar/comfortable with GitHub can continue exactly as before. Those looking for a more traditional website with prominent download buttons for the latest versions of everything can make use of the new website.

Nothing lost; only things gained.

Personally I find using GitHub confusing when trying to locate the correct link to download Sigil, but that's probably just me.

The clearly labelled download download buttons on the new site suit my old brain much better.

Utilize conciously? no.

Inadvertently end up there? yes, IIRC when looking for the manual.

Odd about the Github theme, I haven't logged in for years - and I'm not sure an anonymous user can set it, maybe it was offered as pop up and I clicked 'yes'.

And another reason I probadly don't 'like' the new site is because it is colour-matched to the Evernote support site - about which I'll say no more :( :D

Have tou ever tried to run PageEdit from the calibre book editor, it works fine for XHTML files, but not for the OPF file. I understand why, and its probably not easily fixed because it relates to where the epubs are unarchived etc. But if it could be fixed I'd bee [sic] a very happy camper ;)

BR

Sorry, not much I can do there, that's all calibre. The Open With feature of calibre's editor doesn't seem conducive to opening multiple files in an external program. It seems to move the single file to be edited to a temporary location, where upon finishing the edits, any changes can then be subsequently imported into the original file or discarded.

PageEdit properly opens the opf file and dutifully parses it for the locations of all of the epub's various resources, but it can't find them because they're not where the relocated opf file says they should be. Even if we could anticipate where the opf is being moved to (and there's no way we could), the calibre feature wouldn't be watching the other resources for changes, so nothing would get updated.

The case is a bit too special. When PageEdit "opens" an opf file, the opf file isn't actually what's going to be opened/edited in PageEdit.

Nice job with the new website.

Did anyone notice that in 1.7.0 the search direction selector does not seem to do anything?
It only searches "Down" at the moment, not "Up". It worked fine in 1.6.0.

My normal language is Dutch and the options are translated as "Omhoog" and "Omlaag". I sometimes use a AutoHotKey script to do some changes and than this is a bit awkward because both options start with "O". Maybe "Op" en "Neer" would be a nice alternative translation, that give different starting letters.

Translations are handled by volunteers on Transifex. Please pass along your request to the nl translation team at the Sigil project on Transifex.

There were no search direction code changes in Sigil-1.7.0 since Sigil-1.6.0 so it must be caused by something else that did change. I will look into it.

:shame:
I do not know what was going on, but I have closed Sigil and re-opened it with the file I was working on, and all is fine again.

Hmm ... that is strange. If you can ever recreate the issue, please let us know.

ps. On my build, the up down search direction appears to work as before. So perhaps just a glitch of some sort?

That was my conclusion too, but I hoped you might have a trick up your sleeve :)

BR

Thanks for all the hard work!

I did find a bug that wasn't squashed - not sure if it was supposed to have been??

The preview window is still not updating to the correct place - not syncing with the code view. More precisely - when I make an edit in the code view (either manually or with find/replace), the preview will reposition elsewhere on the page... what I've noticed most often it will reposition to about the middle of the html file. The preview window will sync properly if I click on the code view window where some text is located.


Let me know if you need more detail!

Cheers,
Dion

I'll check, but that's the first I've heard of Preview not syncing correctly in general. There was the find/replace thing, and the attempt to get MathML closer, but other than that, I've not heard any complaints of Preview not syncing correctly after edits (til now).

It's definitely syncing how I expect it to (Preview syncs to the Code View cursor) on Windows 10 and Linux.

I am not seeing this either with Sigil 1.7.0 on macOS. Please provide a detailed sequence of steps to recreate what you are seeing. Please make doubly sure this is with Sigil-1.7.0 and not 1.6 as changes were made since then.

Clicking on Text or Tags makes Preview sync to it. Active editing in CV will force Preview to reload and then sync to where the cursor in CV is.

Here are the Preview syncing related bugs that were reported for Sigil-1.6.0 that should be fixed in 1.7.0:
So if you are seeing something else please let us know how to recreate it so we can track it down and get it fixed.

I'm confused as to what you're actually experiencing, @ Turtle91. In one breath, you say Preview isn't syncing when you make a manual edit in Code View:

Then in the next breath you say that Preview syncs properly when you click on text in Code View:
But since manual editing in Code View would naturally involve clicking on some text, I'm confused as to how the action of editing in Code View could both work and not work at the same time. :blink:

Also... if the xhtml file is large enough to be scrollable in Preview (and the area being edited is far enough away from the beginning or end of the rendered content that Preview is not scrolled all the up or all the way down) then sync will always put the content being edited smack in the middle of Preview's viewing window.

You're not under the impression that the cursor in Code View and the corresponding content being rendered in Preview should always line up vertically are you?

No matter if your cursor is at the top, middle, or bottom of Code View, Preview will always try to sync that content (where the cursor is) to the middle of Preview. Unless, of course, syncing the content causes Preview to scroll to the very top, or the very bottom of the rendered page.

Our sync between Code View and Preview was never intended to keep the content in both exactly in line with each other vertically. That's not possible. The goal is to keep the portion of the file you're editing in Code View IN the Preview Window. Near the middle if possible. So you can immediately see the results of your changes. It's the same for the reverse--Preview to Code View sync. The difference there being the text in Code View gets highlighted.

You may be aware of all of this already. My apologies if so. I just want to make 100% sure we're all on the same page as to the expected behavior of syncing between Code View and Preview.

Unless you have an epub or a situation where the above behavior is not happening as described (which I'm not at all ruling out), CV<->PV sync is working for us the way it was designed it to work.

I'm just trying to make sure this is not matter of expectations being different rather than an actual bug.

I just tested 1.7.0 again with find and replace in a long xhtml file finding the word "the" and replacing it with "athe" and Preview properly scrolled along with the Find and Replace actions as described above by DiapDealer.

So we will need your help to track down what you are seeing.

OK...I was a little worried there that I had downloaded, and NOT installed, the new version...and was re-reporting an old problem. (The original report in Ver 1.6) I think when BeckyEbook mentioned she also had a problem it focused on the find/replace aspect and I didn't follow-up with the other part of the bug. :o

I just confirmed that the other part is still present in windowsx64 version 1.7

Easy steps to replicate what I was talking about before:
- Open an html file that is "longer" than your preview window
- Preview displays the top of the file (img1)
- Scroll the code view down a bit; such that the preview will reposition when you click in code view...and click in code view
- Preview updates such that the point you clicked on is roughly in the middle (vertically) of the preview pane (img2)

So far all of this is normal and expected behavior.

- Now edit the code view...either by changing the text (such as adding a space), or deleting/changing a class/style, etc.
- Preview "refreshes" and the point you were editing is no longer in the same position (vertically). Most often - for longer chapters - the position you are editing is no longer even visible in the Preview window. (img3)
- If you mouse-click on the same position you just edited, the preview window refreshes again putting that point roughly in the middle (vertically) of the preview window. (img4)

The same thing happens when you click on the style sheet tab, or ctrl-click on the class name. The Preview window will "refresh" to some other position - most often, for longer chapters, to a point where the position you were editing is no longer in the preview window. (img5)

When you make a change to the style sheet, the preview window will do a "double refresh"(???) It will flash to show the point you were changing, but then immediately refresh again to show the same (wrong) point it had previously.

This makes it slightly difficult to see the effects of your css edits until you go back to the code view on the html sheet and click on the point to re-sync the preview pane.

Here is a Lorem-Ipsum test Ebook and my Sigil.ini if that helps.

I just tried your test on my mac by adding a space to the text and Preview synced just fine after it automatically reloaded the page following the edits with no need to click. I see from your images it is obviously not doing that for you.

Not sure why. Perhaps this is platform specific? The class clicking and return bug was fixed for macOS in Sigil-1.6.0 too.

So maybe this bug truly is platform specific. Let's wait to see if BeckyEbook or DiapDealer can recreate what you are seeing on their Windows builds.

My very rough thoughts as to maybe where to look, possibly... ;)

Mouse clicking in code view seems to sync preview properly.
Editing in code view (not clicking) causes preview to refresh improperly.
Switching to a css sheet causes preview to refresh improperly.

Are these possibly different "refresh routines", or do they send different parameters to the same routine???

The problem is that code is identical across platforms, and I am not seeing any of this on macOS but did see and was able to fix those issues when reported for Sigil-1.6.0.

But with Sigil-1.7 on macOS, I am just not seeing what you are seeing.

Here is a screen cap following your instructions after editing a line to add the word "Hello" to the start of the line and waiting for Preview to reload.

As you can see it is syncing just fine.

I also try with Go-To-Link-Or-Style on red and then back and it all worked just fine.

So this is going to be very hard for me track down on macOS as I can not recreate it.

Let's hope someone (Doitsu, BeckyEbook, DiapDealer, etc) using Sigil-1.7.0 can recreate what you are seeing on Linux or Windows. If not, I can try and create a debug build for you that adds a bunch of QDebug() output related to Preview position that you can capture in a debug log file so we see what is going on.

Refresh works as it should for me.

If I make an edit to Turtle's ebook the preview window stays in the same place, and no mouse click required to reflect the changes.

Sigil 1.7.0 on Windows 10 64 bit.

I checked all steps twice and it works fine for me.

But…
I did a full test, in which I also overwritten my sigil.ini file, and then discovered that the issue really exists.

So I started to analyze step by step which line in the configuration file was causing the problem and found it.

The problem occurs at non-100% magnification in the preview window (both zoom in and zoom out).

zoom_preview in [user_preferences] section in your sigil.ini file

@Turtle91: Set the zoom for preview window to 100% until the issue is resolved.

Interesting. I admit I never really use the zoom feature, so I never would have noticed. I'll test it out when I get a moment.

Wow! Excellent detective work!

I can now recreate it. It seems there are bugs in QtWebEngineView with Zoom being set needing to be set-again after each page load.

The problem is it must be done before the location to scroll to is set but after the page's resources are loaded.

I will try to figure out some way to get it working properly.

Thanks!

KevinH

Okay, this is really messy. It seems a call to setZoomFactor for a QWebEngineView does not complete instantaneously nor is it immediately reflected in the internal state of the QWebEngineView after the call returns.

So any attempt to immediately scroll and centre the Preview Window on a location fails as the window inner height returned by javascript is incorrect for zoom values different from 100% until the zoom is done completely.

The interface for setZoomFactor is not designed to be asynchronous and so there is no way I know about to check if the zoom is complete yet (ie. to wait until setZoomFactor has completed and be reflected inside the QWebEngineView).

To make the situation worse, anytime a page is loaded, its internal zoom value is seemingly set back to 100%, requiring us to use setZoomFactor each time and then wait some amount of time before trying to scroll.

So a delay is needed between the call to Zoom (setZoomFactor) and when we try to scroll to a location. Among a bunch of other changes needed, I have tried to add that delay in PreviewWindow.cpp.

So right now, a delay of 50ms seems to be sufficient when set in DelayedScrollTo by a singleshot in PreviewWindow.cpp once the zoom is done. I have no way to know if that is enough for all platforms. I tried with a delay of 30ms and it fails.

I have pushed this approach to master. So we need people who can pull and build on Windows and Linux to see if this approach can be made workable for all platforms so that Preview syncing when Preview is not set to 100% works.

Please let me know what you find if you do get a chance to play around with this test case.

I built a version for Windows and it seems ok now.

That's puzzling as I can't replicate Becky's findings.

I always have my preview window set to 80% and the synch between code and preview when editing the code works as expected for me.

https://www.mobileread.com/forums/at...1&d=1627919338

https://www.mobileread.com/forums/at...1&d=1627919338

@Ashjuk: Are you sure you have the 80% preview window?
The zoom is independent for the Code View and the Preview window.

The same zoom control works for both. So click in Preview after it loads and then move the zoom slider and it should only zoom the Preview.

Thanks for testing it. I am going to also try moving the call to setZoomFactor even earlier to see if that helps.

KevinH

We had a bug not all that long ago where the Zoom was resetting itself to 100% under certain conditions, but I can't seem to track it down now, to see just how we fixed it. I don't think it had anything to with what we're seeing now, but I just want to make sure that our fix for that (which was to reapply the zoom) isn't somehow exacerbating the problem and breaking sync.

I won't be able to test any builds on Linux until later this evening.

Yes. I have the preview set to 80% and the code view to 100%. Depending upon which window I have clicked the slider changes to reflect my setting.
If you look at the images I attached to my last post you can see the slider is at 80%.


I discovered that some time ago, as I just said to Becky, I have code set to 100% and preview to 80%.

Just a little puzzling that the 'bug' does not seem to affect me despite my having the preview window zoomed out.

It depends on the length of the file and where you are IN it as well. If the edits you're making are close enough to the top (or bottom) of a relatively small file, it's possible for the recent edit to still remain visible in the Preview Window even after the incorrect sync attempt. Try a good long xhtml file and scroll to the middle of it and see if that makes a difference.

I can see in the original images you posted that you're scrolled nearly to the bottom of the Preview Window. And that although the sync is still being botched after your edit, it's just not moving the needle enough to make a huge difference.