Is there a way or plugin/script to generate a list of images in the epub (loi.xhtml)?

[Doitsu]

Originally Posted by KevinH

In case of figure or div or svg parent of the img tag, shouldn't the id be added to that parent and not the img tag itself?

That's definitely the better approach.

Originally Posted by KevinH

Also a template_loi.xhtml might prove useful, don't you think?

Also a good idea, because it'd allow users to customize the LOI string.

[KevinH]

Okay.

I still think it is important to give precedence to any title attribute on the figure tag over the figcaption and/or the alt for that image's descriptive string. I have many epubs with images where the captions are quite long and involved and the alt strings more describe the image than title it.

That way, a person can add a short title attribute value to the figure tag with a proper edited title so that if they have to re-run the loi plugin generator 2 or more times they do not have to constantly edit to shorten the alt or figcaption values. In other words it gives the editor the ability to control what is there without needing to shorten or edit either the alt or the figcaption.

[Doitsu]

Originally Posted by KevinH

I still think it is important to give precedence to any title attribute on the figure tag over the figcaption and/or the alt for that image's descriptive string. I have many epubs with images where the captions are quite long and involved and the alt strings more describe the image than title it.

OK.

[JSWolf]

Originally Posted by KevinH

I'd say that standardepubs are a bit over the top with their "standardization".

If there's a more complicated way to format (HTML/CSS) eBooks with simple formatting, nobody will do it worse/more complicated then Standard Ebooks.

They feel that they have to use the latest code that doesn't work in a lot of cases. They just don't do it correctly. Some of their CSS doesn't work in ADE and causes the entire CSS to be ignored. It's a right mess.

Lets first hear from others about what they think about the idea of a list of illustrations plugin for Sigil and how it should work if we made one.

As for a plugin to make a list of images, one thing the plugin cannot do is describe the images. That's something you would have to add in by hand to each image. Most eBooks don't have descriptive image names. And if you were to convert KF8 to ePub, if there ever were descriptive image names, they would be lost. So you would have to go through each image and manually put in a description of the image in the list. The easiest way to do it is for the plugin to display each image and allow you to type in the description. The plugin would have to look through the HTML code to see what the order is of the images. I cannot say how easy such a plugin would be to write. It's not a case of make a list of the images and done.

[KevinH]

The more I think about this, we need to screen out tiny/inline images used in place of symbols, or for drop caps, or for scene breaks, or ...

Here is standardebooks view on LOI:

The LoI only contains links to images that are major structural components of the work.

An illustration is a major structural component if, for example: it is an illustration of events in the book, like a full-page drawing or end-of-chapter decoration; it is essential to the plot, like a diagram of a murder scene or a map; or it is a component of the text, like photographs in a documentary narrative.

An illustration is not a major structural components if, for example: it is a drawing used to represent a person’s signature, like an X mark; it is an inline drawing representing text in alien languages; it is a drawing used as a layout element to illustrate forms, tables, or diagrams.

So I think based on this we only include img tags who are direct children of figure or div tags
(and *not* children of inline tags or tags like p, h1-h6, span, etc.)

Once I get that working, we can expand the search to include svg tags with image tags as children (or even all svg tags).

The list of files to be processed will be limited to those in the spine and the loi will be built up in spine order from top to bottom of each file while skipping the cover and NAV files themselves.

I think sigil_bs4 would be best so we can use css selectors to identify the nodes, parents, and to find all values of id attributes already used in that file to prevent duplicates.

When I get something working roughly, I will post it here for people to test with.

[JSWolf]

Originally Posted by Doitsu

[*]If no <figcaption> sibling exists or the <figcaption> string is empty, use the alt attribute value. [*]If no alt attribute exists or it's empty, use the image basename as the title.

