Head's up for those who build their own.

[KevinH]

Just a head's up for those who build their own.

Given all the changes in native nested selectors and CSS 4, Sigil has opted to move to a completely new css parser, moving away from our old CSSTidy derived one. This new css parser is from lexbor.

See https://github.com/lexbor/lexbor

We are using just their css library, statically built. Sigil needed some slight css parser changes that the lexbor developer has agreed to but since those changes modify its abi, we must maintain our changes until such time lexbor is ready to release a new major version. Inside Sigil this code exists inside Sigil/internal/lexbor along side our gumbo version.

Lexbor also has a nice selector implementation we should take a closer look at and an html whatwg spec compliant parser and dom implementation we could move to when and if gumbo gets long in the tooth.

Next our current source code base uses a number of C++ singleton classes which were in desperate need of an overhaul. So each singleton class and surrounding code has been moved to use the Meyers form of the Singleton which should help speed Sigil startup time because of its lazy loading while more safely cleaning up after itself upon exiting Sigil. This change touches a large number of files in Sigil.

Third, I have borrowed code from the hostile Chinese Sigil-Enhanced fork, that should speed up BookBrowser refreshes. Wish they would have contributed that back since they took all our code and never even let us know but ...

Fourth, I have also modified AddExisting to speed up bulk replacement of image files during AddExisting or our DropZone. This time without breaking anything!

So if you do build your own, please start with a fresh build and fresh cmake run to make sure none of the changed files are missed as many new files have been added.

Lastly if you get a chance please test out the single line css reformat and multi-line css reformat and "go to style" in CodeView to make sure I have not broken anything when interfacing their css parser library to our code. It all seems to work for me but more testing is always welcome.

[DNSB]

For those using Windows who are interested in testing the new code, you can download the executable from: Sigil-2.8.1-Windows-x64-Setup.exe.

In my limited testing using my 512 images test ePub, it definitely feels faster. I haven't seen any other issues but I haven't had the chance to spend that much time testing.

[DiapDealer]

We also have a currently opt-in-only test in place for using the python regex module for Sigil's embedded Python routines instead of the re module (plugins will not currently be included in this test). The regex module more closely matches Sigil's PCRE regex then the built-in re module does. Especially where the Python Replace functions are concerned.

The bottom line is that if you build your own Sigil, and you'd like to opt-in to this testing (setting an environment variable), you'll more than like need to update the regex module used in your Sigil build environment. Anything version 2026.5.9 or newer should be fine.

Users of the official releases can opt-in to the test with no worries. The regex module in the official Sigil releases has already been updated starting with Sigil 2.8.1.

[BeckyEbook]

* Each subsequent use of "Multiple Lines Per Style" shifts the opening curly brace further to the right:

.test      {
  text-align: center;
}

* After using "Multiple" a few times, try "Single" – you'll see that the extra spaces are still there:

.test      {text-align:center;}

[KevinH]

Well that is strange. The selector itself is just not being trimmed on the right for some reason in the new library. I will look into adding something to compensate in our interface code.

Thanks for testing and finding that!

[KevinH]

That issue should now be fixed in Sigil master.

It was not their bug, but my interface bug as I chose to use raw css tokens character data to prevent replacements of escaped strings but did not clean them up before using them.

They are purposely left in raw data as a space after a selector segment but before the end must not be trimmed as it may indicate a compound selector.

FWIW, it was actually a lot of work to properly interface their css parser for our use both because it is a heavy callback design for speed and because it is designed to be actually used inside a browser and simply ignores anything it does not like (which is what the spec tells it to do)!

But in Sigil we need feedback on errors in some way to prevent running a reformat when the css itself is broken in someway, possibly ruining it. And we do not want to change the meaning a whole selector because of a missing ";" at the end of one of the properties values.

Either way, this should now be fixed.

I never thought to repeatedly run the reformatter during my testing. I should have.

Thank you for testing it and finding that bug!