rework chapter tite tags ?

stumped · 08-03-2023, 03:09 AM

thanks for all the help with rework chapter headers.

after much help,
i now have books with chapter1, chapter 2 etc added as headers and in toc , but all the newly chapterized chapters lack a matching title tag.

chapter title tags are used by kobo to generate page headers on the device,when i send book to reader as kepubs, so Id like to fix them.

are there tools or is there a plugin to help, or is it a hard regex challenge?

to regex it- best way I can think of is
1) remove all existing title tags, using a find - replace all.
2. use regex to capture everything from the closing </head> tag thru to the new chapter headers, then manipulate that to slot in a new, populated chapter title tag just in front of the /head closure

{ i am guessing that multiple title tags in same file are bad, and that a single title tag can be anywhere in the <head> section }

i would then have to repair the damage done to title tags elsewhere in the books - maps, glossaries, title pages etc, if the step 1 replace all has wiped them out.

fools rush in, so I will wait a while for suggestions before starting that.

Karellen · 08-03-2023, 03:38 AM

Quote:

Originally Posted by stumped

but all the newly chapterized chapters lack a matching title tag.

Do you mean the title tag in the heading tag eg...
<h2 title="Chapter 1">1</h2>

Or do you mean the title tag in the <head> eg...
<head>

</head>

Turtle91 · 08-03-2023, 08:57 AM

I think he is referring to the title in the head. If so, then there is another plugin (Access-Aide Accessibility Helper) that will automatically add the title based on the (first?) header tag <h1-6>. Sorry I am not as familiar with that plugin.

DNSB · 08-03-2023, 12:20 PM

Are the current title elements not present, present but empty ( <title></title> ) or present but with the wrong content ( <title>Book_Title</title> ). The first two should be triggering an error using epubcheck.

Karellen · 08-03-2023, 04:43 PM

Quote:

Originally Posted by DNSB

<title>Book_Title</title> ). The first two should be triggering an error using epubcheck.

Really? It doesn't for me when using <title>Book_Title</title>.

DNSB · 08-03-2023, 06:23 PM

Quote:

Originally Posted by DNSB

Are the current title elements not present, present but empty ( <title></title> ) or present but with the wrong content ( <title>Book_Title</title> ). The first two should be triggering an error using epubcheck.

Quote:

Originally Posted by Karellen

Really? It doesn't for me when using <title>Book_Title</title>.

That part you quoted is the third condition. The first was not having the title element present, the second was having an empty title element, the third was the wrong content.

Code:

<head>
                     <== no title element
</head>

Code:

<head>
  <title></title> <== empty title element
</head>

Code:

<head>
  <title>Book_Title</title> <== incorrect title element
</head>

Karellen · 08-03-2023, 06:45 PM

Got it, Thanks.

Karellen · 08-03-2023, 06:49 PM

What should be in there?
In the early days I read somewhere it should be the book title. But now your comments sounds like it shouldn't be.

Turtle91 · 08-03-2023, 07:06 PM

From what I understand, ePub only requires that there BE a <title></title> in the document head… it can be empty. However, accessibility standards require an accurate descriptor of the document. I was a little surprised that ePubcheck would throw an error for an empty title?!?!

I used to just have the book title on all documents/chapters, but now I put the chapter title if it has one, or just "Chapter x" if it doesn’t. Id definitely check the accessibility standards though… I’ve made a mistake, or two, in my life.

Karellen · 08-03-2023, 08:08 PM

Unfortunately, I don't have the supporting knowledge to understand most of what is being said in this article, but looking at the example, it is a title for that particular xhtml document, not the document (ebook) in total, which is probably where I misunderstood during the learning curve.

https://html.spec.whatwg.org/multipa...-title-element

theducks · 08-03-2023, 09:03 PM

Quote:

Originally Posted by Karellen

Unfortunately, I don't have the supporting knowledge to understand most of what is being said in this article, but looking at the example, it is a title for that particular xhtml document, not the document (ebook) in total, which is probably where I misunderstood during the learning curve.

https://html.spec.whatwg.org/multipa...-title-element

We are doing EPUB, which is a subset of HTML, so not all 'required' applies.

EPUB3 added requirements,
but why make an EPUB3 if you only need EPUB2 features?

KevinH · 08-04-2023, 09:56 AM

To note ... it is Accessibility that wants those titles filled in properly (alongside img alt, and semantic tags).

IMHO, both epub2 and epub3 devs should strive to make an epub as Accessible as possible. Adding those titles automatically from either ncx or nav entries for that file or even from local header tags for that file is trivial work for a plugin to do. The AccessAide plugin will help you do that as well as make it easier to fill in img alt tags with something more meaningful, add semantics where needed, etc.

If just a title updater plugin is needed, I could throw something together to do just that but there are other things that should be added to make an epub more Accessible.