This won't work. In many cases I've seen alt="image" or other stuff that's nothing to do with the images. And the filenames are less then helpful in most cases. It would be best if the plugin displayed the image and the the user type in the description. The figcaption text could be too long or not appropriate if there was such. Most eBooks don't have a figcaption. There's no way to fully automate the plugin so there is nothing for the user to do but run it.

[KevinH]

Originally Posted by JSWolf

As for a plugin to make a list of images, one thing the plugin cannot do is describe the images. That's something you would have to add in by hand to each image. Most eBooks don't have descriptive image names. And if you were to convert KF8 to ePub, if there ever were descriptive image names, they would be lost. So you would have to go through each image and manually put in a description of the image in the list. The easiest way to do it is for the plugin to display each image and allow you to type in the description. The plugin would have to look through the HTML code to see what the order is of the images. I cannot say how easy such a plugin would be to write. It's not a case of make a list of the images and done.

Actually it is not a list of images but a list of illustrations to be pedantic. And the descriptor generation algorithm was already described above and the use of the title attribute on the parent div or figure can be used to handle any customization of the description.

FWIW, Sigil's Access-Aide plugin already generates a list of images with thumbnails and allows the user to edit/generate "alt" descriptors quite easily. So all that has long existed using Sigil plugins.

So running this loi generator on an accessible epub (ie. with proper alt values) is easily handled with running the Access-Aide plugin first.

And the results may still need to be edited, and that is okay.

[Doitsu]

Originally Posted by KevinH

So I think based on this we only include img tags who are direct children of figure or div tags
(and *not* children of inline tags or tags like p, h1-h6, span, etc.)

IMHO, that's a good idea. I'm sure that some epub creators will complain about it, but wrapping <img> tags in <div> or <figure> tags can be easily done with a Saved Search.
Epub creators could also take advantage of this requirement by wrapping decorative images in dummy <span> tags to prevent them from being added to the List of Illustrations.

[KevinH]

Originally Posted by Doitsu

IMHO, that's a good idea. I'm sure that some epub creators will complain about it, but wrapping <img> tags in <div> or <figure> tags can be easily done with a Saved Search.
Epub creators could also take advantage of this requirement by wrapping decorative images in dummy <span> tags to prevent them from being added to the List of Illustrations.

Agreed.

If need be we can use a plugin preferences settings to determine the set of allowed immediate parents (defaulting to div, and figure initially).

[KevinH]

Okay, attached is a proof of concept LOI generator and the output generated by the Mutiny On the Bounty test epub linked in Doitsu's post in this thread (and attached below for convenience).

This plugin is just a proof of concept and is designed to FAIL so you can see the debug output in the Plugin Runner Window. It builds no loi.xhtml file by design and instead just prints the basic info needed for the loi.xhtml, book path to file, id, and what descriptor it found.

It seems how we identify the descriptor string still needs some work as well as identifying usable ids so new ones do not always need to be inserted.

I post it here as a tool for refining the algorithms used to determine which images to include, where to get good descriptors, and which ids are usable.

This is not ready for use but more to play around with to see if this tool can be useful when in its finished form. Any changes and improvements to the plugin.py welcomed.

Please give it a try on your favourite epubs with lists of illustrations so we can compare what is detected and try to improve on it to make a useful tool.

Thanks in advance


Edit: removed older version of LOI-Generator plugin. See later posts in this thread for newer versions.

[KevinH]

Perhaps if no other description is found and the alt attribute on the image tag is missing, empty or just whitespace, that would be a good indicator that this is not an image suitable for a loi?

[DNSB]

I would agree with that conclusion.

[Doitsu]

Originally Posted by KevinH

Perhaps if no other description is found and the alt attribute on the image tag is missing, empty or just whitespace, that would be a good indicator that this is not an image suitable for a loi?

IMHO, using empty alt attributes to mark decorative images is a good approach, because that's exactly what DAISY recommends for decorative images.

I'd recommend the following approach for images without alt attributes:

• exclude them from the loi, but also add the image information to an error log
• add an alt="" attribute
• optional: add a role="presentation" attribute, but only in epub3 books
• display an error log listing all images without alt attributes

