Problem with not referenced files - Page 2

DiapDealer · 09-10-2020, 08:24 AM

Sigil (as of v1.0) no longer forces epubs into its traditional folder structure (OEBPS/Text, Images, Fonts, css) when opening them. It will work with whatever structure an epub was created with. Many epubs are constructed in that manner already, but many are not. When inserting files, you need to check what their actual path IS before manually adding links to them. The path can usually be seen in the tooltip when hovering over the file in BookBrowser. You can also see the paths using the Reports tool, or you can see the paths (relative to the OPF) in the OPF manifest using the href property value.

I have no experience using the CssFromFont plugin, but my guess is that it might not have been updated to work properly with the changes introduced (RE not automatically restructuring all epubs) in Sigil 1.0. We gave advanced notice of the changes to plugin devs, but not all took the steps to meet the changes. For those that didn't, they advise users to always run the "Restructure" tool before using their plugins.

I see no mention of that plugin being updated for the Sigil v1.0 changes, so the advice to always "Restructure" first will apply if you want to continue using it.

"Non-standard epub" is probably not the perfect phrase, but for lack of a better one ... What is meant is an epub that's not created using Sigil's historical, traditional folder hierarchy. There's never been any sort of requirement that epubs use a standard folder structure--and they don't. Sigil now honors the structure an epub was created with. It no longer forces each and every epub into its own proprietary structure. The idea is to change nothing about an epub that doesn't need to be changed. But you can still manually do so with Sigil's Restructure tool. Calibre's editor also has a tool to restructure epubs and create specific folders for file-types that can be manually run.

The bottom line is that unless you manually run the Restructure tool first, no assumptions of any kind can be made about what the href to a file will look like in any epub.

BeckyEbook · 09-10-2020, 01:29 PM

CssFromFonts IS updated by Doitsu to work with Sigil v1.x
https://www.mobileread.com/forums/sh...0&postcount=17

DiapDealer · 09-10-2020, 01:35 PM

Quote:

Originally Posted by BeckyEbook

CssFromFonts IS updated by Doitsu to work with Sigil v1.x
https://www.mobileread.com/forums/sh...0&postcount=17

Good to know, thanks! I just didn't see a changelog, nor any mention of it specifically in the thread.

DiapDealer · 09-10-2020, 02:05 PM

@KevinH, do you know if the plugin framework's bk.addfile function honors a custom epub layout? I ask because the plugin in question (CssFromFont) will always create a "Styles/font.css" file if no css files exist. Even if the epub was created using a custom flat epub layout. But it's not the plugin requiring the creation of the "Styles" folder that I can see.

If I create a completely flat custom epub layout, and add font files to the new epub, they are properly added to the root of the epub. If I add an empty stylesheet file from the Sigil context menu, it correctly adds it to the root of the epub. But for some reason, the call to bk.addfile() in the plugin will always create the "Styles" subfolder if no css file exists in the epub for the plugin to modify. That's why I'm curious about how bk.addfile goes about determining where a file should be created (and if it honors a custom epub layout).

KevinH · 09-10-2020, 02:11 PM

It will add the file to whatever folder is default for that resource type at the time the plugin is launched. The default is determined by the folder with the largest number of resources of that type when the plugin is launched. If none exist the it can default to a "standard" location.

The only way to fully control the path is to use the new plugin method to add a file with a specific full book root relative path.

KevinH · 09-10-2020, 02:24 PM

I checked and for groups (think of resource types here) that have no instances, a guess is made based on the current resource type and backfilled into the default for that type.

This is done when the opf is parsed.

See the code after here:

https://github.com/Sigil-Ebook/Sigil...parser.py#L278

It uses the resource type (case adjusted to match existing uses of case) as the default folder path. This was to match standard locations by default unless otherwise specified.

I personally like to use bk.addbookpath() in Sigil plugins post Sigil 1.0 when I want to control the exact path.

FWIW, Another approach I have used in my own plugins is to use normal addfile to create the file but with empty data and the use its returned id to get its bookpath (whatever that turned out to be) and then write any adjusted contents to that added but empty file.

DiapDealer · 09-10-2020, 02:51 PM

I'll take a look, thanks.

I just thought it a little odd that while Sigil itself knew to add a new blank stylesheet to the correct location specified by the Sigil custom epub layout (the epub root--no subfolder), bk.addfile seemed to assume the traditional "Styles" location was the better choice. Not a big deal, I just want to be sure I understand.

KevinH · 09-10-2020, 03:20 PM

They will always match if at least one resource of that type already exist. The code in both works similarly like that. It is just in the plugin that has no access to the epub design, but must make decisions based on what info it can extract from the opf of the epub itself.

Leonatus · 09-12-2020, 09:57 AM

Though I didn't understand so much at last, I would like to thank all for their help!