As for why epub3 vs epub2, it is to help provide better Accessibility (smil, more semantics, etc) and to future proof the epub even when it does not need specific epub3 only features.

My 2 cents ...

DiapDealer · 08-04-2023, 01:22 PM

I think it's a mistake to think of EPUB2 vs EPUB3 in terms of "features" needed. EPUB3 is the latest standard. As such, it should be used primarily--regardless of whether a project could be done with EPUB2 in my opinion. The fact the EPUB3 provides more in the way of accessibility is just icing on the cake.

If decisions were made based merely on what was needed to read a text-only ebook, we'd be preparing/distributing Word documents.

Tex2002ans · 08-04-2023, 08:22 PM

Quote:

Originally Posted by Turtle91

I think he is referring to the title in the head. If so, then there is another plugin (Access-Aide Accessibility Helper) that will automatically add the title based on the (first?) header tag <h1-6>.

Yep, that's probably the best/fastest way to mass add <title>s to your ebooks now.

One of the functions can look for the first heading, then auto-insert that text into the <title> for you.

WAY WAY easier/faster than it used to be.

Quote:

Originally Posted by Karellen

What should be in there?
In the early days I read somewhere it should be the book title. But now your comments sounds like it shouldn't be.

We covered <title> in ebooks (and web pages) multiple times over the years.

It can be blank:

Code:

<title></title>

it should NEVER have this bogus auto-generated junk:

Code:

<title>converted_file1.xhtml</title>

and, ultimately, it would have useful, human-readable information:

Code:

<title>Chapter 1: The Beginning</title>

[...]

<title>“The Ultimate Poem” by Tex</title>

For more information on what good <title>s should say + strategies for naming <title>s + where they might appear, see:

WebAIM: "Page Titles"

for more info about <title> in ebooks, see my discussion in:

2018: "Two questions"
- I covered <title> + HTML lang.

and all those relevant pages/links I linked to for more technical details.

- - -

Side Note: I wasn't aware any ereaders that actually displayed the <title> stuff yet, but it's good to see it might finally be rolling out + changing since 2016/2018ish.

(I always included it as best practices... because many users, like those using Screen Readers [or reading ebooks in their browsers], could see this info in the tabs or could have it read out loud... just like if they were reading a page on a website!)

Side Note #2: So many tools, like InDesign, automatically insert filenames inside the <title>. This is horrible, and WORSE THAN NOTHING/BLANK.

Just like shoving filenames inside of alt tags is an atrocious idea:

Code:

<img alt="Image01.jpg" src="../Images/Image01.jpg"/>

better to have alt be completely blank:

Code:

<img alt="" src="../Images/Image01.jpg"/>

or, the best—and what you should aim for—is to have useful alt + human-readable filenames!

Code:

<img alt="The Mona Lisa (1503) by Leonardo da Vinci" src="../Images/Mona.Lisa.jpg"/>

For more info, see:

2022: "Remove blank pages"
- One of the examples I gave was showing the user's original alt tags (just listing the filename) vs. a better description.
2016: "Accessibility question: TTS and ligatures"
- I linked to WCAG's alt recommendations.
2021: "pageList... again? Surely not!"
- I linked to DAISY's fantastic 3-part webinar on alt-text: "The Art and Science of Describing Images"
2021: "Automation of scanning on phone or tablet"
- Towards the bottom of the post, I linked to the fantastic DAISY video: "Describing Images in Publications – Guidance, Best Practices and the Promise of Technology" + many more resources.

Many of those best practices + similar reasons for alt tags applies to <title>s too.

It's not anything you can see with your own eyes, on the surface, but once you begin interacting with ebooks in different ways (like Text-to-Speech), this "hidden layer" becomes much more important.

08-03-2023, 03:09 AM	#1
stumped Wizard Posts: 3,305 Karma: 10259306 Join Date: May 2016 Device: kobo forma, Kobo Libra, Huawei media Tab, fire HD10, PW3 HDX8.9,	rework chapter tite tags ? thanks for all the help with rework chapter headers. after much help, i now have books with chapter1, chapter 2 etc added as headers and in toc , but all the newly chapterized chapters lack a matching title tag. chapter title tags are used by kobo to generate page headers on the device,when i send book to reader as kepubs, so Id like to fix them. are there tools or is there a plugin to help, or is it a hard regex challenge? to regex it- best way I can think of is 1) remove all existing title tags, using a find - replace all. 2. use regex to capture everything from the closing </head> tag thru to the new chapter headers, then manipulate that to slot in a new, populated chapter title tag just in front of the /head closure { i am guessing that multiple title tags in same file are bad, and that a single title tag can be anywhere in the <head> section } i would then have to repair the damage done to title tags elsewhere in the books - maps, glossaries, title pages etc, if the step 1 replace all has wiped them out. fools rush in, so I will wait a while for suggestions before starting that.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Composite Two questions: Column for Certain Tags & Chapter Numbers	chicleeblair	Library Management	2	07-05-2023 05:09 PM
Chapter & Text file counts and Chapter splits	BetterRed	Library Management	0	04-06-2021 06:25 PM
Does “7 min left in chapter” learn how fast you read? Or based on the chapter itself?	kindledude20	Amazon Kindle	4	08-02-2020 08:12 PM
Love the rework on saved searches!!!	JoeBloe	Editor	5	10-02-2014 02:38 AM
Amazon Tags - Popular tags vs Unique tags.	chrisanthropic	Writers' Corner	6	09-19-2011 11:18 PM

