Sigil-0.9.991 (1.0 Pre-release)

[KevinH]

In fact, a compendium epub merging plugin might be a useful thing to create.

[DiapDealer]

As mentioned, the tooltip always shows the full path. You don't have to expand Book Browser widely. I find with reasonably named files, I can leave the setting to show the full path on all the time (and unreasonably named files don't stay so for long!).

As mentioned elsewhere: there will be no treeview with the actual file structure forthcoming. Sorry. The would defeat the purpose of being able to select multiple files of the same type for processing. Such as mass renaming.

[odamizu]

Originally Posted by KevinH

I will pm you with an updated link once my last commit passes through travis.
Thanks again for all of your testing.

Thanks! I installed the latest build, ran it through my usual workflow and also tested against specific bug-fixes (e.g., invalid mediatypes). Sigil came through like a champ.

I did however get that crash on Quit, which I think is the same crash that we have been chasing off-forum for a while. I will send you the crash report directly.

While I would never have asked to have the filename at the top of the Preview window, having it there is a pleasant surprise — something I never knew I wanted until I had it It's useful to me even if the Preview window is docked because I usually have multiple files/tabs open such that the full filename can't be seen, so having the name of the active tab at the top of the Preview window is nice. Thanks!

Originally Posted by Vroni

... i miss a shortcut in the bookbrowser to switch fast between standard view and extended view with path info.

I would also find a keyboard shortcut or toolbar button that toggles standard view and extended view on/off useful.

The reason is that now that Sigil respects original structure, I would find it useful to see the book structure in a single glance, then turn full filepaths off to save space. Mousing over each filename is awkward, as is going to Preferences to turn on full filepaths and then going back to turn off.

However, this is a minor issue for me and I understand if it's problematic to implement. Just thought I'd weigh in since it's come up.

Originally Posted by DiapDealer

... I find with reasonably named files, I can leave the setting to show the full path on all the time (and unreasonably named files don't stay so for long!).

Is there a quick way to mass-rename files with a structure like this, where you want to delete a repeated phrase XXXXXXXXXXX without touching the rest of the filename?

XXXXXXXXXXX_titlepage.xhtml
XXXXXXXXXXX_copyright.xhtml
XXXXXXXXXXX_chapter01.xhtml
XXXXXXXXXXX_chapter02.xhtml
XXXXXXXXXXX_chapter03.xhtml
XXXXXXXXXXX_epilogue.xhtml

I know that I can select all the "chapter" files and rename them "chapter01" and it will number them sequentially. But can I delete a phrase that is repeated in all filenames without touching the rest of it?

All in all, I'm feeling 0.9.991 is working really well!

Thank you

[DiapDealer]

Originally Posted by odamizu

Is there a quick way to mass-rename files with a structure like this, where you want to delete a repeated phrase XXXXXXXXXXX without touching the rest of the filename?

Unfortunately there's not. Not with Sigil features anyway. Sounds like a good idea for a plugin, though!

[KevinH]

If we use plugins for that we will have to recreate all of the UniversalUpdates code in python. That might be a good thing to have for plugins in the long run anyway.

That said, we could easily add an TrimPrefix Rename menu item and a TrimSuffix Rename menu item and that would ask for the prefix or suffix to trim where Prefix would trim from the left (only if filename actually starts with that prefix), and similarly for a suffix that worked on the filename to the left of the extension.

We could add them to the BookBrowser context menu or to the MainWindow tools menu.

Any interest?

Or alternatively we could use some sort of regular expression based matching to extract the desired name piece.

[snarkophilus]

Originally Posted by KevinH

Okay, as a test, I just pushed to master an unrecognized media type load warning when an epub is first imported and the media type is unrecognized. This will not fix your issue as the media-type was recognized but incorrect.

With 0.991-41 I now get this on loading the epub:

The OPF uses an unrecognized media type "txt/css" for file "stylesheet.css" - A temporary media type of "text/css" has been assigned. You should edit your OPF file to fix this problem.

I get no popups or messages of any kind renaming any file, including renaming the xpgt with the incorrect media-type. Was removing the invalid mediatype popup intentional? I missed that.

As I previously mentioned, EpubCheck didn't mention anything about the xpgt, but I just accidently ran FlightCrew (its quick launch button is next to EpubCheck's), and it did report something.

