Feature requested for Sigil 1.7 - Page 2

RbnJrg · 08-04-2021, 03:14 PM

Quote:

Originally Posted by DiapDealer

We don't run the update Manifest Properties tool (or any other tool with the exception of the minimum Mend necessary) automatically for other reasons. Those tools exist in the state they do because there is little point in running them repeatedly and/or automatically.

In this case, not so automatically and not so repeatedly, only when a js file were added and linked (unlinked) because the property "scripted" must be added (or removed) to the respective item in content.opf. How much time can waste Sigil running that command? One second, two perhaps?

And that ONLY when a .js file is added (or removed). Of that way, the linking (unlinking) process will be completed because the property "scripted" will have been written (deleted) also in content.opf.

KevinH · 08-04-2021, 03:19 PM

Adding any svg or adding an link to an external resource, adding an inline script even moving code via copy and paste may require updating manifest properties but there is no way for Sigil to determine that since they were introduced by text editing.

So if you are editing epub3s, there really is a good reason to use the Update Manifest Properties tool last, right before running epubcheck and doing the final save. Having link javascript do it is no guarantee is has been done properly until after all text editing is done.

Sorry but this is not a good idea as it may lead the user into thinking their manifest properties are correct when they are actually not.

KevinH · 08-04-2021, 03:25 PM

As I explained you can not remove the script manifest property just because you unlinked a javascript. There can still be mathml scripts, inline javascripts in head, and links to external javascripts inside the body.

It is important for epub3 devs to get into the habit of running it once before the final run of epubcheck and final save as it could be needed due to other text edits/changes.

KevinH · 08-04-2021, 03:53 PM

All that said ... the actual change in Sigil's code to do this is quite easy to do.

It is basically a one line change in MainWindow.cpp in the routine to link/unlink javascripts to call the opf's UpdateManifestProperties routine with the list of impacted resources.

I would be happy to post a diff with that small change if you do build your own.

RbnJrg · 08-04-2021, 07:37 PM

Quote:

Originally Posted by KevinH

All that said ... the actual change in Sigil's code to do this is quite easy to do.

It is basically a one line change in MainWindow.cpp in the routine to link/unlink javascripts to call the opf's UpdateManifestProperties routine with the list of impacted resources.

I would be happy to post a diff with that small change if you do build your own.

No problem Kevin

I just wanted to be free from the worry of updating the .opf file. But as you say, it just a couple of mouse clicks or a key shortcut.

KevinH · 08-05-2021, 11:11 AM

Okay, I see that in other places in the Sigil source code I already call:

Code:

m_Book->GetOPF()->UpdateManifestProperties(resources);

on a limited set of resources.

So I was being a big hypocrite saying "we should not" when we already do in two other places in the source code. I had forgotten about them. And I hate being a hypocrite.

So I have decided to run UpdateManifestProperties on just the resources touched by linking of the javascripts in that routine.

**BUT** [climbs back on to my soapbox!]
I still think it is really really important to run UpdateManifestProperties on *all* xhtml resources as one of the final steps since just text editing can create the need for it and there is no way for Sigil to easily tell if it is needed.

RbnJrg · 08-05-2021, 08:58 PM

Quote:

Originally Posted by KevinH

**BUT** [climbs back on to my soapbox!]
I still think it is really really important to run UpdateManifestProperties on *all* xhtml resources as one of the final steps since just text editing can create the need for it and there is no way for Sigil to easily tell if it is needed.

Of course Kevin and thanks a lot, thanks a lot!

Binchen · 08-06-2021, 03:09 AM

Seeing Flightcrew in this list: I've often encountering errors from flightcrew coming from non-sigil-structured ebboks where FC has problems of finding the file. Its present, but i guess FC has some hardcoded paths where it assumes the files but the structure of the ebook does not contain the folder FC is trying to look at. Restructering the epug to Sigils default structure resolves those error.

I will try to create a sample. Or is FC more or less dead and will not be maintained any more?

