Call for testers for Sigil 2.6.0 - Beta 2

[KevinH]

I think, one thing easy to remove is the TEXT_OF_FOOTNOTE_HERE and the same for the endnote text place holder and just use the \\1 replace reference, since all of these are clips.

That way if you are marking up existing text it will work easier. I will take a shot at that.

[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>

If I replace the footnote/endnote text with \\1 and assume the initial selection is in this format:

"[1] The remainder of text here."

We could extract the footnote number from the text and insert it into the template. We could look for [d+] or d+ at the beginning of the selection and use regex to extract the number.

I think that would be doable.

The same approach could be used for the references to footnotes.

If nothing is selected it would add in the templates.

How does that sound? Sort of a smart footnote clip.

[Doitsu]

Originally Posted by KevinH

How does that sound? Sort of a smart footnote clip.

Sounds good.

[philja]

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'm using the latest epubcheck plugin and it checks weekly (?) for updates. Both Windows and Linux claim to be using EpubCheck 5.2.1 and my Windows Sigil just did its check for an update and still used 5.2.1. The MacBook is also on 5.2.1.

But curiously, the Windows Sigil doesn't object to "backlink" nor does my MacBook using Sigil Beta1. The objection is only in my Linux Sigil.

So, why the difference?

[philja]

Originally Posted by KevinH

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.

In the MacBook, after the failure to run Sigil Beta 2, I went back to Sigil Beta 1 which draws Apple's wrath over the fact of a dangerous download from the internet.

I jumped thro their Security hoops and Beta 1 runs fine.

Beta 1 was also a tar.xz download and only three days ago.

The MacBook sees some difference between Beta 1 and Beta 2 which Apple does not like.

[KevinH]

I only have Mac intel laptop with me to check so I can not actually try running the CI arm build. I will try redownloading it from our CI and compare shasums to see if I downloaded it improperly.

[Doitsu]

Originally Posted by philja

MacBook using Sigil Beta1. The objection is only in my Linux Sigil. So, why the difference?

If you're using my EpubCheck plugin, it should briefly display the EPUBCheck version number like this:

Running EPUBCheck 5.2.1... please wait.

Maybe the update code failed to download to the latest version.

Originally Posted by philja

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

Are you sure that you didn't select a different validator? AFAIK, my EpubCheck plugin doesn't display blue error messages. Also, IIRC, EPUBCheck doesn't check epub:type values.

[KevinH]

Originally Posted by philja

I'm using the latest epubcheck plugin and it checks weekly (?) for updates. Both Windows and Linux claim to be using EpubCheck 5.2.1 and my Windows Sigil just did its check for an update and still used 5.2.1. The MacBook is also on 5.2.1.

But curiously, the Windows Sigil doesn't object to "backlink" nor does my MacBook using Sigil Beta1. The objection is only in my Linux Sigil.

So, why the difference?

None of them should complain. The old epub:type="referrer" was dropped after the first update from the Epub3 Structural Semantics Vocabulary document back around when epub 3.0.1 came out. Ever since all of the updated Vocabulary lists have included epub:type="backlink" so it has been that way for quite a few years now.

Not sure why you are seeing that.

[KevinH]

Originally Posted by philja

In the MacBook, after the failure to run Sigil Beta 2, I went back to Sigil Beta 1 which draws Apple's wrath over the fact of a dangerous download from the internet.

I jumped thro their Security hoops and Beta 1 runs fine.

Beta 1 was also a tar.xz download and only three days ago.

The MacBook sees some difference between Beta 1 and Beta 2 which Apple does not like.

That is increasingly strange. I downloaded that tar.xz directly from the github CI build and its sha256 was an exact match for what I posted on my personal repo.

So nothing was added or lost on upload.

If that build truly is broken in some way, then it is the github CI build process that is involved. I will look into it.

[DNSB]

Originally Posted by KevinH

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

If need be I can revert things.

I was just noticing that your repository is still showing as:

This branch is 24 commits ahead of, 15 commits behind Sigil-Ebook/Sigil:master.

[KevinH]

@philja

Okay I looked through the entire CI build and just like DiapDealer said, there were no issues.

So I snuck into my wife's office and borrowed her MacBook Air (which is an arm64) and downloaded the Beta2 build from my github personal repo.

Then I dragged it out of the Downloads folder to her Desktop:

Then in Terminal.app I did the following:

xattr -d com.apple.quarantine Sigil.app-2.6.0-Beta-2-Mac-arm64.tar.xz

which I always do with trusted software (since I built it!)

Then double-clicked on it to let Archive unpack it.

I was able to then Double-Click on the resulting Sigil application and it launched just fine (after telling Apple it was okay to open).

And it all worked for me.

So I am not sure why you are seeing what you are seeing? Do you by chance have some strange MacOS anti-virus software running?

[KevinH]

Originally Posted by DNSB

I was just noticing that your repository is still showing as:

This branch is 24 commits ahead of, 15 commits behind Sigil-Ebook/Sigil:master.

My personal repo was missing a few recent changes/fixes from BeckyEbook plus some older translations updates. So I cherry-picked them from official Sigil master to my personal repo.

When I added my changes to Sigil official master, I did not do a pull and merge. Instead I generated a diff by hand and edited it to include just the pieces I wanted.

Then I checked out Sigil-Ebook Sigil master and applied the changes using patch. Then pushed them in a few restructured commits from my local repo back to Sigil master (official).

So the source code is now up to date in Sigil-Ebook master. But the commits that got it there were "*different*" then the commits I used in my own repo but the end product should be identical.

But github can not tell that by looking at commit logs.

I have a tendency to hack around in my local repo and push to my personal github repo (so nothing gets lost) until I am reasonably happy. Then my personal repo will lie fallow until the next major change idea comes about.

Everything from here on out will happen from Sigil official master.

[philja]

@philja

Okay I looked through the entire CI build and just like DiapDealer said, there were no issues.

So I snuck into my wife's office and borrowed her MacBook Air (which is an arm64) and downloaded the Beta2 build from my github personal repo.

Then I dragged it out of the Downloads folder to her Desktop:

Then in Terminal.app I did the following:

xattr -d com.apple.quarantine Sigil.app-2.6.0-Beta-2-Mac-arm64.tar.xz

which I always do with trusted software (since I built it!)

Then double-clicked on it to let Archive unpack it.

I was able to then Double-Click on the resulting Sigil application and it launched just fine (after telling Apple it was okay to open).

And it all worked for me.

So I am not sure why you are seeing what you are seeing? Do you by chance have some strange MacOS anti-virus software running?

No strange anti-virus that I've installed. Apart from the apps I use, my MacBook Air is a bog-standard Apple laptop - with OS updated whenever a new version is announced.

And my initial post indicated that I had checked the sha256 checksum on both downloads and both were ok.

My installation procedure was to double-tap the download tar.xz to unpack it inside the Downloads directory and then drag the Sigil.app to the Applications directory.

However, now for the good news.

I followed your procedure as you listed it (on your wife's MacBook) using the first of my Beta2 downloads and now I have a working Beta2.

It must be down to your line of code which I trustingly and blindly followed:

xattr -d com.apple.quarantine Sigil.app-2.6.0-Beta-2-Mac-arm64.tar.xz

Strange that Beta1 was ok but my MacBook didn't like Beta2. But I'll keep your code handy for the future.

[KevinH]

I was checking the sha56 checksums from our github build to what I uploaded to my repo to make sure my initial upload was not broken.

Apple applies stricter security when you run or unpack things inside Downloads.

I always drag it out of Downloads to the Desktop manually. I actually have a Droplet App that runs that command line command to remove the com.apple.quarantine extended attribute that Apple adds to everything you download. On my wife's machine I had to do it by hand.

That attribute is like a virus in that everything you unpack on Apple gets that attribute defines to all its contents if the package itself has that extended attribute.

To really have fun, go to your some busy folder on your Mac and open Terminal and type:

ls -a@el

to get a full listing of all of your extended attributes on your existing files in that folder then compare it with what you trust or do not trust. It is freaky anything runs at all.

I regularly run clean up runs on my home and dev machines to remove those silly attributes from github checkouts, images, etc

Apple really should have an easy way for a user to say I trust something. After 40+years of contributing to various open source projects and shareware before that, and over a decade on Sigil alone, I think a bit of trust should be given for what I produce. But Apple treats everything and everyone as suspect unless it is them.

[philja]

Originally Posted by KevinH

To really have fun, go to your some busy folder on your Mac and open Terminal and type:

ls -a@el

to get a full listing of all of your extended attributes on your existing files in that folder then compare it with what you trust or do not trust. It is freaky anything runs at all.

I regularly run clean up runs on my home and dev machines to remove those silly attributes from github checkouts, images, etc

I see what you mean !!