Another new Chinese Sigil fork

[KevinH]

If you remember we found a fork of Sigil called "sigil-modified" that ended up being out of date, bug ridden and not adding much value but had some interesting ideas. Furthermore the author of which never contacted us, or contributed anything back.

So there is now a new Chinese fork of Sigil called Sigil-Enhanced that has already added huge amounts of new code to their version of Sigil, even though it started with the old sigil-modified that we found was bug ridden.

It is being developed by a whole company: https://huggingface.co/3tic which according to them is "The AI community building the Future".

Hopefully they have found and fixed those bugs. And of course no-one from that project has contacted us or offered to contribute anything back to Sigil. I guess the whole idea of contributing back that made open source actually work is truly dead.

Point Google Translate at this github site:

https://github.com/3tic-project/Sigil-Enhanced

They seem to want to include a built-in interface to LLMs to automate cleanup tasks. Might be some good ideas there but if so, I hope they greatly improve the code quality from the earlier sigil-modified effort.

If anything appears to be a good idea, do let me know.

One thing I did learn is that a Singleton class that must exist the full time the application exists and is only deleted at application termination can not delete its own instance even if created by new. That is news to me. Especially since no pointers are stored to a Singleton class anyplace else by definition. But changing to a Meyers based Singleton by reference would eliminate the need, preventing any potential destructor recursion. I will look into moving to a Meyers based Singleton pattern in Sigil. So that's a plus.

[DNSB]

I gave a quick test to the release version. The Emmet tool was just as unimpressive as in the test Sigil version and after 5 minutes I disabled autocomplete. Further testing will have to wait.

The use of HarfBuzz looks interesting but since I do not do much in languages other than English, I really don't have many test documents for it.

[KevinH]

Interesting.

There is a whole "opencc" chinese conversion library added to convert between the different regional dialects of chinese and japanese. That at least makes good sense for a specialized Chinese version of Sigil. Same might be true for harfbuzz, but afaik, harfbuzz is already part of Qt.

They have also added a "mcp" interface to LLMs. And added some kind of "Live Plugin" environment but I have no idea of what it can handle or do. This required them to greatly grow the number of installed python modules.

Interestingly they kept the buggy prettifier code we tested that could not even handle inline tags properly, and the broken emmet code, the buggy pre-search feature called FindReplacePlus that caused crashes, the auto complete which was next to worthless when tested because xhtml tags are short, and kept the builtin epub3-itizer code all from "sigil-modified" as well.

So as far as I can tell, unless big improvements were made, these were not promising decisions.

I do think if you could use an LLM to handle complex corrections in the text and clean-ups without exposing that same precious text and ideas to an LLM to be absorbed or stolen, it might prove useful.

And it looks like they have built a whole unarchive zip file protection system to supposedly protect against malicious plugin zip archives. Silly, because any plugin itself must be trusted as it has full runtime privs. Plus our Unzip code safely forces all unzipped files into the target folder preventing them from overwriting anything outside their own folder. Again, a bit of a waste of time. Might make you feel good but truly accomplishes nothing. The plugin python code is running just like any other python program on your system with your full rights. And lots of code can test a zip archive for safety without unpacking it but once unpacked, it can do anything. An macOS and Linux running unzip -t or unzip -lv will show all final paths and file sizes if anyone is worried about a plugin zip file. They should be much more worried about the python code inside if they do not trust the source! My guess is they did this to start commercializing plugins, but I could be wrong.

They also added dragging and dropping resources into CodeView to add images and other resources to an xhtml file. Given how many crashes are caused by dragging and dropping inside Qt Editors over that last 10 years, I hope Qt fixed it.

They seemed to have expanded CV's Undo and Redo capability so that might be useful. And I am sure there must be some interesting changes and bug fixes someplace in their code but with many commit messages in Chinese, I am not sure I would ever find them.

Well good luck to them. I am sure many book authors will just love to hear that their epub editor uses AI and LLM to work.

It would be nice if they at least contributed back to us actual bug fixes they find in our code, (like the potential Singleton destructor recursion issue) but I fear this will be a one-way street like it has been so far.

[3333]

Hi KevinH and everyone,

I'm one of the maintainers of Sigil-Enhanced. English is not my native language, so I'm using translation software to help write this post. Please excuse any awkward wording or misunderstandings caused by the translation.

I came across this thread by chance. First, thank you for taking the time to look through Sigil-Enhanced and for pointing out the concerns you found.

I think there are a few things about the project that would be useful to clarify.

First, 3tic-project is not a company.

The name originally came from a small community/project group we created when we started working on a Japanese-to-Chinese translation model. Later, some other open-source projects were placed under the same organization. There is no company behind Sigil-Enhanced, and there is currently no plan to commercialize Sigil or its plugin ecosystem.

The reason Sigil-Enhanced exists is also quite specific.

The original goal was to make it easier for Chinese users to edit and clean up Japanese light-novel EPUBs.

There are many workflows that appear quite frequently in this particular community: Chinese Simplified/Traditional conversion, regional Chinese text conversion, CJK font subsetting, cleaning EPUBs converted from various Japanese e-book formats, fixing unusual paragraph structures, handling books containing very large numbers of resources, and various repetitive editing operations.