08-03-2023, 08:57 AM	#3
Turtle91 A Hairy Wizard Posts: 3,117 Karma: 18727091 Join Date: Dec 2012 Location: Charleston, SC today Device: iPhone 11/X/6/iPad 1,2,Air & Air Pro/Surface Pro/Kindle PW & Fire	I think he is referring to the title in the head. If so, then there is another plugin (Access-Aide Accessibility Helper) that will automatically add the title based on the (first?) header tag <h1-6>. Sorry I am not as familiar with that plugin.

08-03-2023, 12:20 PM	#4
DNSB Bibliophagist Posts: 36,393 Karma: 145735554 Join Date: Jul 2010 Location: Vancouver Device: Kobo Sage, Libra Colour, Lenovo M8 FHD, Paperwhite 4, Tolino epos	Are the current title elements not present, present but empty ( <title></title> ) or present but with the wrong content ( <title>Book_Title</title> ). The first two should be triggering an error using epubcheck.

08-03-2023, 06:45 PM	#7
Karellen Wizard Posts: 1,156 Karma: 4917718 Join Date: Sep 2021 Location: Australia Device: Kobo Libra 2	Got it, Thanks.

08-03-2023, 06:49 PM	#8
Karellen Wizard Posts: 1,156 Karma: 4917718 Join Date: Sep 2021 Location: Australia Device: Kobo Libra 2	What should be in there? In the early days I read somewhere it should be the book title. But now your comments sounds like it shouldn't be.

08-03-2023, 07:06 PM	#9
Turtle91 A Hairy Wizard Posts: 3,117 Karma: 18727091 Join Date: Dec 2012 Location: Charleston, SC today Device: iPhone 11/X/6/iPad 1,2,Air & Air Pro/Surface Pro/Kindle PW & Fire	From what I understand, ePub only requires that there BE a <title></title> in the document head… it can be empty. However, accessibility standards require an accurate descriptor of the document. I was a little surprised that ePubcheck would throw an error for an empty title?!?! I used to just have the book title on all documents/chapters, but now I put the chapter title if it has one, or just "Chapter x" if it doesn’t. Id definitely check the accessibility standards though… I’ve made a mistake, or two, in my life.

08-03-2023, 08:08 PM	#10
Karellen Wizard Posts: 1,156 Karma: 4917718 Join Date: Sep 2021 Location: Australia Device: Kobo Libra 2	Unfortunately, I don't have the supporting knowledge to understand most of what is being said in this article, but looking at the example, it is a title for that particular xhtml document, not the document (ebook) in total, which is probably where I misunderstood during the learning curve. https://html.spec.whatwg.org/multipa...-title-element

08-04-2023, 09:56 AM	#12
KevinH Sigil Developer Posts: 7,714 Karma: 5444398 Join Date: Nov 2009 Device: many	To note ... it is Accessibility that wants those titles filled in properly (alongside img alt, and semantic tags). IMHO, both epub2 and epub3 devs should strive to make an epub as Accessible as possible. Adding those titles automatically from either ncx or nav entries for that file or even from local header tags for that file is trivial work for a plugin to do. The AccessAide plugin will help you do that as well as make it easier to fill in img alt tags with something more meaningful, add semantics where needed, etc. If just a title updater plugin is needed, I could throw something together to do just that but there are other things that should be added to make an epub more Accessible. As for why epub3 vs epub2, it is to help provide better Accessibility (smil, more semantics, etc) and to future proof the epub even when it does not need specific epub3 only features. My 2 cents ...

08-04-2023, 01:22 PM	#13
DiapDealer Grand Sorcerer Posts: 27,588 Karma: 193191846 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	I think it's a mistake to think of EPUB2 vs EPUB3 in terms of "features" needed. EPUB3 is the latest standard. As such, it should be used primarily--regardless of whether a project could be done with EPUB2 in my opinion. The fact the EPUB3 provides more in the way of accessibility is just icing on the cake. If decisions were made based merely on what was needed to read a text-only ebook, we'd be preparing/distributing Word documents.

Advert

Advert