Plugin Development

[DiapDealer]

Originally Posted by BeckyEbook

But now it is defined, plus it is the same color as Base.

Are you sure? It was my understanding that AlternateBase (in plugin_utils.py) is being assigned the same color as the Window role from Sigil.

https://github.com/Sigil-Ebook/Sigil...unner.cpp#L244

https://github.com/dougmassay/sigil-..._utils.py#L264

https://github.com/dougmassay/sigil-..._utils.py#L272

Unless Base and Window are the same color.

I'm not opposed to your suggestion, but I would ultimately like the actual system alternateBase color to be used. With a hard-coded color in plugin_utils.py being embedded in tons of Qt plugins, that might not be a realistic hope.

I'd rather we didn't have to do this (match_dark_palette) on Windows at all, but...

[BeckyEbook]

Of course – not Base, but Window.

[DiapDealer]

I went ahead and updated plugin_utils.py (and the light version) with your suggested color. Thanks!

[wrCisco]

Ok, I updated my copy of plugin_utils too.

One question for DiapDealer: the readme of the sigil-plugin-utils repository indicates the GPL v3 license but the notice at the top of each file shows the 2-clause BSD license. Is the latter the valid one or do you have another preference?

[DiapDealer]

I prefer the 2-clause BSD (more permissive than GPLv3). I think GitHub might have just defaulted to GPLv3 when I quickly created the repo. I'll try to make them match. Thanks.

EDIT: I think I got everything updated to match on GitHub. Thanks again.

[wrCisco]

I wanted to improve and generalize the first-words-then-everywhere wrapping of text for the plain text of QLabels, so I'm partially rewriting the code of my WrappingCheckBox widget to use QTextBoundaryFinder to split words and graphemes in a text, and I stumbled upon a small incompatibility between pyqt5 and pyside6: while in pyside6 you can iterate over qt enums, in pyqt5 you can't. Do you know if there is a more clever way to do what I'm doing with 'boundary_reasons' in the following function (an optional parameter which, if None, is assigned all the enumeration's values combined)?

from functools import reduce
from plugin_utils import QtCore

def tokenize_text(
            text: str,
            boundary_type: QtCore.QTextBoundaryFinder.BoundaryType,
            boundary_reasons: QtCore.QTextBoundaryFinder.BoundaryReason | None = None) -> list[str]:
        """
        Divide text in a list of tokens based on boundary_type.
        boundary types: Grapheme, Word, Line, Sentence
        """
        if boundary_reasons is None:
            try:
                # BreakOpportunity doesn't come up while iterating over BoundaryReason flags
                # (PySide 6.9), so I use it as the initializer of the reduce function
                boundary_reasons = reduce(
                    lambda x, y: x | y,
                    QtCore.QTextBoundaryFinder.BoundaryReason,
                    QtCore.QTextBoundaryFinder.BoundaryReason.BreakOpportunity
                )
            except TypeError:
                # PyQt5 doesn't allow iterations over Qt enums
                boundary_reasons = (
                    QtCore.QTextBoundaryFinder.BoundaryReason.StartOfItem
                    | QtCore.QTextBoundaryFinder.BoundaryReason.EndOfItem
                    | QtCore.QTextBoundaryFinder.BoundaryReason.MandatoryBreak
                    | QtCore.QTextBoundaryFinder.BoundaryReason.SoftHyphen
                    | QtCore.QTextBoundaryFinder.BoundaryReason.BreakOpportunity
                )
        tbf = QtCore.QTextBoundaryFinder(boundary_type, text)
        tokens = []
        pos = prev = tbf.position()
        while True:
            pos = tbf.toNextBoundary()
            if pos == -1:
                break
            if pos != prev and boundary_reasons & tbf.boundaryReasons():
                token = text[prev:pos]
                tokens.append(text[prev:pos])
                prev = pos
        return tokens

I found a couple of Stack Overflow answers that address the issue, but the solution proposed seems way too complex for my limited use case (https://stackoverflow.com/questions/...representation, https://stackoverflow.com/questions/...-typedef-for-q).

[KevinH]

Given it is only one enum and given PyQt5/Qt5 has no further development and therefore the enum will never be changed, your approach seems like the simplest and best.

That said, PyQt5 had a long life. Are there any earlier versions of this enum in Qt5 that changed? Maybe eyeball the history of the Qt source file that defines the Qt5 enum on github to see if it ever changed over its life. If not, you should be golden.

Update: It did change very early in Qt 5.0 from the final Qt 4.x series as per:
https://github.com/qt/qtbase/commit/...41ecc95fa976e9

But since that change happened to make Qt 5.0.0 you should be quite safe.

Here is the enum as stated in Qt 5.15.x. You should be good to go.

   enum BoundaryReason {
        NotAtBoundary = 0,
        BreakOpportunity = 0x1f,
        StartOfItem = 0x20,
        EndOfItem = 0x40,
        MandatoryBreak = 0x80,
        SoftHyphen = 0x100
    };

[DiapDealer]

I knowingly punted on trying to attain enum compatibility between PyQt5 and PySide6 with plugin_utils.

I agree with Kevin here. No need to get overly clever/complex for one enum. You could check to see if PySide6 is already in sys.modules rather than try/except, but there's no real advantage either approach would have over the other in my opinion.

[wrCisco]

Ok, thank you both!

[mrprobert]

Hi,

Long ago I wrote a tiny sed script to translate font units like small, medium, etc. into ems and rems. It worked well enough but it was getting to be a pain to use as it runs outside of the Sigil environment. Just for fun I used Claude AI to write a plugin based my script. I've attached the result along with documentation. I am interested in hearing about:

1. Any issues with the algorithm?
2. Is it a "conforming" plugin?
3. What do you think of the code?

Thanks for your time.

[Doitsu]

Originally Posted by mrprobert

2. Is it a "conforming" plugin?

No really, because Tk support will be removed in future Sigil versions.

BTW, you might want to add the following line to plugin.xml:

<autostart>true</autostart>

I'm curious about the use case. What kind of tool generates epubs that use:

font-size: small;

[mrprobert]

Originally Posted by Doitsu

No really, because Tk support will be removed in future Sigil versions.

Good to know, thanks.

I'm curious about the use case. What kind of tool generates epubs that use:

font-size: small;

I've seen this kind of construct in older files, mostly ancient epub2 epubs.

[DNSB]

One genius at one of the big publishers about 12 years back generated ePubs with the body font size set to large and the base paragraph font size set to small. This came up with a base paragraph font size just over 1em. Oddly, several newer books use the same except for the body size being set to 1.09em and the base paragraph being set to 0.917em with same result of an ~1em base paragraph size.

[DiapDealer]

The markup in mobi files was full of small, medium, large, x-small, xx-large, and normal font sizes.

The mobi2xhtml script in the kindleinport plugin has a routine that tried to make some sort of sense out of it:

https://github.com/dougmassay/kindle...2xhtml.py#L358