Plugin Development - Page 25

Doitsu · 02-26-2018, 02:09 PM

@KevinH: Thanks for the clarification.

KevinH · 02-26-2018, 02:21 PM

ps: I just uploaded a fixed cfitest.epub with that missing content.opf id added back.

So hopefully, if the ACE Checker output puts out normal epubcfis and an error string, you should be able to collect the epubcfi, and error strings and run this through the cfi_convert for that epub and build up the needed validation results.

You may have to correct a few things to make it match exactly in Sigil as you have done in other validation plugins, but there should be enough info provided to fix up what you need (I hope).

Just let me know if I can help or answer any questions.

Doitsu · 02-26-2018, 02:35 PM

Quote:

Originally Posted by KevinH

So hopefully, if the ACE Checker output puts out normal epubcfis and an error string, you should be able to collect the epubcfi, and error strings and run this through the cfi_convert for that epub and build up the needed validation results.

The epubcfis generate by ACE use a slightly different format, but it shouldn't be too complicated to reformat them for use with your code.
Thanks again for your help!

KevinH · 02-26-2018, 02:38 PM

No problems. If you can post a sample epub and a list of epubcfis, I would be happy to modify the code to support that format.

KevinH · 02-26-2018, 03:37 PM

FWIW, I took a look at the Daisy ACE github project and searched for epubcfi and what they report is an specific filename/href followed by a nodepath in that file with no assertions at all. These are not legal epubcfis according to the spec.

Instead they remove the entire content.opf and its spine redirection nonsense and just tell you which file to use. Effectively, they remove everything up to and including the first ! point of the epubcfi and just provide the node path after the proper file has been identified.

That way they are not limited to files directly listed in the spine (things like the nav may not be there, etc).

Their approach actually makes more sense and it would make the conversion code easier as we could ignore the whole spine redirection piece of the code.

I tried to put lots of comments in cfi_convert.py so hopefully you can follow along and understand what is going on and what a nodepath by comparing it to the example part of the idpf spec document here:

http://www.idpf.org/epub/linking/cfi...-path-examples

Doitsu · 02-26-2018, 04:32 PM

Quote:

Originally Posted by KevinH

Instead they remove the entire content.opf and its spine redirection nonsense and just tell you which file to use. Effectively, they remove everything up to and including the first ! point of the epubcfi and just provide the node path after the proper file has been identified.

I still don't fully understand the epubcfi format. For example, for a test epub3 book that I created ACE reported the following non-standard epubcfi:

Code:

Text/Section0001.xhtml#epubcfi(/4/4)

The actual Section0001.xhtml HTML code is:

Spoiler:

Assuming that Section0001.xhtml is the second spine entry, how would I need to reformat the above non-standard ACE epubcfi for use with your code?

The actual spine looks like this:

Spoiler:

KevinH · 02-26-2018, 04:52 PM

To make it a more official epubcfi, you would need to convert it to be:

epubcfi(/6/4!/4/4)

The first /6 tells it to find the 3rd tag child on the content.opf package tag, which is the spine, and then the /4 means to take the second tag child of the spine tag (the itemref for Section0001.xhtml). The ! means to follow the idref to access the correct file href in the manifest and redirect to it.

The remainder /4/4 from your cfi says to start with the html tag of the target file and take its 2nd tag child (body) and then the 2nd tag child of the body tag which is the line with the p tag with the epub:type="dedication" attribute.

If a node path ends with a n odd node number, it means it is a text node and a character offset into the text would be added after a : .

So for example, an epubcfi(/6/4/4/4/1:10) should point to the "d" in the word "dedication" in the text node with the string "This is a dedication."

Hope this helps.

KevinH

Quote:

Originally Posted by Doitsu

I still don't fully understand the epubcfi format. For example, for a test epub3 book that I created ACE reported the following non-standard epubcfi:

Code:

Text/Section0001.xhtml#epubcfi(/4/4)

The actual Section0001.xhtml HTML code is:

Spoiler:

Assuming that Section0001.xhtml is the second spine entry, how would I need to reformat the above non-standard ACE epubcfi for use with your code?

The actual spine looks like this:

Spoiler:

KevinH · 02-26-2018, 05:01 PM

Alternatively we can easily modify cfi_convert to be passed in a file href, and a simple nodepath instead of a full epubcfi if that would help.

Doitsu · 02-27-2018, 03:09 AM

Quote:

Originally Posted by KevinH

