Possible To-Do List for Future Sigil Releases Post Sigil 1.8

[democrite]

Sounds like it'll either be hard to track down or we'd need to await a newer Qt 6. Minor issue, can be ignored.

Of other things I mentioned before, ...

Originally Posted by KevinH

Mass renaming, mass renumbering and mass changing of extensions are easily done. A Regular Expression Renamer was added to pretty much rename many things in any way. Manually renaming one file after another in a long list is not the way to go.

I am referring to after any rename or mass rename, cursor focus moves out of that panel. With certain publishers, file names are not helpful for locating a chapter, thus for future corrections of typos or other, naming them as such helps me. As the file names do not indicate chapter or metadata, I usually need to use some other editor to quickly locate range of files to rename, select, and rename. If cursor focus remained in pane, I could then more easily after, to continue with the next set like next section/part, simply use arrow key to go to next file, shift-down arrow to select next range, and continue renaming, e.g. select, cmd-option-R, arrow key to select more, repeat, without need to use mouse.

Same as, though I haven't tried it, maybe search/replace or other places within app, after performing an action, cursor focus remains.

I have yet to see a valid case where Sigil's gumbo repair parser broke anything, ever. I will need a full test case that clearly illustrates this happening.

That is the whole point of the Checkpointing feature added to Sigil. Say "no" to any changes on import. Hit make checkpoint. Now reload the epub but this time let Sigil fix things (Mend on open) and then compare to earlier Checkpoint's via the Sigils compare tools to see exactly what was changed and where.

Maybe for some their profession is EPUB-making. Some like us, modify purchased ebooks, most of the time. For similar reasons of another feature, it would be difficult to checkpoint all edited EPUBs in my calibre library.

