|
I simply use Sigil's "Edit TOC" function. No need to add any code in the html file.
|
Quote:
That's what I used to do. And you have to do it again every time you move or add anything. If you tag your files rebuilding the TOC is one click. Quote:
|
When using this to add pages to an epub3, there are a couple of issues.
I use the plugin to create an SVG page, and run epubcheck. It reports: ERROR(HTM-004): Irregular DOCTYPE: found '-//W3C//DTD XHTML 1.1//EN', expected '<!DOCTYPE html>'. ERROR(OPF-014): The property 'svg' should be declared in the OPF file. In the OPF I find that this was added to the manifest: <item id="SVG_LSSquad" href="Text/SVG_LSSquad.xhtml" media-type="application/xhtml+xml" /> epub3 needs properties="svg" to be added to this: <item id="SVG_LSSquad" href="Text/SVG_LSSquad.xhtml" media-type="application/xhtml+xml" properties="svg"/> This is done if I use the "Epub3 tools/Update manifest properties" from Sigil's menu, but would be nice if the plugin did it. The Doctype error though is still there. The SVG file has this in its header: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> this needs to be changed to : <!DOCTYPE html> |
If it helps ... you should be able to run Mend all and it should fix the any bad DOCTYPE headers it finds. There is also a epub3 specific menu to regenerate the opf manifest properties that should properly add the svg property to the manifest. Although not a long-term fix, these two simple menu items should help handle this issue until epub3 compatibility is added to this plugin.
|
Quote:
I knew about the "Update manifest properties" tool, but not that "Mend" would fix the header. I can't find an explanation of what "Mend code" does, it's not in the the last version of the Sigil User Guide (0.7.2, as far as I know). Is there any documentation of just what it does? |
Mend is the replacement for HTMLTidy. The difference being that Mend doesn't break anything or randomly eat any content (or create any extraneous css) like Tidy used to do. It fixes broken xhtml (and it knows what headers are required for epub2 vs epub3).
If you've not disabled Mend on Open/Save in your preferences (and I don't recommend anyone disable it), then you've been using Mend every Open/Save. |
@AlanHK: If you only work with epub3 files, you could temporarily patch plugin.py as follows:
change line 326: Code:
xml += '<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">\n'Code:
xml += '<!DOCTYPE html>\n'Code:
self.bk1.addfile(uid, basename, xml, mime)Code:
self.bk1.addfile(uid, basename, xml, mime, 'svg') |
Quote:
BR |
Quote:
It looks like the plugin creator CalibUser hasn't been here for 6 months. So unless someone adopts it it may never be updated. I've got no experience with Python so couldn't undertake it myself, even it was kosher to do that. Quote:
|
Epub2 and EPub 3
1 Attachment(s)
Hi,
I have tried to update the plugin to cope with epub 2 and epub 3 books (attached). However, the plugin enters a loop so that when the plugin finishes running it runs again. As I have been coding in another language for the last 6 months I may have confused that code with Python and done something stupid. Can anybody spot my error? Thanks |
No error. This will happen the first time you install a plugin (this bug was fixed in master). After installing a plugin the first time, simply close out of Sigil and restart it to work around this problem.
|
Thanks, Kevin, I did not realise this bug existed.
I have uploaded an updated version of the plugin to the first post in this thread. The plugin will work with both epub 2 and epub 3 books. Thanks to Doitsu for identifying the changes needed - this saved me time. |
2 Attachment(s)
Hi
Image numbering Thank you for this very useful plugin. I found that the numbering of images of the plugin differs from the one of the file manager. This could be confusing and requires extra care from the user when he (she) wishes to insert many images. I think that the numbering which should be used by the plugin should be the same as the one used by the file manager (right screenshot). see ePub3 screenshots for clearer explanations: |
@roger64: I'm glad you find my plugin useful.
I looked at the issue your raised but must admit that I don't understand it. When 'Import image' is selected it shows a list of files that are available in the selected folder on your hard drive (including any numbers that are in their filenames). If you select a file from this list and click 'Insert' then the relevant file is imported into Sigil using exactly the same name as the original file on the disk. If this included a number then this is included in the filename of the imported file in the 'Images' section. Are you finding that the number in the filename is changing when it is imported into the ePub? Could it be that the images are listed in a different order in the 'Images' section of the ePub to that in the folder and this is causing confusion? Another thought - I have only tested this on Windows 7 as I don't have access to other computers. Are you using a different OS? |
I am using Linux. Follow the numbers one by one please.
The screenshot on the left shows the numbers begin with the waist down then the head down, while on the right it goes from head to foot. Each image keeps its own number but why display them in that broken order? |
@CalibUser...I think roger64 is asking if you could just do an ascending top down sort of the image filenames before they are displayed in your dialog.
|
Thank you slowsmile. Human communication is tough at times... :)
Let me count sequentially (i.e. reading from top to bottom), plugin-wise: 001, 010, 011, 012, 013, 014, 015, 016, 017, 018*, 002, 003, 004, 005, 006, 007, 008, 009 To compare with Sigil 001, 002, 003, 004, 005, 006, 007, 008, 009, 010, 011, 012, 013, 014, 015, 016, 017, 018* *The book contains 18 images so there is no 019. Take the first number (three digits) of each of these two lists above which is the same 001 (luck!). The number following immediately this number 001 (I mean on its right) is NOT the same for the plugin than for Sigil. One of them may be wrong. :D |
Ah, I see what you mean. Thanks for clarifying, slowsmile.
I will look at this as soon as I can, although I may not get time to do it this coming weekend. |
You are welcome. Thank you for taking care of this detail. :)
|
I have updated the plugin so that the list of images are shown in alphanumerical order.
The update is attached to the first post in this thread. |
Thank you :D
|
It seams the plugin does not insert the svg.xhtml page where you choose to insert (after, before, etc), but several pages above.
Anybody has experienced the same behaviour? Using latest Sigil and Plugin. Thanks |
Quote:
And looking at the code, I see why it doesn't work, but I'm not certain how quick or easy the fix would be. If there was a one-line change I could give to correct it, I would. You'll probably have to wait on the plugin creator to notice this. Suffice to say: the code should probably be using bk.spine_iter() instead of bk.text_iter. And sorting the xhtml files before loading them int0 the combo box is a mistake. |
Actually, it's not that difficult. It would take a minor reworking to make it more robust, but someone should be able to get by with changing line 194 of plugin.py from:
Code:
for id, href in self.bk1.text_iter():Code:
for id, linear, href in self.bk1.spine_iter():From: Code:
self.cbXhtmlList=self.natural_sort(self.cbXhtmlList) #Sort the list of imagesCode:
#self.cbXhtmlList=self.natural_sort(self.cbXhtmlList) #Sort the list of images |
Thanks i will give that a try.
|
I have updated the plugin to version 1.6.1 to correct the bug mentioned by Thomas_AR. The bug was introduced in version 1.6.0
Thanks to DiapDealer for spotting the bug. |
Is it normal the svg import image with a smaller width and hight?
I have a photo 1000px x 1511px But the viewBox will become "0 0 260 400" and the image size will become width="260" height="400" |
Quote:
I want this function too. It will much easier to make comic Epub |
Hi
This is a proposal. One example coming from an ePub3 produced by LibreOffice. The original cover file is described with an item in both the toc.xhtml and the toc.ncx. If you change this original file with a SVG wrapper using this fine plugin, and then delete the original file, the new SVG wrapper file name is not updated in both tocs. epubcheck reports then that the original file is missing and you have to change the name of this file manually. It could concern, not only the cover images, but some images within the ePub as well. Could this last task (updating the tocs) be performed automatically? |
I'm not sure that makes sense, Roger. This plugin creates a new xhtml file out of an image you specify. It doesn't change any existing files and it has no preconceived notions about what you want to do with the newly created one (SVG wrapped images can occur anywhere on an epub). Once this new xhtml file has been created, it's up to you (the user) to decide if it is to be used as the cover page, or if it needs to be included in any html toc or nav documents, or what-have-you.
If you're looking to modify an existing cover page in an epub, I suggest using the built-in Tools->Add Cover feature of Sigil. It will take an image of your choosing, wrap it in an SVG and either create a new cover.xhtml (if no cover-page is already defined), or it modifies an existing cover page (if one is already defined). All pre-existing links would remain intact. |
@DiapDealer
Thanks for your reply. It was just a proposal, if there had been an easy way to do it...:) When the cover page file name is present in both tocs (it does not happen all the time, it depends of the tool used to produce en ePub) and needs to be changed, I'll rather use the Sigil built-in tool that I did not have considered. |
Quote:
If there are any ID anchors in the original file, you can preserve them or adjust any links to them to just be to the file, not the anchor. Epubcheck will tell you if you need to do that. If it's a cover image, as long as the original cover file was tagged as "Cover" (in the OPF), then the Sigil built-in "Add cover" will overwrite it, again preserving all links. Possibly the SVG plugin could have an additional option allowing you to choose the target filename, either the default (new) one as now or an existing one to overwrite. |
Quote:
Code:
<svg |
More than likely, the image's actual size is not being correctly retrieved by the PIL Python library. This would imply to me that there's probably something wrong with the original images in general. Is ffdl-0.jpg an actual jpg, or does it just have a .jpg extension? How was it created? Are other images' sizes being correctly determined by the plugin, or is it just some images?
Can you share an image that the plugin is "getting wrong?" That would probably be the most helpful thing for debugging purposes. |
Same issue here with every image i inserted since i use this plugin.
Greetings from the cold Buenos Aires Thomas |
He's inadvertently thumbnailing self.img with PIL (to display it in the Tk widget). So when self.img.size is called later on, the new smaller thumbnail size is the one being returned.
Lots of different ways to tackle correcting it. A down-and-dirty-way to get it going would be to make a few similar changes in two different locations. In plugin.py (latest version) starting with line #255 change: Code:
self.img = Image.open(BytesIO(bkImage))Code:
img_temp = Image.open(BytesIO(bkImage))And in plugin.py line #275 (before the above change) change: Code:
self.img = Image.open(filehandle.name)Code:
img_temp = Image.open(filehandle.name) |
Quote:
|
Quote:
It was an easy mistake to make. It's not immediately clear that the image.thumbnail() function of Pillow is actually altering the original image, rather than returning a new, smaller copy of it. |
Quote:
So I hope what it is doing now can be clarified: does it downsample to 400px? PS-- did some tests. I made a PNG with 1 px lines 1 px apart, image size 800x800. the SVG plugin made: Code:
<div><svg Code:
<div><svg If I resize the PNG in PhotoShop to 400x400, the lines blur into each other, as the gap becomes 0.5 px. So, the plugin isn't resampling. It's silly, but not degrading the image. PPS-- Took it the other way and made the "thumbnail" size even smaller. All looked fine, even down to: Code:
<div><svg |
No. The image itself is not being downsampled. The SVG wrapper is limiting the viewbox to 400 pixels on the longest side. Which is essentially the same thing for display purposes. The plugin is making a mistake in this regard. There's no question about that. I've posted a potential fix.
|
| All times are GMT -4. The time now is 08:04 PM. |
Powered by: vBulletin
Copyright ©2000 - 3.8.5, Jelsoft Enterprises Ltd.
MobileRead.com is a privately owned, operated and funded community.