Alternatively we can easily modify cfi_convert to be passed in a file href, and a simple nodepath instead of a full epubcfi if that would help.

Thanks again for your help and the epubcfi tutorial. I finally figured it out. There's no need to modify cfi_convert. If all goes well, I'll release a new version of my ACE plugin in a couple of days.

BeckyEbook · 03-06-2018, 06:33 PM

Could I ask you for a tiny example of using bk.setguide?

DiapDealer · 03-06-2018, 07:45 PM

Consider the following guide section from an OPF file:

Code:

  <guide>
    <reference type="start" title="Start" href="Text/file1.xhtml"/>
    <reference type="toc" title="Table of Contents" href="Text/toc.xhtml"/>
    <reference type="thumbimagestandard" title="thumbimagestandard" href="Images/thumb.jpg"/>
    <reference type="copyright-page" title="Copyright" href="Text/copy.xhtml"/>
    <reference type="cover" title="Cover" href="Text/titlepage.xhtml"/>
  </guide>

bk.getguide() would return the following list of tuples:

Code:

[('start', 'Start', 'Text/file1.xhtml'), ('toc', 'Table of Contents', 'Text/toc.xhtml'), ('thumbimagestandard', 'thumbimagestandard', 'Images/thumb.jpg'), ('copyright-page', 'Copyright', 'Text/copy.xhtm'), ('cover', 'Cover', 'Text/titlepage.xhtml')]

If you wanted to programatically remove the thumbimagestandard reference item from the Guide, then you would do so with:

Code:

bk.setguide([('start', 'Start', 'Text/file1.xhtml'), ('toc', 'Table of Contents', 'Text/toc.xhtml'), ('copyright-page', 'Copyright', 'Text/copy.xhtm'), ('cover', 'Cover', 'Text/titlepage.xhtml')])

Each tuple in both (set|get)guide is three-member tuple comprised of (type, title, href).

BeckyEbook · 03-07-2018, 02:13 AM

Thank you. Now I understand.

Of course getguide and setguide.

DiapDealer · 03-07-2018, 05:59 AM

Quote:

Originally Posted by BeckyEbook

Thank you. Now I understand.

Of course getguide and setguide.

Well, yes. The correct function names would have been much better.

I'll correct them.

Doitsu · 03-23-2018, 11:41 AM

@DiapDealer & @KevinH:

Many of my plugins are simple wrappers for tools written by somebody else. Most of these tools are rarely updated, but some of them, e.g. fonttools, are updated almost every month.

I'm wondering if it'd OK, if I modified the font subsetting plugin to check for updates on Github and then directly update the embedded Python package in the plugin folder.
I.e., it'd download the updated package from the GitHub page of the fonttools developers and replace the package that I originally bundled the plugin with.

This would save me the hassle of releasing a new plugin version every month.

However, I vaguely remember having read somewhere that "self-modifying code" is generally frowned upon...

KevinH · 03-23-2018, 12:15 PM

Good question. At the MacOSX level all application code is checksummed (cryptographically hashed) and so self-modifying code would be detected and might prevent the launch depending on user settings. There are always questions about scripted languages that are not compiled (or dynamically compiled) and what happens then.

That said ... doing this is a plugin folder means it is not directly part of the Sigil application and so would not and is not part of the signed executable process used on Macs. But it could still be detected by some antivirus or security software and might cause a error on some systems.

So technically, I think self-modifying code in a plugin folder may work now, I am not sure it would work in the future depending on how secure the system it is used on needs to be.

Are the fixes in fonttools really needed? Is there some way to have your plugin check if there are important updates to fonttools, and if so ask the user to update it manually. Or somehow host the latest fonttools someplace ready to be installed someplace separately by the user and then ask them where and then use what the user has installed by adding it to the python PATH early in the plugin?

03-23-2018, 11:41 AM	#374
Doitsu Grand Sorcerer Posts: 5,731 Karma: 24031401 Join Date: Dec 2010 Device: Kindle PW2	Can I release self-modifying plugins? @DiapDealer & @KevinH: Many of my plugins are simple wrappers for tools written by somebody else. Most of these tools are rarely updated, but some of them, e.g. fonttools, are updated almost every month. I'm wondering if it'd OK, if I modified the font subsetting plugin to check for updates on Github and then directly update the embedded Python package in the plugin folder. I.e., it'd download the updated package from the GitHub page of the fonttools developers and replace the package that I originally bundled the plugin with. This would save me the hassle of releasing a new plugin version every month. However, I vaguely remember having read somewhere that "self-modifying code" is generally frowned upon...

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Loading Plugin in development	Sladd	Development	6	06-17-2014 06:57 PM
Question for plugin development gurus	DiapDealer	Plugins	2	02-04-2012 11:33 PM
DR800 Plugin development for DR800/DR1000	yuri_b	iRex Developer's Corner	0	09-18-2010 09:46 AM
Device plugin development	reader42	Plugins	10	03-29-2010 12:39 PM
Calibre plugin development - Newbie problems	minstrel	Plugins	5	04-12-2009 12:44 PM

