PageEdit-0.9.5 Released

[DiapDealer]

PageEdit-0.9.5

For the impatient, the binary files (and source) can be found as assets at the bottom of the PageEdit Github Release page.

PageEdit-0.9.5 is is primarily a new features release.

One of the major new features of this release is the ability to pass all xhtml files in the spine in Reading Order to PageEdit via opening the OPF.
Make sure to check out the New Features Synopsis and the New Features Video in the downloads section of the Github release page.

Installing PageEdit on Windows

Here is a more complete list of the changes:

New Features

• add the ability to pass all xhtml files in the spine in Reading Order to PageEdit
  via opening the OPF. Allow quick file navigation via navigation menu and next
  and previous arrows keys.
• add a Edit vs Preview mode toggle icon that will allow links among xhtmls files in the spine
  to be active and work (in Mode: Preview)
• installed a QtMessage handler to create a debug log file controlled via a
  PAGEEDIT_DEBUG_LOGFILE environment setting, to simplify user bug issue feedback

Bug Fixes

• fix macOS specific launch bugs due to bug in canonical files and timing of Apple events
• make sure jQuery is loaded before trying to manipulate a file by imporving web load sequence
• use GetEnvironmentVar to uniformly access Environment Vars in a cross platform manner
• disable prev and next navigation buttons when only one input xhtml file exists

[eschwartz]

Still waiting to see how packaging webengine dictionaries for Arch Linux users goes... I think I might have news soon, watch this space for details : https://lists.archlinux.org/pipermai...er/029666.html

[un_pogaz]

The new navigation and reading is so much easier than in pure Sigil.
A window/panels for view and use the TOC would be a good addition, but this is very secondary.

BTW, Bug report: If you open PageEdit in ereader mode (content.opf), close sigil (but not PageEdit) and then try to navigate to a new XHTML page => PageEdit freeze and crash.

[Springbok]

IT looks good, thanks. It is a big help for me at the final state of the book editing before publishing.

I would still like to see couple of dictionary maintaining functions present under Sigil (add word to dictionary, Ignore etc.) and then I am 100% satisfied.

[KevinH]

Yes, closing Sigil underneath PageEdit would be a huge no-no. Sigil is supplying the unpacked epub (that Sigil unpacks to its own temp files) to another app which will be erased when you close Sigil. So you effectively gave paths to files to PageEdit that no longer exist. Try deleting all the xhtml files out from under any e-reader while actively reading and it will have similar issues

If you do not need or want Sigil open, then unzip a copy of the epub you want to work on to someplace and then open its OPF file in PageEdit directly.

This might be a good use for Sigil's FolderIn and FolderOut plugins. If you have a book in Sigil, you can use FolderOut to save it someplace. You can safely close Sigil. Fire up PageEdit and do your thing. Then when you leave PageEdit, you can use Sigil's FolderIn plugin to get all your changes.

Otherwise, no closing Sigil behind PageEdit's back. You can of course minify Sigil at any point, just not close it as it will delete its files to clean up after itself.

Originally Posted by un_pogaz

The new navigation and reading is so much easier than in pure Sigil.
A window/panels for view and use the TOC would be a good addition, but this is very secondary.

BTW, Bug report: If you open PageEdit in ereader mode (content.opf), close sigil (but not PageEdit) and then try to navigate to a new XHTML page => PageEdit freeze and crash.

[KevinH]

Sorry that can not be done as the spellcheck code used by PageEdit is internal to Qt's QtWebengine which does not support any of that. When and if, QtWebEngine supports that, we will to. But unfortunately Qt uses a very different approach.

Originally Posted by Springbok

IT looks good, thanks. It is a big help for me at the final state of the book editing before publishing.

I would still like to see couple of dictionary maintaining functions present under Sigil (add word to dictionary, Ignore etc.) and then I am 100% satisfied.

[KevinH]