KevinH · 08-06-2021, 08:44 AM

More likely FC is detecting an incorrect case in a path that just seems to work due to testing on case insensitive file system. If you have a testcase that shows the error with FC please post it.

08-05-2021, 11:11 AM	#21
KevinH Sigil Developer Posts: 7,644 Karma: 5433388 Join Date: Nov 2009 Device: many	Okay, I see that in other places in the Sigil source code I already call: Code: m_Book->GetOPF()->UpdateManifestProperties(resources); on a limited set of resources. So I was being a big hypocrite saying "we should not" when we already do in two other places in the source code. I had forgotten about them. And I hate being a hypocrite. So I have decided to run UpdateManifestProperties on just the resources touched by linking of the javascripts in that routine. BUT [climbs back on to my soapbox!] I still think it is really really important to run UpdateManifestProperties on all xhtml resources as one of the final steps since just text editing can create the need for it and there is no way for Sigil to easily tell if it is needed. Last edited by KevinH; 08-05-2021 at 11:38 AM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
A few Sigil Feature Requests	crankypants	Sigil	6	11-03-2015 09:56 AM
Parity feature with Sigil	roger64	Editor	8	03-17-2014 11:28 AM
the 'save' file feature on Sigil	abethan53	Introduce Yourself	6	06-15-2013 07:33 AM
Is auto-relinking a Sigil feature?	dlw	Sigil	2	06-27-2011 12:43 AM
Request Feature requested for the power bottom	henry_moh	enTourage Archive	3	05-25-2010 08:36 PM

08-04-2021, 03:19 PM	#17
KevinH Sigil Developer Posts: 7,644 Karma: 5433388 Join Date: Nov 2009 Device: many	Adding any svg or adding an link to an external resource, adding an inline script even moving code via copy and paste may require updating manifest properties but there is no way for Sigil to determine that since they were introduced by text editing. So if you are editing epub3s, there really is a good reason to use the Update Manifest Properties tool last, right before running epubcheck and doing the final save. Having link javascript do it is no guarantee is has been done properly until after all text editing is done. Sorry but this is not a good idea as it may lead the user into thinking their manifest properties are correct when they are actually not.

08-04-2021, 03:25 PM	#18
KevinH Sigil Developer Posts: 7,644 Karma: 5433388 Join Date: Nov 2009 Device: many	As I explained you can not remove the script manifest property just because you unlinked a javascript. There can still be mathml scripts, inline javascripts in head, and links to external javascripts inside the body. It is important for epub3 devs to get into the habit of running it once before the final run of epubcheck and final save as it could be needed due to other text edits/changes.

08-04-2021, 03:53 PM	#19
KevinH Sigil Developer Posts: 7,644 Karma: 5433388 Join Date: Nov 2009 Device: many	All that said ... the actual change in Sigil's code to do this is quite easy to do. It is basically a one line change in MainWindow.cpp in the routine to link/unlink javascripts to call the opf's UpdateManifestProperties routine with the list of impacted resources. I would be happy to post a diff with that small change if you do build your own.

08-06-2021, 03:09 AM	#23
Binchen Connoisseur Posts: 57 Karma: 10 Join Date: Jul 2021 Device: Abakus	Seeing Flightcrew in this list: I've often encountering errors from flightcrew coming from non-sigil-structured ebboks where FC has problems of finding the file. Its present, but i guess FC has some hardcoded paths where it assumes the files but the structure of the ebook does not contain the folder FC is trying to look at. Restructering the epug to Sigils default structure resolves those error. I will try to create a sample. Or is FC more or less dead and will not be maintained any more?

08-06-2021, 08:44 AM	#24
KevinH Sigil Developer Posts: 7,644 Karma: 5433388 Join Date: Nov 2009 Device: many	More likely FC is detecting an incorrect case in a path that just seems to work due to testing on case insensitive file system. If you have a testcase that shows the error with FC please post it.