Absolute filepaths being converted to relative?

[Mister L]

A cursory search did not turn up the answer to my question so my apologies if it's been addressed already.

When I have internal links (such as to end notes) I prefer to use the full / absolute filepath (using Sigil's normal file structure), for example:
href="../Text/notes.xhtml#footnote-1"

In the very latest version(s? not sure when it started) of Sigil, these mysteriously get converted into relative filepaths:
href="notes.xhtml#footnote-1"

I cannot for the life of me figure out what triggers it as it doesn't appear to be on save and I don't see anywhere to set a preference for that but I am 99.99999% sure this didn't used to happen previously.

Why / when does this happen, and is there a way to stop it?

I'm using version 1.2 on windows 10.

[Tex2002ans]

Sigil 1.0+ got rid of the strict enforcement of the "Text", "Images", "Styles", "Fonts" folders.

(You could sort files back to Sigil's old way by going under Tools and clicking the new menu item.)

See the 1.0.0 changelog:

• The BookBrowser will still show the Text, Images, Styles, Fonts, Audio, Video, and Misc “folders” but these are now “virtual folders” that simply organize the existing resources by type but do not restrict their actual location within the epub.
• A new Preferences setting has been added to the Appearance Preferences that will determine if the book folder relative path will be shown in the BookBrowser or its shorter unique name (filename) will be used instead. In either case, the BookBrowser tooltips will always show the file’s true book folder relative path. Duplicate file names (in different subfolders) will always show the longer path to be able to differentiate between them regardless of the new Appearance Preference.
• A Tools menu item has been added to standardize any epub already loaded to Sigil’s old structure

[pdurrant]

Originally Posted by Mister L

When I have internal links (such as to end notes) I prefer to use the full / absolute filepath (using Sigil's normal file structure), for example:
href="../Text/notes.xhtml#footnote-1"

In the very latest version(s? not sure when it started) of Sigil, these mysteriously get converted into relative filepaths:
href="notes.xhtml#footnote-1"

Both those are relative paths. I don't think there is a way to have an absolute path from the root of the ePub.

[KevinH]

There is no way to have absolute path urls for internal epub files.

If the source xhtml is in Text/ and uses a relative href "../Text/notes.xhtml", that url is simplified to notes.xhtml since that is the correct destination. The "../Text" is unneeded and does in no way clarify the link destination.

So when Sigil went 1.0, it allowed for users to have any organization they want for their epub and the need and use for prefacing a destination with its folder went away since those links can now be relative to other folders and need not be correct anymore.

[Mister L]

Originally Posted by Tex2002ans

Sigil 1.0+ got rid of the strict enforcement of the "Text", "Images", "Styles", "Fonts" folders.

(You could sort files back to Sigil's old way by going under Tools and clicking the new menu item.)

Yes, I always set my files to the "historic" structure, I even have set a shortcut for it (CTRL + *). Keeping to a standardised structure across all my files makes things easier for things like clips or to add various links (css, images, internal links...) so I prefer it.

Originally Posted by pdurrant

Both those are relative paths. I don't think there is a way to have an absolute path from the root of the ePub.

Ok. I was trying to think of a clear way to differentiate between the two paths, that seemed like the most understandable to me, sorry if that was incorrect.

Originally Posted by KevinH

If the source xhtml is in Text/ and uses a relative href "../Text/notes.xhtml", that url is simplified to notes.xhtml since that is the correct destination. The "../Text" is unneeded and does in no way clarify the link destination.

So when Sigil went 1.0, it allowed for users to have any organization they want for their epub and the need and use for prefacing a destination with its folder went away since those links can now be relative to other folders and need not be correct anymore.

Yes, I do understand all that, thank you. What I am asking about is why the file paths that I defined are being modified silently, and what is the event that triggers it (it is not saving since they are the same immediately after a save, but they eventually get changed, without any alert).

One of the things I like about Sigil is that in general it does not modify my code unless explicitly allowed (in preferences or with a dialog box), which doesn't seem to be the case here. If "../Text" is unneeded, but not actually incorrect, since I am explicitly deliberately setting my internal file structure to that, does it matter if I write the filenames that way? If it matches the real file structure and won't cause problems, why change it? As I said, it's down to a question of habit for me and I don't mind changing if there is a reason to but either way, I'd prefer it if my code wasn't changed in the background (if only so I don't start to wonder if I'm going crazy when I do search / replace all for 50 footnote links to add "../Text" to the front of them and then 5 minutes later that bit of code has disappeared. I did that S/RA 3 times on the same file the other day thinking maybe I'd not selected "all html files" or something, I thought I was going mad ).

[KevinH]

Any move or rename or splitting or merging of anything will invoke the update all links code. This code was always run from the beginning. In the old Sigil the added the folder to the path was a workaround instead of resolving the simplest relative path.

So your version of the link from epub root we be would be the following:

OEBPS/Text/../Text/notes.xhtml

which would then need to be simplified.

whereas in current Sigil the link destination will be built as

OEBPS/Text/notes.xhtml

with no further simplification needed.

So if you stop making any changes to the epub or mending of code, no changes will be made to links. But once a file name is changed or a mend is done, a split is done, etc, the links will be corrected and properly updated, just as Sigil always has done.

[Mister L]

Sorry, somehow I completely missed out seeing this until now.

Originally Posted by KevinH

Any move or rename or splitting or merging of anything will invoke the update all links code.

Ah, thank you, one "mystery" solved.

Originally Posted by KevinH

This code was always run from the beginning. In the old Sigil the added the folder to the path was a workaround instead of resolving the simplest relative path.

So your version of the link from epub root we be would be the following:

OEBPS/Text/../Text/notes.xhtml

which would then need to be simplified.

whereas in current Sigil the link destination will be built as

OEBPS/Text/notes.xhtml

with no further simplification needed.

So if you stop making any changes to the epub or mending of code, no changes will be made to links. But once a file name is changed or a mend is done, a split is done, etc, the links will be corrected and properly updated, just as Sigil always has done.

Okay, thanks very much for those details. It's making my brain melt a little bit because I thought same internal structure = same paths, regardless of which version of Sigil. I did not realise there could be a difference to the paths for an epub with the same (standard) internal structure when managed by old Sigil vs. new Sigil or that old Sigil was displaying paths that were not the actual paths.

Anyway thanks for taking the time to explain it.

[Shozzer]

Hi

It is so long that I used the forum that I have had to re-register!

I have been using Sigil for a number of years and recently updated to 1.4.2. (Windows 10). I have noted an issue regarding splitting files and the updating of links. When creating links to footnotes I use the following format: <a id="fn1" href="#en1"> and then close off with </a>. In the past, when I split the file into chapters the links were updated automatically to reflect the split files. When I split a file now the link stays the same. Is there a setting I need to change or is it the way I have formatted the tag? The posts above suggest that the link update should be automatic.

I have another query regarding file splitting and performance but will raise this in a separate thread.

Many thanks.

[KevinH]

Yes this is a bug! I have just now committed a fix for it to master. The Sigil devs need to think about a Sigil-1.4.3 release or not.

As for performance in splitting really really long files, the best approach is to use find and replace to manually insert split markers all at once. Then running SplitAtMarkers which should use QtConcurrent and multiple threads to help speed up things.

If you do splitting manually, you should start at the end of the file and split pieces off from the bottom. It is a bit faster that way.


But before doing that, if you do a lot of file splitting, I would revert to Sigil-1.3.0 for now until or if a Sigil-1.4.3 makes the scene.

Sorry about that.

And thank you for your bug report!

Originally Posted by Shozzer

Hi

It is so long that I used the forum that I have had to re-register!

I have been using Sigil for a number of years and recently updated to 1.4.2. (Windows 10). I have noted an issue regarding splitting files and the updating of links. When creating links to footnotes I use the following format: <a id="fn1" href="#en1"> and then close off with </a>. In the past, when I split the file into chapters the links were updated automatically to reflect the split files. When I split a file now the link stays the same. Is there a setting I need to change or is it the way I have formatted the tag? The posts above suggest that the link update should be automatic.

I have another query regarding file splitting and performance but will raise this in a separate thread.

Many thanks.

[Shozzer]

Originally Posted by KevinH

Yes this is a bug! I have just now committed a fix for it to master. The Sigil devs need to think about a Sigil-1.4.3 release or not.

As for performance in splitting really really long files, the best approach is to use find and replace to manually insert split markers all at once. Then running SplitAtMarkers which should use QtConcurrent and multiple threads to help speed up things.

If you do splitting manually, you should start at the end of the file and split pieces off from the bottom. It is a bit faster that way.


But before doing that, if you do a lot of file splitting, I would revert to Sigil-1.3.0 for now until or if a Sigil-1.4.3 makes the scene.

Sorry about that.

And thank you for your bug report!

Thanks Kevin. I will revert to 1.3.0 for now and await further developments regarding 1.4.3...