Call for testers for Sigil 2.6.0 - Beta 2

[KevinH]

Given the EU recent move to require Accessibility for all Digital Publications and websites, Sigil might need an easier way to see and apply Aria Accessibility role attributes and mapped epub:type attributes, and a way to quickly paste in Aria Accessibility recommended code clips for Chapters, footnotes, endnotes, tips, etc.

In order to make that happen we have had to design a few base classes and dialogs and modify Sigil to employ them when editing in CodeView on epub3.

One proof of concept way of achieving this has been added to Sigil master and we are releasing it as a Beta build in the hopes people will download and test these new features and feed back their thought and comments.

Please note, to not make extra or duplicative work for Translators, I have *not* updated the base for translations to include this code and will not until we have hammered it into some final form.

I have posted the unsigned ci beta builds for Mac, Linux, and Windows on my personal repo here:

https://github.com/kevinhendricks/Bu...nMac/releases/

If you are willing to help make Sigil better please give these a test run and report back your thoughts. Much of the design and gui for these Accessibility improvements is still up in the air, so your feedback will be valuable.

The files to get are named as follows (you can grab the checksums as well):

Mac
----
Sigil.app-2.6.0-Beta-2-Mac-arm64.tar.xz
Sigil.app-2.6.0-Beta-2-Mac_x86_64.tar.xz

Windows
----------
Sigil-2.6.0-Beta-2-Windows-x64-Setup.exe

Linux AppImage
-----------------
Sigil-2.6.0-Beta-2-x86_64.AppImage

Thanks in advance for you help testing and your thoughts on the gui changes.

[DNSB]

Installed and looks good so far in very limited testing.

Is this based on the Sigil or your repository?

[philja]

I downloaded the Sigil.app-2.6.0-Beta-2-Mac-arm64.tar.xz for my MacBook but Apple refused to open the Sigil.app saying '“Sigil.app” is damaged and can’t be opened. You should move it to the Bin.'

The sha256 checksum was correct. I repeated the download and checksum and got the same rejection.

I don't remember getting that with the Beta 1. In that case it was a matter of finding out how to overcome Apple's objections to a file downloaded from the internet - not their claim that the file was damaged.

I'll get to Linux and Windows this afternoon when it's too hot to work outside.

[Doitsu]

I also did some quick tests and everything looks OK. For footnotes and endnotes it would be helpful, if the clip would replace _N_ with a number if a number was selected before the clip was applied.

For example, if I enter a 1, select it and apply an Endnote LI clip the result should be:

    <li id="en1" epub:type="endnote">
      <p>
        <a href="HREF_FOR_RETURN_FROM_ENDNOTE#en1" epub:type="backlink" role="doc-backlink">[1]</a>
            TEXT_OF_ENDNOTE_HERE
      </p>
    </li>

[philja]

Got Beta 2 running successfully on both Linux and W10 boxes. The new ePub3 functionality works fine so far.

One question though.

When we click on Aria Clip and select an item, like <section>, would it be possible to keep the focus in the initial tag and have a pop-up appear automatically with a list of the possible appropriate roles?

[KevinH]

Originally Posted by philja

Got Beta 2 running successfully on both Linux and W10 boxes. The new ePub3 functionality works fine so far.

One question though.

When we click on Aria Clip and select an item, like <section>, would it be possible to keep the focus in the initial tag and have a pop-up appear automatically with a list of the possible appropriate roles?

Thanks.

I think that would be possible but useful for only the section and aside clips as all of the remainders already have all the appropriate roles in them. So we would have to special case 'section' and 'aside' somehow.

Let me think about it.

[KevinH]

Originally Posted by Doitsu

I also did some quick tests and everything looks OK. For footnotes and endnotes it would be helpful, if the clip would replace _N_ with a number if a number was selected before the clip was applied.

For example, if I enter a 1, select it and apply an Endnote LI clip the result should be:

    <li id="en1" epub:type="endnote">
      <p>
        <a href="HREF_FOR_RETURN_FROM_ENDNOTE#en1" epub:type="backlink" role="doc-backlink">[1]</a>
            TEXT_OF_ENDNOTE_HERE
      </p>
    </li>

But the user would still have to manually replace all the other placeholders, so it really would not help much. Especially with endnotes. One you created the endnotes you could always sequentially renumber them with Python Function Replace. To search for and replace that placeholder would be easy. But filling in all the remaining placeholders hrefs not so much.


So Let's say you had 6 footnotes, at the end of the file, I would insert one footnote clip, and copy and paste it 5 more times. Then use Python Function Replace to fill in each _N_ incrementing them automatically. For only 1 or 2 footnotes I would just do the replace by hand.

That still leaves replacing each footnotes text appropriately.

Footnotes are really hard to deal with in an editor, so a plugin is probably a better way to handle them.

