Mobileread
PageEdit-0.9.5 Released
#1  DiapDealer 09-03-2019, 09:44 PM
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

Bug Fixes
Reply 

#2  eschwartz 09-03-2019, 10:10 PM
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/pipermail/arch-dev-public/2019-September/029666.html
Reply 

#3  un_pogaz 09-04-2019, 04:48 AM
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.
Reply 

#4  Springbok 09-04-2019, 05:59 AM
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.
Reply 

#5  KevinH 09-04-2019, 08:14 AM
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.

Quote 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.
Reply 

#6  KevinH 09-04-2019, 08:17 AM
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.

Quote 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.
Reply 

#7  KevinH 09-04-2019, 10:47 AM
@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?


Quote 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/pipermail/arch-dev-public/2019-September/029666.html
Reply 

#8  eschwartz 09-04-2019, 11:29 AM
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_software_that_does_not_respect_the_Free_Sy stem_Distribution_Guidelines#chromium-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/issues/detail?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/pipermail/qtwebengine/2017-January/000409.html
Reply 

#9  KevinH 09-04-2019, 12:14 PM
According to Qt's wiki:

Quote
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


Quote 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_software_that_does_not_respect_the_Free_Sy stem_Distribution_Guidelines#chromium-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/issues/detail?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/pipermail/qtwebengine/2017-January/000409.html
Reply 

#10  DiapDealer 09-04-2019, 01:33 PM
Quote 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).
Reply 

  Next »  Last »  (1/5)
Today's Posts | Search this Thread | Login | Register