There's a new sheriff in town …

[KevinH]

Yes, wpub/epub4 is just a "packaged web app" and is meant for serving ebooks from the web. It is nothing like an epub in any way. Sad really.

Do ebook publishers really want the "web app in a box"?

Looking back the IDPF made a huge mistake ignoring backwards compatibility when moving from epub2 to epub3, and then confusing b2b metadata needs of its members/the book industry with b2c consumer metadata needs.

It seems the Japanese book industry is a big user of refines in metadata even though they were a huge mistake and so now can not be removed in favour of more sane metadata in the opf.

[KevinH]

IMHO: Given what I have read, unless a sane 3.2 is released and largely adopted, and soon, the epub format as we know it does not have a bright future.

[Toxaris]

Originally Posted by KevinH

Do ebook publishers really want the "web app in a box"?

Yes, I think they do. That way they could enforce much more control and even more a subscription type of book instead of a downloadable book that you control.

[BetterRed]

Originally Posted by KevinH

Do ebook publishers really want the "web app in a box"?

Maybe it's a step towards Bookify - ebooks for free if you can accept targeted advertising at the bottom of every page, no ads if you pay a subscription.

BR

[jcsalomon]

Originally Posted by KevinH

Do ebook publishers really want the "web app in a box"?

Some do, sure. But the big draw (as I see it) isn’t in the bells-and-whistles that modern HTML+CSS+JS enables—I expect Amazon to keep saying, “we’ll support this and no more,” and everyone targeting that subset of features—but in the simplicity of specification: “Use standard web tech, package it in this simple manner, and you’re done,” or for e-readers, “Unpack this simple package format and use a standard browser widget.”

Originally Posted by KevinH

It seems the Japanese book industry is a big user of refines in metadata even though they were a huge mistake and so now can not be removed in favour of more sane metadata in the opf.

I can’t find where I’ve seen what the Japanese publishers are using refines for, but it is the only way currently offered to deal with hierarchically-organized metadata. Maybe a simple JSON-based format could afford them what they’re asking for?

[jcsalomon]

Also, “web app in a box” is coming anyway (PWPub); if it’s going to catch on (a big “if”), it might just be convenient to say, “a ‘web app in a box’, with certain features and restrictions, is an e-book”.

[KevinH]

Hi All,

Based on the discussion held here, I have created a beta level Access-Aide that is coming close to being feature complete with a rudimentary graphical user interface for updating image alt text attributes.

I could use your feedback.

See attached Access-Aide_v020.zip

It will:

- add primary language (first dc:language tag found) to the html tag using both lang and xml:lang attributes

- parse the nav for the title of the first link into an xhtml file and use this information to fill in the head title tag if empty

- will add empty alt attributes to all img tags (if none already exists) and later present a gui to allow you to see the image and then update the alt text.

- add the metadata to the opf needed for accessibility

- it will add epub:type semantics from nav landmarks to the appropriate body tags or ids

- map epub:type attributes to aria role attributes


Limitations:
- only work for Python 3.4 or later (the embedded python for Windows and macs)
- works only on epub3 for now, requires a nav
- will abort if epub has audio or video resources
- will abort if the epub uses mathml tags
- will abort if the epub uses javascript

The reason for that is the accessibility schema can not be properly added when mathml, javascript, audio, and video tags are present. Selecting the correct accessibility metadata would take human intervention.

This edit plugin is still quite rough but could use some testing and feedback of bugs and things that still need to be done.

It is hopefully useful in its current condition.

All feedback welcome.


Updated: Should now add missing title in a better manner including to the nav itself, and should now use epub:type semantic information from the nav landmarks section to add appropriate epub:type to body or to particular tags with id when missing

Updated: Now tries to build a tkinter GUI to allow you to more easily edit/fill in "alt" attributes on image tags to add better textual descriptions of images.

[Doitsu]

I've slapped together a Sigil ACE wrapper plugin that'll run ACE and display the report file in the default browser.

[KevinH]

I can probably create a python routine that will take an epubcfi and convert it to a file line or offset, if that would help.

[Doitsu]

Originally Posted by KevinH

I can probably create a python routine that will take an epubcfi and convert it to a file line or offset, if that would help.

That would be very helpful.

[elibrarian]

Originally Posted by KevinH

Based on the discussion held here, I have created an alpha level Access-Aide that is incomplete but could use your feedback.

All feedback welcome.

Hi -

I've tried the plugin at some of our older and newer editions, and on a correctly sectioned/epub:typed epub3 file it seems to work as advertised (and certainly much better than any regexes I had been able to concoct!), except for one little thing: It doesn't insert a title in the nav.xhtml, if that is missing.

I've also tried the plugin on an old epub2 (from 2002) converted by the epub3-itizer plugin, which didn't go well "out-of-the-box" (hadn't expected it, of course - no sectioning and all), but with a reasonable amount of work, massaging the old files' peculiarities and inserting sections, the Access-Aide plugin is a great help!



Regards,

Kim

[KevinH]

Unfortunately, I parse the nav to get the titles for all of the other xhtml docs. I suppose, I could translate "Table of Contents" or "Navigation" or something along those lines and then use the primary language to look up a good title and place that there.

Since epub:type tags can be used on the body and div tags and does not require a section tag, there might be a way to add epub:type chapter (and its role) if there way some way to determine if it is actually a chapter and not an index, or new volume or something else.

Which epub:type attributes do you use most frequently?

Do you always add section tags or instead put the epub:type attribute on the body and divs?

Can you point me at a few (public domain) epubs that show good examples of the proper use of epub:type semantics inside xhtml files?

Thanks,

KevinH

[JSWolf]

[elibrarian]

Originally Posted by KevinH

Unfortunately, I parse the nav to get the titles for all of the other xhtml docs. I suppose, I could translate "Table of Contents" or "Navigation" or something along those lines and then use the primary language to look up a good title and place that there.

I've come up with this python-regex during my experiments:

found = re.search(r'(?<=<h1>).*?(?=<\/h1>)',html)
if found is not None:
	html = re.sub(r'\<title>(.+?)\<\/title\>', r'<title>' + found.group(0) + '</title>', html)

It works for me, because I routinely cut up my books in one file per chapter, but if it could be run on the nav only, you could get round the language problem.

Originally Posted by KevinH

Since epub:type tags can be used on the body and div tags and does not require a section tag, there might be a way to add epub:type chapter (and its role) if there way some way to determine if it is actually a chapter and not an index, or new volume or something else.

Originally Posted by KevinH

Which epub:type attributes do you use most frequently?

Depends on the book, but since I only do fiction, it's more or less limited to part and chapter, cover, titlepage, noteref, footnote, endnote, toc (and sometimes foreword, dedication etc.)

Originally Posted by KevinH

Do you always add section tags or instead put the on the body and divs?

I usually put the "-matter'-tags in body and the rest in section. I don't think there's an established practise.

Originally Posted by KevinH

Can you point me at a few (public domain) epubs that show good examples of the proper use of epub:type semantics inside xhtml files?

I'll try to find some. But since "the authorities" - whoever that may be - haven't established any practise, I don't think I can find any files that are THE solution.

Regards,

Kim

[KevinH]

Okay, when I parse the nav to get titles for each file I can extract the navs h1 to get a workable title for the nav. I can also parse the nav landmarks and extract epub:type semantics for any file listed and use those to add epub:type and aria roles to the appropriate body tag of the correct file.

That should help. I’ll post a new alpha for testing hopefully some time this weekend.