02-26-2018, 02:09 PM	#361
Doitsu Grand Sorcerer Posts: 5,731 Karma: 24031401 Join Date: Dec 2010 Device: Kindle PW2	@KevinH: Thanks for the clarification.

02-26-2018, 02:21 PM	#362
KevinH Sigil Developer Posts: 8,783 Karma: 6000000 Join Date: Nov 2009 Device: many	ps: I just uploaded a fixed cfitest.epub with that missing content.opf id added back. So hopefully, if the ACE Checker output puts out normal epubcfis and an error string, you should be able to collect the epubcfi, and error strings and run this through the cfi_convert for that epub and build up the needed validation results. You may have to correct a few things to make it match exactly in Sigil as you have done in other validation plugins, but there should be enough info provided to fix up what you need (I hope). Just let me know if I can help or answer any questions.

02-26-2018, 02:38 PM	#364
KevinH Sigil Developer Posts: 8,783 Karma: 6000000 Join Date: Nov 2009 Device: many	No problems. If you can post a sample epub and a list of epubcfis, I would be happy to modify the code to support that format.

02-26-2018, 03:37 PM	#365
KevinH Sigil Developer Posts: 8,783 Karma: 6000000 Join Date: Nov 2009 Device: many	FWIW, I took a look at the Daisy ACE github project and searched for epubcfi and what they report is an specific filename/href followed by a nodepath in that file with no assertions at all. These are not legal epubcfis according to the spec. Instead they remove the entire content.opf and its spine redirection nonsense and just tell you which file to use. Effectively, they remove everything up to and including the first ! point of the epubcfi and just provide the node path after the proper file has been identified. That way they are not limited to files directly listed in the spine (things like the nav may not be there, etc). Their approach actually makes more sense and it would make the conversion code easier as we could ignore the whole spine redirection piece of the code. I tried to put lots of comments in cfi_convert.py so hopefully you can follow along and understand what is going on and what a nodepath by comparing it to the example part of the idpf spec document here: http://www.idpf.org/epub/linking/cfi...-path-examples

02-26-2018, 05:01 PM	#368
KevinH Sigil Developer Posts: 8,783 Karma: 6000000 Join Date: Nov 2009 Device: many	Alternatively we can easily modify cfi_convert to be passed in a file href, and a simple nodepath instead of a full epubcfi if that would help.

03-06-2018, 06:33 PM	#370
BeckyEbook Guru Posts: 842 Karma: 3335974 Join Date: Jan 2017 Location: Poland Device: Various	Could I ask you for a tiny example of using bk.setguide?

03-07-2018, 02:13 AM	#372
BeckyEbook Guru Posts: 842 Karma: 3335974 Join Date: Jan 2017 Location: Poland Device: Various	Thank you. Now I understand. Of course getguide and setguide.

03-23-2018, 12:15 PM	#375
KevinH Sigil Developer Posts: 8,783 Karma: 6000000 Join Date: Nov 2009 Device: many	Good question. At the MacOSX level all application code is checksummed (cryptographically hashed) and so self-modifying code would be detected and might prevent the launch depending on user settings. There are always questions about scripted languages that are not compiled (or dynamically compiled) and what happens then. That said ... doing this is a plugin folder means it is not directly part of the Sigil application and so would not and is not part of the signed executable process used on Macs. But it could still be detected by some antivirus or security software and might cause a error on some systems. So technically, I think self-modifying code in a plugin folder may work now, I am not sure it would work in the future depending on how secure the system it is used on needs to be. Are the fixes in fonttools really needed? Is there some way to have your plugin check if there are important updates to fonttools, and if so ask the user to update it manually. Or somehow host the latest fonttools someplace ready to be installed someplace separately by the user and then ask them where and then use what the user has installed by adding it to the python PATH early in the plugin?

Advert

Advert