@eschwartz,
I was not aware that there were still issues with QtWebEngine's license according to some linux distributions. The Chromium license quoted in that mail thread seems like a pretty straightforward, no advertising, do not sue me, style BSD license.

Do you know of a source that discusses the "licensing issues" people have with QtWebEngine specifically?

Originally Posted by eschwartz

Still waiting to see how packaging webengine dictionaries for Arch Linux users goes... I think I might have news soon, watch this space for details : https://lists.archlinux.org/pipermai...er/029666.html

[eschwartz]

The GNU Free System Distribution Guidelines considers chromium itself to be not-compliant because it is a huge, huge heap of code which contains e.g. non-libre code for unrar, various media codecs that require it to be built with --enable-proprietary-codecs, and generally code that has "unknown licensing". It is an 11 year old project which was not, originally, proactive about double-checking the licenses and dotting all the i's and crossing all the t's, so it is plausible there are interesting things lurking in corners.

https://libreplanet.org/wiki/List_of...romium-browser

Its status is officially "unclear, therefore the GNU FSDG refuses to condone it". Some distributions take it on faith that Chromium developers say they have the right to all the code (minus obvious things like proprietary codecs or third_party/unrar/src/*.cpp) while others reject it entirely.

The standard reference for chromium (the place where the discussion about this issue began) is https://bugs.chromium.org/p/chromium...etail?id=28291

...

Qt WebEngine is another kettle of fish entirely. And here, FSDG-compliant Linux distributions are under the impression that WebEngine "embeds all of Chromium" and should therefore be tarred with the same brush as Chromium (whatever that brush may be, currently it is "I don't trust the licenses to be complete"). Meanwhile the Qt and KDE developers claim they disable and strip out tons of source, and the parts that they keep -- mostly lower level stuff -- aren't problematic even if Chromium itself is. Some background:
https://labs.parabola.nu/issues/1167
https://bugs.kde.org/show_bug.cgi?id=374808#c4
https://lists.qt-project.org/piperma...ry/000409.html

[KevinH]

According to Qt's wiki:

Qt WebEngine uses code from the Chromium project. However, it is not containing all of Chrome/Chromium:

Binary files are stripped out
Auxiliary services that talk to Google platforms are stripped out
The codebase is modularized to allow use of system libraries like OpenSSL
We do update to the latest Chromium version in use before a Qt release. After a release some bug fixes and security patches are backported. For LTS releases of Qt we might also update Chromium in a patch level release.

And for all of the pieces QtWebEngine uses, it lists the third party licenses here:

https://doc.qt.io/qt-5/qtwebengine-licensing.html

So I understand there still might be concerns for Chromium on the whole and Electron, I am not sure why QtWebEngine is being painted with the same brush especially now after they have made things clear on their website and with all of the Licenses used by QtWebEngine pieces.

So are Sigil and PageEdit, post the port to QtWebEngine) actually in danger of being blacklisted on some Linux Distributions? Will that also impact Calibre with its "engine" port to QtWebEngine in the future?

The funny part is the primary reason we moved from WebKit to WebEngine was that the QtWebKit version was not regularly maintained and it suffered from huge memory leaks when any significant javascript was used, and had no security fixes in a long long time, etc. Even with annulen's work to update WebKit the first time, it was not really suitable for those reasons. And porting to QtWebEngine from QtWebkit is not trivial as each brings unique problems with it.

KevinH

Originally Posted by eschwartz

The GNU Free System Distribution Guidelines considers chromium itself to be not-compliant because it is a huge, huge heap of code which contains e.g. non-libre code for unrar, various media codecs that require it to be built with --enable-proprietary-codecs, and generally code that has "unknown licensing". It is an 11 year old project which was not, originally, proactive about double-checking the licenses and dotting all the i's and crossing all the t's, so it is plausible there are interesting things lurking in corners.

https://libreplanet.org/wiki/List_of...romium-browser

Its status is officially "unclear, therefore the GNU FSDG refuses to condone it". Some distributions take it on faith that Chromium developers say they have the right to all the code (minus obvious things like proprietary codecs or third_party/unrar/src/*.cpp) while others reject it entirely.

The standard reference for chromium (the place where the discussion about this issue began) is https://bugs.chromium.org/p/chromium...etail?id=28291

...

Qt WebEngine is another kettle of fish entirely. And here, FSDG-compliant Linux distributions are under the impression that WebEngine "embeds all of Chromium" and should therefore be tarred with the same brush as Chromium (whatever that brush may be, currently it is "I don't trust the licenses to be complete"). Meanwhile the Qt and KDE developers claim they disable and strip out tons of source, and the parts that they keep -- mostly lower level stuff -- aren't problematic even if Chromium itself is. Some background:
https://labs.parabola.nu/issues/1167
https://bugs.kde.org/show_bug.cgi?id=374808#c4
https://lists.qt-project.org/piperma...ry/000409.html

[DiapDealer]

Originally Posted by KevinH

So are Sigil and PageEdit, post the port to QtWebEngine) actually in danger of being blacklisted on some Linux Distributions?

If so, it would be a very, very small faction. All of the major players that I would concern myself with are packaging QtWebEngine (though I could have missed a few). Many are behind the curve on Sigil in general, but I haven't seen any I would worry about who didn't have QtWebEngine packages they COULD use to package Sigil if they wanted to (provided the Qt5.9.x bare minimum requirement, of course).

[KevinH]

Good to know!

Thanks,

Originally Posted by DiapDealer

If so, it would be a very, very small faction. All of the major players that I would concern myself with are packaging QtWebEngine (though I could have missed a few). Many are behind the curve on Sigil in general, but I haven't seen any I would worry about who didn't have QtWebEngine packages they COULD use to package Sigil if they wanted to (provided the Qt5.9.x bare minimum requirement, of course).

[eschwartz]

I think this should only be the case for FSDG distributions, of which there is a fairly short list to be seen here: https://www.gnu.org/distros/free-distros.html

None of these distributions have WebEngine available at the moment, and thus, none of them can have the most recent Sigil release installed. Once the calibre port is complete, they won't have that either -- this is one of the reasons I would like to finish the Python 3 port sooner rather than later, since regardless of my practical disagreement with them, I think it would be great if they could at least freeze on an old version that supports Python 3, rather than freeze on an old version that is stuck with Python 2.

I've provided guidance to the Parabola developers that they should freeze Sigil at the last version to use Webkit, on the rationale that it shouldn't stop being as useful as it used to be... that is all I can do for them, they will either have to freeze packages at old versions or complete the stalled license review of chromium/webengine.

[DiapDealer]

Originally Posted by eschwartz

I've provided guidance to the Parabola developers that they should freeze Sigil at the last version to use Webkit, on the rationale that it shouldn't stop being as useful as it used to be...

Thanks for that. It's easy to forget that 0.9.14 is still a perfectly serviceable epub2/3 editor.

Though I freely admit that I'm a little surprised I'm not at least familiar with the names of any of those distros. As someone who got his *nix start downloading FreeBSD to 3-1/2" floppy's with a 14.4 modem, I'm a little embarrassed (as well as a bit encouraged--at least for Sigil's future).

[un_pogaz]

@KevinH I know how Sigil works, that PageEdit encounters an error in such circumstances does not surprise me. What I wanted to point out is more like the order of a "unhandled exception".
A message "The request file does not exist" will therefore suffice.

[KevinH]

Can't easily be done. Imagine deleting a file during an active file read operation. That is what QtWebengine is facing in PageEdit when you close Sigil. This is not a loss of network situation. The delete can happen just when the page resources are starting to be read from the file. So checking if a file exists is not enough.

And since it is a separate process an on close event handler won't work, and the file reads are being done in separate threads deep inside of QtWebEngine.

I will try to add more file exists checks but deleting any resource as it is being actively loaded is going to still be an issue.