Inside CV editor it is not clear if the footnote text already exists (ie. you are marking up existing text) and you just want to wrap around selected text and provide a number.

Or if no text exists so you just want to create a structure with all the roles and things first and as many of them as needed. The go back and fill in the text.

In a plugin you can assume the author has already somehow marked both the text you are footnoting and its corresponding footnote, and then can create links and number them much more easily.

I took the clips approach but perhaps a standalone insert footnote command or insert endnote command might be better. But it would need to differ across epub 2 and epub3.

Really not sure here.

[KevinH]

Originally Posted by DNSB

Installed and looks good so far in very limited testing.

Is this based on the Sigil or your repository?

It is now all in Sigil master. It was just the only way to create the betas.

If need be I can revert things.

[KevinH]

Originally Posted by philja

I downloaded the Sigil.app-2.6.0-Beta-2-Mac-arm64.tar.xz for my MacBook but Apple refused to open the Sigil.app saying '“Sigil.app” is damaged and can’t be opened. You should move it to the Bin.'

The sha256 checksum was correct. I repeated the download and checksum and got the same rejection.

I don't remember getting that with the Beta 1. In that case it was a matter of finding out how to overcome Apple's objections to a file downloaded from the internet - not their claim that the file was damaged.

I'll get to Linux and Windows this afternoon when it's too hot to work outside.

Wow, perhaps our CI for arm64 is broken. I will manually recreate one later this week and replace it.

Thanks for the head's up.

[philja]

Originally Posted by Doitsu

I also did some quick tests and everything looks OK. For footnotes and endnotes it would be helpful, if the clip would replace _N_ with a number if a number was selected before the clip was applied.

For example, if I enter a 1, select it and apply an Endnote LI clip the result should be:

    <li id="en1" epub:type="endnote">
      <p>
        <a href="HREF_FOR_RETURN_FROM_ENDNOTE#en1" epub:type="backlink" role="doc-backlink">[1]</a>
            TEXT_OF_ENDNOTE_HERE
      </p>
    </li>

I thought I might have a case where I disagree. For an existing book where on revision you might want to add a second footnote to a chapter using #fn2, I thought epubcheck would choke because #fn1 thro #fn34 had already been used in various chapters thro the book.

But to my surprise, it didn't object to #fn2 being used in two separate chapters. Could this cause a problem in some e-reading devices?

But it did bring up a blue 'error' message about an unrecognised epub:type value "backlink"

[KevinH]

Is this the latest epubcheck?

According to the latest official docs on mapping the epub:type referrer is now called backlink.

So perhaps they have not updated epubcheck to meet their own latest standards.

[DiapDealer]

Originally Posted by KevinH

Wow, perhaps our CI for arm64 is broken. I will manually recreate one later this week and replace it.

I don't see anything unusual in the arm64 CI deploy run for your betas. Looks the same as the last few releases. *shrug*

But we rarely use the deploy builds (except for betas) so maybe there is something going wrong creating the the tgz archive.

[DiapDealer]

Originally Posted by philja

But to my surprise, it didn't object to #fn2 being used in two separate chapters. Could this cause a problem in some e-reading devices?

Not to my knowledge. ids/url fragments only need to be unique to the file they're in.

[DiapDealer]

Originally Posted by DiapDealer

I don't see anything unusual in the arm64 CI deploy run for your betas. Looks the same as the last few releases. *shrug*

But we rarely use the deploy builds (except for betas) so maybe there is something going wrong creating the the txz archive.

The only difference I see is that your mac beta archives are named *.tar.xz whereas the official releases have been using *.txz

[Doitsu]

Originally Posted by KevinH

Is this the latest epubcheck?

According to the latest official docs on mapping the epub:type referrer is now called backlink.

So perhaps they have not updated epubcheck to meet their own latest standards.

I created a new epub3 file with the following contents:

Spoiler:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html>

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops">
<head>
  <title>title</title>
</head>

<body>
  <section epub:type="endnotes" role="doc-endnotes">
    <ol>
      <li id="en1" epub:type="endnote"><p><a href="Section0001.xhtml#en1" epub:type="backlink" role="doc-backlink">[1]</a> TEXT_OF_ENDNOTE_HERE</p></li>
    </ol>
  </section>
</body>
</html>

(I added a circular dummy backlink.)

EPUBCheck 2.5.1 didn't complain about it.
Here's the partial .json output:

Spoiler:

  "checker" : {
    "path" : "C:\\Users\\user\\AppData\\Local\\sigil-ebook\\sigil\\plugins\\EpubCheck\\temp.epub",
    "filename" : "temp.epub",
    "checkerVersion" : "5.2.1",
    "checkDate" : "06-20-2025 17:47:20",
    "elapsedTime" : 41944,
    "nFatal" : 0,
    "nError" : 0,
    "nWarning" : 0,
    "nUsage" : 0
  },

Most likely, philja is using an older version or there's another syntax issue in his code.