Quote:
Originally Posted by slowsmile
@Mister L...Here's the latest plugin. I think the new plugin is close to what you want now. Anyway, we'll see.
|
I tried it out but it doesn't seem to make any changes to the file. I used the same file as previously, generated an html toc with h1 "Table of Contents", then ran the new plugin; it changed the indents of the code in the html files but no new text was added. I tried running it with no html toc as well, just the ncx, but same result. Do I need to do anything particular to the file before running it?
Quote:
Originally Posted by slowsmile
By the way, "kludge" refers to unnecessary dross code. When you use spans with classes to achieve titlecase or smallcaps for headings it makes it awkward and more difficult for the plugin code to actually find the html heading names because the heading name characters are all split up and insulted with multiple span styling. Why they don't just type in the heading the way they want to see it in their original doc(without using spans) just boggles the mind. How easy is that? That's span "kludge". For my own ebooks I never use span styling in my html headings which are always styled as a standard either as allcaps(typed in) or as proper titlecase(typed in) and that's it. See below.
|
Right, I see, thanks. I don't remember seeing that word before so I wasn't sure what it meant, too lazy to google it this week-end.
I am a code purist, like you seem to be, so I avoid extra spans and styles as much as possible, don't put the chapter number and title in 2 separate tags... The fake small-caps code drives me crazy but there are a couple of clients who use it in their house styles (which were set up before I started making their books, and since I'm not the only person who works for them it's not easy getting changes made all through the workflow). They have small-caps on the titles in the chapters, but they want the toc to show the titles in lower case (also part of their house styles). Nobody else who works for them ever puts the "toc display" title text in the files so whenever they give me an old file to modify, fixing the toc alone sometimes takes more time than whatever specific task I'm meant to be doing (thus the request for this plugin). I have no idea how the person who originally made the file manages it; do they hand-code the entire toc, every single time they work on a file?? These are epub2 books, if you modify the order of the files or add one or split or merge anything you have to renumber every single navpoint PLUS any modifications to the text... What a colossal waste of time.
Quote:
Originally Posted by Hitch
That sort of code is used for the obvious reasons. If you "only" use smallcaps, then the text won't look right on older devices. You have to reverse-engineer the font sizes (small), (etc), so that it looks okay on KF7 and other devices. That's the simple eplanation.
Hitch
|
That's more or less the situation I am dealing with; those clients want epub2 files so advanced formatting is limited. But I dislike those sort of "kludge" for many reasons, not only because it makes dealing with the file more complicated but also from a usability standpoint it is not great as it can break the search function for instance. I'm trying to make gentle changes with them little by little but it's one of those "small cog big machine" situations.
When I have more liberty to decide though, for the majority of my clients, I make only fully backwards-compatible epub3 files and make typographical smallcaps using font-variant: smallcaps. I put the text either in allcaps (acronyms, roman numerals, etc.) or title case, depending on the situation. Very few of my clients object. One of them requests fake smallcaps on roman numerals / acronyms so they will be sure of the result everywhere, but those are outliers and as that still requires a span on the full word it doesn't really make much difference.
The way I see it, smallcaps are a purely esthetic choice; they look pretty but if the text is displayed in title case on older software, no meaning is lost and it's not hugely less beautiful to read. And it makes cleaner code that is fully searchable (and does not cause trouble when generating the toc
although anyway when I make a book, I add the title="" attribute from the start wherever necessary so I never have these problems on my own books).
Also, it's really frustrating to me that the reading software developped by companies who easily have the ressources to improve it if they wanted to is still so primitive after all these years, and the way I see it, if we keep limiting ourselves to what is
currently supported by all (or at least the majority) of reading sw, the sw devs have no reason to improve, because "there's no demand". Whereas if it's possible to point to X number of ebooks with typographical smallcaps and dropcap initials made with "first-letter" (etc.) and say "these books are not displaying as intended on your software", then at least there is a concrete argument in favour of improving, at least on all the new machines; as it's absolutely possible to make epub3 books which are completely compatible with epub2 rs (they won't have smallcaps or dropcap initials but they'll still be absolutely readable and look good), nobody loses.