What I am uncomfortable is code fixing that is from some syntax error. For various reasons, I tend to use BBEdit - search/replace multiple files is easier, file name I can use arrow keys to move between files and contents is shown in file view pane immediately (thus I can easily view chapter order, I tend to like restoring print order of front matter that's sometimes/often changed, ….

Header fix is fine. Other, over time I may make various edits. Perhaps unfamilar with how gumbo works, if there is some fix in missing close tag, misspelling of span/div/em/strong/etc., I am not sure if then when fixed, if there is some text where such tag is misapplied, some paragraph break combined, some unwanted paragraph break introduced, and so forth.

If it were possible to have distinct messages, such that "missing a DOCTYPE …", files that are not well formed", or a message that indicated both, I'd know what's happening. If that is not too much trouble and is possible, I'd be so much more at ease. For now, I may randomly edit any EPUB in my library, and I'm always uncomfortable seeing that message, and not knowing have I ever opened such in Sigil, is it first time, did I edit it once somewhere before and made an error, etc.

If it such is possible, it'd be much easier for me compared to epubcheck or other.

Sigil already allows users to install their own custom icon sets. If you create a set of mac-like svg icons and most importantly are willing to keep them updated and add new icons when needed in a timely manner, we would be happy to add them to our custom theme repo.

May get to that someday. I was thinking maybe some file format where one could specify and use installed fonts. As with some native APIs, one can specify typical OS UI fonts by character identifier, I think there are Qt libs on GitHub where one could do such or use unicode point. Maybe Qt will add such later if not, who knows. Would some possible change, such as an XML file specifying code point per icon someday make theme making easier over creating images? I don't know. Worth the effort, who knows. Minor thing.

[democrite]

Related slightly to above, of the file list pane, some editors will open a new tab or load file into file view pane (if tabless) on single click or if cursor focus is in file pane, as one uses arrow keys. Haven't thought much about how problematic such an option/mode may be, yet in an EPUB/project with many files, finding the right one sometimes is effort. Arrowing thru files and seeing what they are immediately helps for many things.

One thing maybe related to Qt6, deleting files like fonts, when I scroll to the bottom and multiple select, after right-click to delete, I'm somewhat frequently unable to select the menu since file pane scroll position resets, it scrolls up. Single click detected over right/contextual. Forgot if it happened much before. Maybe it's Monterey, Qt 6, other, unsure.

A feature that may help elsewhere, possible to cmd/ctrl-delete selected files? Maybe some new menu or submenu somewhere for when focus is in file pane, any file action available thru context menu, shows in the main menu and becomes enabled and usable? Perhaps someday it may help other features become discoverable, as perhaps such are somewhat major operations and having such in the main menu, I tend to like that.

[KevinH]

Again, you only need to use Checkpoint on first load to see exactly what is changed by Mend.
You can delete that Checkpoint easily when done. You do not need to checkpoint all files in your library.

Actually try the RERenamer tool. It can handle most multiple renames youcan imagine in one or two passes.

Any error on load is either a missing doctype or the file itself is not well formed. Again just use Checkpoint as I have explained after first launch if you want details of everything changed when gumbo Mend is used. Or pass your file through an external xhtml validator.

The gumbo repair parser uses the exact whatwg spec to build a dom tree when parsing errors are present. This is the same spec followed by all browsers.

So there are existing ways to get what you want. You just need to try them. Your suggestions for improvements are noted but given available tools they will not be added to my To-Do list as they will not add value over what is here and to some extent are an artifact of you using external editors that do not properly repair parse leaving broken xhtml behind.

Sorry.

[democrite]

Unfortunate. Perhaps someday you'll reconsider.

Perhaps there are other cases. Can we be sure all commercial EPUBs are w/o error? Of those that produce EPUBs, are there not some that may use multiple tools, or where there is more than one person on one system that work on one before publication? Maybe such may use Git, some other form of version control, have some process, etc., yet isn't it possible someone may somewhere introduce some error and fixing w/o feedback of specific repairs may be undesirable?

If at least the dialog had some optional panel, such an expandable hidden by default panel with text such as "show errors" and an arrow key to show a field with issues, that'd be something.

[KevinH]

Then use an external xhtml validator.

Sigil will load exactly what you give it or will tell you that problems exist and let you decide if you want to auto repair or not. If you decide to not auto repair, you can run sanity check to get a simple list of errors that prevent it from being well formed and fix them yourself. Or make a Checkpoint, then run auto repair and see everything that it fixed using the Checkpoint tools. If you then decide you do not like what was changed you can revert back to the checkpoint made. You can manage your Checkpoint repos to delete them once you have to things the way you want.

As for working with teams, then using the FolderIn and FolderOut plugins to access git repos for the book is what you want.

Thank you for your suggestions but I am done with this subject as you do not appear to be even trying what I suggest.

[KevinH]

I just tested this in master under Qt6. I took an epub, restructured it to Sigil norm, then renamed the content.opf to package.opf and saved it.
When I loaded up that just saved test epub, it was detected as non-standard properly.

I then Restructured it to Sigil norm again (which changed package.opf back to content.opf) and it properly detected and added the [std] to the Window title.

So based on this, the bug you reported must exist only in the arm64 version of Qt or Sigil.

Until I get an arm64 machine tracking this one down is going to be impossible.

Sorry.

Originally Posted by KevinH

The [std] indicator is updated after every File/Resource addition, deletion, or move so it catches every standardize test I tried.

Thinking about it more now, that does leave out rename, but the only two names that mean anything to standardization are the opf name and the ncx name (if it exists). So could the only things that were not standard in bug test case be "content.opf" or "toc.ncx" before you standardized it?

If so, let me know and I will see if there are signals for renaming both that I can hook to somehow to detect when to update the Window title bar.

KevinH

[democrite]

Thanks for taking a look. Several I tried were without issue. Just one where it was similar to Sigil norm with standard folder names but main folder was OPS instead of OEBPS. Later in front of a computer I can either try to create a test epub or PM you the original.

[KevinH]

A test case would certainly help. Thanks.

Originally Posted by democrite

Thanks for taking a look. Several I tried were without issue. Just one where it was similar to Sigil norm with standard folder names but main folder was OPS instead of OEBPS. Later in front of a computer I can either try to create a test epub or PM you the original.

[democrite]

ok I think this is reproducible. Default EPUB created from Sigil File | New. Renamed main folder from OEBPS to OPS with calibre editor.

Normalizing worked without issue. Then added "META-INF/com.apple.ibooks.display-options.xml". Seems that is it.

[KevinH]

Yes, the ibooks xml file is inheriting the wrong media-type (it actually does not have one that I can find) and is actually showing up in Misc when it should not on import. I will have to see about creating it a media-type and making sure standard epub tests ignore it.

[DiapDealer]

The ibooks xml file has always appeared to be in Misc upon import, but it's not actually moved there if I remember correctly. After saving/closing the epub, it will still be in the META-INF folder where it belongs. I cannot recall at this time why this bit of trickery was required.

[BeckyEbook]

Originally Posted by DiapDealer

The ibooks xml file has always appeared to be in Misc upon import, but it's not actually moved there if I remember correctly. After saving/closing the epub, it will still be in the META-INF folder where it belongs. I cannot recall at this time why this bit of trickery was required.

Everything is fine when the EPUB file is opened with the already existing "com.apple.ibooks.display-options.xml" in the META-INF folder. We see it in Misc, but the file is actually in the correct folder.

There is a special exception in the code for this file: ImportEPUB::AddNonStandardAppleXML()

If we use the AddiBooksXML plugin, everything is fine too.

The problem is only adding "com.apple.ibooks.display-options.xml" via the "Add File" function.

Originally Posted by KevinH

Yes, the ibooks xml file is inheriting the wrong media-type (it actually does not have one that I can find) and is actually showing up in Misc when it should not on import. I will have to see about creating it a media-type and making sure standard epub tests ignore it.

In my newest build standard epub tests ignore it when ibooks .XML file is in Misc folder, though of course it shouldn't be there.

Hmmm ...
Apart from ignoring the addition of such a file, I see other solutions here:
a) detection of the file name during adding and if equal "com.apple.ibooks.display-options.xml", then use an exceptional procedure and move the file directly to the META-INF folder.
b) after detecting exactly such file name during adding, displaying a message suggesting to use the "AddiBooksXML" plugin.

[DiapDealer]

Originally Posted by BeckyEbook

The problem is only adding "com.apple.ibooks.display-options.xml" via the "Add File" function.

I'd forgotten that the display-options.xml file could even be added with "Add File". But that explains why the plugin has fallen out of use.

Now that Book Browser's folders are virtual, I'm curious what path shows for a properly added com.apple.ibooks.display-options.xml file (found either by hovering over the file or by turning on "Show Full Paths" in Sigil prefs)?

[KevinH]

The bug was actually related to having empty folders in an epub and that ibooks file in the META-INF after a restructure.

It was confusing the setting of paths for resource groups/types that no file exists for yet.

I think I have tracked this down and fixed it. The ibook xml will still appear in Misc but should no longer interfere with the default folders calculations.

Please try master to verify the fix.

[democrite]

Looks good.

I'm not sure if there's any other possible files that'd trigger such; you'd know and I imagine already thought of it. As that's the only thing I could think of, tested also an ADE template in main OEBPS folder just in case.

Many thanks.