[KevinH]

I will make a change to leave out images with empty or missing alt attributes when no other descriptor is found.

But fixing missing alt attributes, and adding aria role information for epub3 are really the domain for other plugins as they have nothing directly to do with generating a loi. Especially when those images might later be used in a loi upon a second pass after editing by the epub developer, forcing them to delete the aria role from each.

I do agree that generating a log file of images that were not included is probably a good idea.

[KevinH]

Okay with those changes in place, the output looks very reasonable:

OEBPS/3295685525714288644_69363-h-0.htm.xhtml i_frontis PITCAIRN ISLAND.
OEBPS/3295685525714288644_69363-h-6.htm.xhtml image_016 MOORLAND CLOSE, CUMBERLAND, THE BIRTHPLACE OF FLETCHER CHRISTIAN.
OEBPS/3295685525714288644_69363-h-6.htm.xhtml image_019 gourd and book
OEBPS/3295685525714288644_69363-h-7.htm.xhtml image_026 THE LANDING PLACE, BOUNTY BAY.
OEBPS/3295685525714288644_69363-h-8.htm.xhtml image_036 BOUNTY BAY FROM THE CLIFFS.
OEBPS/3295685525714288644_69363-h-8.htm.xhtml image_042 THURSDAY OCTOBER CHRISTIAN.
OEBPS/3295685525714288644_69363-h-8.htm.xhtml image_044 Breadfruit
OEBPS/3295685525714288644_69363-h-9.htm.xhtml image_048 PATH THROUGH COCOANUT GROVE.
OEBPS/3295685525714288644_69363-h-9.htm.xhtml image_050 FIGURES CUT IN THE ROCKS AT THE ROPE.
OEBPS/3295685525714288644_69363-h-9.htm.xhtml image_052  MORINDA CITRIFOLIA.
OEBPS/3295685525714288644_69363-h-10.htm.xhtml image_058  THE CHAPEL.
OEBPS/3295685525714288644_69363-h-10.htm.xhtml image_063 GROUP OF ISLAND MAIDENS.
OEBPS/3295685525714288644_69363-h-11.htm.xhtml image_070 ROSA YOUNG.    ARTHUR YOUNG.
OEBPS/3295685525714288644_69363-h-11.htm.xhtml image_075 Headstone
OEBPS/3295685525714288644_69363-h-12.htm.xhtml image_080 PITCAIRN AVENUE.
OEBPS/3295685525714288644_69363-h-13.htm.xhtml image_090  GROUP OF NATIVE MEN.
OEBPS/3295685525714288644_69363-h-13.htm.xhtml image_096 Stem of flowers
OEBPS/3295685525714288644_69363-h-14.htm.xhtml image_100 THE ISLAND SAWMILL.
OEBPS/3295685525714288644_69363-h-15.htm.xhtml image_110 PARLIAMENT OF PITCAIRN ISLAND.
OEBPS/3295685525714288644_69363-h-15.htm.xhtml image_118 native bush
OEBPS/3295685525714288644_69363-h-16.htm.xhtml image_124 GROUP OF NATIVE CHILDREN.
OEBPS/3295685525714288644_69363-h-16.htm.xhtml image_126 butterfly on flowers
OEBPS/3295685525714288644_69363-h-17.htm.xhtml image_130 THE “PITCAIRN” AND MAN-OF-WAR OFF PITCAIRN ISLAND
OEBPS/3295685525714288644_69363-h-18.htm.xhtml image_140 FAMILY GROUP OF NATIVES.
OEBPS/3295685525714288644_69363-h-18.htm.xhtml image_147 a Pitcairn cottage
OEBPS/3295685525714288644_69363-h-19.htm.xhtml image_151 BREADFRUIT.
OEBPS/3295685525714288644_69363-h-19.htm.xhtml image_155 CHILDREN AND WHEELBARROW.
OEBPS/3295685525714288644_69363-h-20.htm.xhtml image_159 a small island
OEBPS/3295685525714288644_69363-h-20.htm.xhtml image_160 POINT LOOKOUT.
OEBPS/3295685525714288644_69363-h-20.htm.xhtml image_165 GROUP OF YOUNG MEN.
OEBPS/3295685525714288644_69363-h-22.htm.xhtml image_180 SIMON YOUNG AND WIFE.
OEBPS/3295685525714288644_69363-h-23.htm.xhtml image_198 THE MISSION HOUSE.
OEBPS/3295685525714288644_69363-h-23.htm.xhtml image_205 creek running down from hill
OEBPS/3295685525714288644_69363-h-24.htm.xhtml image_212 GROUP OF WOMEN AND CHILDREN.
OEBPS/3295685525714288644_69363-h-25.htm.xhtml image_222 GIRLS IN BATHING COSTUME.
OEBPS/3295685525714288644_69363-h-27.htm.xhtml image_236 HATTIE ANDRE’S CLASS.
OEBPS/3295685525714288644_69363-h-28.htm.xhtml image_250 ROSA YOUNG’S CLASS.
OEBPS/3295685525714288644_69363-h-28.htm.xhtml image_259 sailing ship out at sea