Because of that, Sigil-Enhanced is intentionally quite specialized. It is not intended to replace Sigil or become a general-purpose "better Sigil".

At the moment the project is still very much in an active feature-development phase. We are deliberately doing a lot of experimentation and "adding things" first, while also auditing the code inherited from sigil-modified.

This is one reason we have not immediately tried to upstream every change.

Some experiments may turn out to be useful, some may require redesign, and some may eventually be removed. I don't think it would be helpful to send upstream a large number of immature or highly specialized patches while those ideas are still changing.

Once the project and these implementations become more stable, however, I do intend to separate the generally applicable findings from Sigil-Enhanced-specific features. Bugs found in the common Sigil codebase, performance improvements that make sense for upstream, and the corresponding solutions can then be documented and shared with the Sigil project.

So I hope this will not remain a one-way street. We are simply not yet at the stage where I feel most of the experimental work is suitable for upstream submission.

The LLM/MCP work probably also needs some explanation, because its purpose is broader than simply "adding AI to Sigil".

There are actually two main goals.

The first is the obvious one: allowing an LLM to assist users with repetitive EPUB work such as layout cleanup, proofreading, structural corrections, checking consistency, and similar editing tasks.

It does not require a particular commercial LLM provider. The interface can also be used with local models. Sigil-Enhanced itself does not automatically upload EPUB content to an external service; what model or MCP host is connected is controlled by the user.

The second goal is more experimental and, from my perspective, perhaps more interesting.

Sigil's existing Python plugin system generally executes a plugin against a snapshot/copy of the EPUB. A Python plugin does not operate continuously against the live Sigil workspace and editor state.

For Sigil-Enhanced, I have been experimenting with a different Python plugin architecture that can interact with the current book session and workspace in real time, while still having controlled operations for reading resources, modifying them, importing files, previewing changes, creating checkpoints, and rolling changes back.

MCP provided a convenient way to exercise that new interface.

An LLM agent can perform combinations of operations that would otherwise require writing many dedicated test plugins. By asking it to perform increasingly complicated EPUB editing tasks, it becomes a kind of automated capability-coverage test for the new plugin system.

For example, when an agent fails to accomplish a reasonable editing workflow, it often reveals that the plugin API is missing an operation, exposes insufficient context, has an inconvenient transaction boundary, or cannot correctly synchronize some part of the live book state.

So part of the MCP work is effectively being used to discover what capabilities a future live Python plugin API still lacks.

The intention is therefore not to make every EPUB editing operation dependent on an LLM. The LLM happens to be a useful and unusually demanding client for testing the interface.

Regarding the archive extraction protection: I agree that this does not make an installed Python plugin safe.

Once Python code is executed with the user's permissions, the plugin itself has to be trusted. The archive protection is aimed at a different boundary: handling an untrusted ZIP/EPUB before its contents are accepted or executed.

In addition to path traversal issues, it attempts to deal with malformed paths, symlinks, duplicate or colliding paths, resource limits, unexpectedly large expanded files, extreme compression ratios, and ZIP-bomb-style archives.

It also makes failed extraction or plugin replacement easier to roll back cleanly.

So this is not intended to be a Python sandbox, nor is it related to commercializing plugins. It is simply defensive handling of potentially malformed or hostile archive input.

For OpenCC, the motivation is mostly the Chinese-language editing workflow. Simplified Chinese, Traditional Chinese, and regional variants often need more than a simple character-for-character conversion, so having this directly available for selections, individual XHTML files, or whole books is useful for the users this fork currently targets.

For HarfBuzz, although Qt already uses HarfBuzz for text shaping, the Enhanced feature uses HarfBuzz's font subsetting functionality directly. The goal is to collect the glyphs actually needed by an EPUB and safely reduce embedded CJK fonts, which can otherwise be very large.

As for the functionality inherited from sigil-modified — including Emmet, autocomplete, formatting code, FindReplacePlus, drag-and-drop behavior, and others — I don't assume that all of it is correct simply because it already existed.

Sigil-Enhanced initially used sigil-modified as a convenient starting point because it contained several workflow ideas that Chinese users had already found useful. Since then, we have been auditing those implementations, fixing problems, replacing parts of them, and adding tests.

Some of those older features may need substantial redesign, and if an implementation proves to be more trouble than it is worth, removing it is also an option.

Right now the project is still moving fairly quickly, so code quality and regression testing are areas I am actively trying to improve alongside feature development.

Finally, I want to emphasize that Sigil-Enhanced would not exist without Sigil.

Sigil provides the mature EPUB model, editor, validation infrastructure, plugin system, and years of maintenance that make these experiments possible in the first place.

The fork is mainly a place where we can experiment with workflows that are unusually important to Chinese and Japanese light-novel EPUB users without expecting upstream Sigil to accept every specialized feature.

When those experiments expose problems in the common foundation, or produce solutions that are genuinely useful outside this specialized fork, I am happy to share those findings with upstream once they have been properly isolated and tested.

Thank you again for looking at the project, and also for the criticism. Even where we may have different opinions about individual features, feedback from people who know Sigil's codebase much better than I do is useful for identifying areas that deserve another look.