File: content.opf
Line: 114
Offset: 23784
Message: Error OPF bad item media type value : The <item> element's "media-type" attribute has value "application/vnd.adobe-page-map+xml", but the file's media type is "application/vnd.adobe-page-template+xml". near column 101

I'll bring this one up in the EpubCheck thread.

[DiapDealer]

If TrimPrefix or TrimSuffix would be relatively painless (and less work than porting UniversalUpdates to Python) then I say, why not? There's plenty of epubs out there that could benefit from being de-garbaged.

[KevinH]

Yes that was the load warning for an unrecognized media type txt/css and the file name it applies to and info on where to fix it.

Yes, it does not detect the second error anymore since it is actually a valid mediatype, just not one that matches the file itself. Since the iana.org that registers mediatypes allows vnd. trees, it is is a valid mediatype clearly stated in the OPF manifest, and there just isn't an easy way to detect the mismatch that does not require a new one to many mapping since file extensions may have many valid mediatypes.

We only detected a problem before since the bad mediatype was not a perfect match for previously required adobe-page-template+xml but changes this year in the media type registrations structure of the iana.org means Sigil must now accept it as valid.

KevinH

Originally Posted by snarkophilus

With 0.991-41 I now get this on loading the epub:

The OPF uses an unrecognized media type "txt/css" for file "stylesheet.css" - A temporary media type of "text/css" has been assigned. You should edit your OPF file to fix this problem.

I get no popups or messages of any kind renaming any file, including renaming the xpgt with the incorrect media-type. Was removing the invalid mediatype popup intentional? I missed that.

As I previously mentioned, EpubCheck didn't mention anything about the xpgt, but I just accidently ran FlightCrew (its quick launch button is next to EpubCheck's), and it did report something.

File: content.opf
Line: 114
Offset: 23784
Message: Error OPF bad item media type value : The <item> element's "media-type" attribute has value "application/vnd.adobe-page-map+xml", but the file's media type is "application/vnd.adobe-page-template+xml". near column 101

I'll bring this one up in the EpubCheck thread.

[KevinH]

Okay, I will take a shot at it tomorrow, at least the prefix one anyway.

Originally Posted by DiapDealer

If TrimPrefix or TrimSuffix would be relatively painless (and less work than porting UniversalUpdates to Python) then I say, why not? There's plenty of epubs out there that could benefit from being de-garbaged.

[odamizu]

Originally Posted by KevinH

Okay, I will take a shot at it tomorrow, at least the prefix one anyway.

Thanks! I actually was not trying to create more work for you. I asked because Sigil often has features that I'm not aware of, that I only discover from reading these forums — and then I smack myself in the head for doing it the hard way unnecessarily. So this time I thought I would check to make sure I wasn't missing something But thank you!

[BeckyEbook]

Originally Posted by DiapDealer

Unfortunately there's not. Not with Sigil features anyway. Sounds like a good idea for a plugin, though!

Sounds great, but... it is not possible (easily).
Every now and then someone asks a similar question, e.g. here.

I would be happy if there was (safe and universal) possibility to rename file in the epub structure by the plugin.

Of course, implementing "TrimPrefix" / "TrimSuffix" directly in BookBrowser will be a partial solution, but with weird names it won't help.

[KevinH]

With really wierd names, can't you just use Sigil to bulk renumber them as it currently can? You can set any base template for renumbering as well.

My long run goal is to create a python code to handle universal updates for moves and renames but until then, some type of bulk name trimming will make it much easier to fixup Gutenberg style file naming conventions style epubs.

KevinH

[KevinH]

Perhaps, instead of a TrimPrefix and TrimSuffix, we instead create a "RE Renamer".
It would put up a dialog that asks for a RegularExpression and a replacement. We could use QString's QRegularExpression to modify each matching filename. It would support replacement subgroups too.

Then it could produce a list of before and after filenames side by side and have OK and CANCEL buttons.

That would give easy trimming, adding, and even re-arranging of sub capture groups.

That should be quite doable. Would this be better, or are regular expressions too hard for most users needs?

KevinH

[BeckyEbook]

Originally Posted by KevinH

Perhaps, instead of a TrimPrefix and TrimSuffix, we instead create a "RE Renamer".

RE Renamer sounds good!
If there was a preview of file names in two windows: before and after ... then the function would have a considerable educational value.

[KevinH]

Why 2 windows? I thought one column of "before" names and one column of "after" names just in case the re did something the user did not think would happen.