With the following images that were properly wrapped in a div skipped because of empty alt and no discernible description information. These results seem quite consistent with the hand generated loi provided in the book.

Warning: Image Skipped -  1189670316845751299_i_012.jpg
Warning: Image Skipped -  1189670316845751299_i_020.jpg
Warning: Image Skipped -  1189670316845751299_i_031.jpg
Warning: Image Skipped -  1189670316845751299_i_045.jpg
Warning: Image Skipped -  1189670316845751299_i_055.jpg
Warning: Image Skipped -  1189670316845751299_i_065.jpg
Warning: Image Skipped -  1189670316845751299_i_066.jpg
Warning: Image Skipped -  1189670316845751299_i_076.jpg
Warning: Image Skipped -  1189670316845751299_i_087.jpg
Warning: Image Skipped -  1189670316845751299_i_097.jpg
Warning: Image Skipped -  1189670316845751299_i_108.jpg
Warning: Image Skipped -  1189670316845751299_i_119.jpg
Warning: Image Skipped -  1189670316845751299_i_127.jpg
Warning: Image Skipped -  1189670316845751299_i_138.jpg
Warning: Image Skipped -  1189670316845751299_i_148.jpg
Warning: Image Skipped -  1189670316845751299_i_158.jpg
Warning: Image Skipped -  1189670316845751299_i_170.jpg
Warning: Image Skipped -  1189670316845751299_i_176.jpg
Warning: Image Skipped -  1189670316845751299_i_177.jpg
Warning: Image Skipped -  1189670316845751299_i_192.jpg
Warning: Image Skipped -  1189670316845751299_i_193.jpg
Warning: Image Skipped -  1189670316845751299_i_206.jpg
Warning: Image Skipped -  1189670316845751299_i_219.jpg
Warning: Image Skipped -  1189670316845751299_i_220.jpg
Warning: Image Skipped -  1189670316845751299_i_228.jpg
Warning: Image Skipped -  1189670316845751299_i_229.jpg
Warning: Image Skipped -  1189670316845751299_i_233.jpg
Warning: Image Skipped -  1189670316845751299_i_234.jpg
Warning: Image Skipped -  1189670316845751299_i_242.jpg

These were mainly chapter headers showing the artwork at the start of each chapter taken from the original book that are not referenced or used in the book itself (just presentation)

So it appears, we can make this plugin useful.

But I will need a bunch of test cases to help make things robust. If you know of public domain epubs with lists of illustrations (loi) pages in them please post a link here. Even 3 or 4 good ones should help.

I will work on adding support for svg image tags just in case svg wrappers are being used.