09-10-2020, 08:24 AM	#16
DiapDealer Grand Sorcerer Posts: 28,341 Karma: 203719646 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	Sigil (as of v1.0) no longer forces epubs into its traditional folder structure (OEBPS/Text, Images, Fonts, css) when opening them. It will work with whatever structure an epub was created with. Many epubs are constructed in that manner already, but many are not. When inserting files, you need to check what their actual path IS before manually adding links to them. The path can usually be seen in the tooltip when hovering over the file in BookBrowser. You can also see the paths using the Reports tool, or you can see the paths (relative to the OPF) in the OPF manifest using the href property value. I have no experience using the CssFromFont plugin, but my guess is that it might not have been updated to work properly with the changes introduced (RE not automatically restructuring all epubs) in Sigil 1.0. We gave advanced notice of the changes to plugin devs, but not all took the steps to meet the changes. For those that didn't, they advise users to always run the "Restructure" tool before using their plugins. I see no mention of that plugin being updated for the Sigil v1.0 changes, so the advice to always "Restructure" first will apply if you want to continue using it. "Non-standard epub" is probably not the perfect phrase, but for lack of a better one ... What is meant is an epub that's not created using Sigil's historical, traditional folder hierarchy. There's never been any sort of requirement that epubs use a standard folder structure--and they don't. Sigil now honors the structure an epub was created with. It no longer forces each and every epub into its own proprietary structure. The idea is to change nothing about an epub that doesn't need to be changed. But you can still manually do so with Sigil's Restructure tool. Calibre's editor also has a tool to restructure epubs and create specific folders for file-types that can be manually run. The bottom line is that unless you manually run the Restructure tool first, no assumptions of any kind can be made about what the href to a file will look like in any epub. Last edited by DiapDealer; 09-10-2020 at 10:40 AM.

09-10-2020, 02:24 PM	#21
KevinH Sigil Developer Posts: 8,439 Karma: 5703082 Join Date: Nov 2009 Device: many	I checked and for groups (think of resource types here) that have no instances, a guess is made based on the current resource type and backfilled into the default for that type. This is done when the opf is parsed. See the code after here: https://github.com/Sigil-Ebook/Sigil...parser.py#L278 It uses the resource type (case adjusted to match existing uses of case) as the default folder path. This was to match standard locations by default unless otherwise specified. I personally like to use bk.addbookpath() in Sigil plugins post Sigil 1.0 when I want to control the exact path. FWIW, Another approach I have used in my own plugins is to use normal addfile to create the file but with empty data and the use its returned id to get its bookpath (whatever that turned out to be) and then write any adjusted contents to that added but empty file. Last edited by KevinH; 09-10-2020 at 02:31 PM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Referenced resource could not be found	ksrives	Calibre	0	12-13-2018 05:23 PM
Strange behaviour with "not referenced" files	Phssthpok	Editor	4	10-21-2015 10:43 AM
Referenced resource not found	DeborahM	ePub	2	09-26-2015 05:13 AM
Javascript files not referenced in ebook-editor	dmonasse	Editor	2	04-17-2014 07:37 AM
Opening of referenced PDF file	DrBibber	iRex	2	07-30-2006 09:28 PM

09-10-2020, 01:29 PM	#17
BeckyEbook Guru Posts: 808 Karma: 2416112 Join Date: Jan 2017 Location: Poland Device: Various	CssFromFonts IS updated by Doitsu to work with Sigil v1.x https://www.mobileread.com/forums/sh...0&postcount=17

09-10-2020, 02:05 PM	#19
DiapDealer Grand Sorcerer Posts: 28,341 Karma: 203719646 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	@KevinH, do you know if the plugin framework's bk.addfile function honors a custom epub layout? I ask because the plugin in question (CssFromFont) will always create a "Styles/font.css" file if no css files exist. Even if the epub was created using a custom flat epub layout. But it's not the plugin requiring the creation of the "Styles" folder that I can see. If I create a completely flat custom epub layout, and add font files to the new epub, they are properly added to the root of the epub. If I add an empty stylesheet file from the Sigil context menu, it correctly adds it to the root of the epub. But for some reason, the call to bk.addfile() in the plugin will always create the "Styles" subfolder if no css file exists in the epub for the plugin to modify. That's why I'm curious about how bk.addfile goes about determining where a file should be created (and if it honors a custom epub layout).

09-10-2020, 02:11 PM	#20
KevinH Sigil Developer Posts: 8,439 Karma: 5703082 Join Date: Nov 2009 Device: many	It will add the file to whatever folder is default for that resource type at the time the plugin is launched. The default is determined by the folder with the largest number of resources of that type when the plugin is launched. If none exist the it can default to a "standard" location. The only way to fully control the path is to use the new plugin method to add a file with a specific full book root relative path.

09-10-2020, 02:51 PM	#22
DiapDealer Grand Sorcerer Posts: 28,341 Karma: 203719646 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	I'll take a look, thanks. I just thought it a little odd that while Sigil itself knew to add a new blank stylesheet to the correct location specified by the Sigil custom epub layout (the epub root--no subfolder), bk.addfile seemed to assume the traditional "Styles" location was the better choice. Not a big deal, I just want to be sure I understand.

09-10-2020, 03:20 PM	#23
KevinH Sigil Developer Posts: 8,439 Karma: 5703082 Join Date: Nov 2009 Device: many	They will always match if at least one resource of that type already exist. The code in both works similarly like that. It is just in the plugin that has no access to the epub design, but must make decisions based on what info it can extract from the opf of the epub itself.

09-12-2020, 09:57 AM	#24
Leonatus Wizard Posts: 1,050 Karma: 11391181 Join Date: Mar 2013 Location: Guben, Brandenburg, Germany Device: Kobo Clara 2E, Tolino Shine 3	Though I didn't understand so much at last, I would like to thank all for their help!