Adequacy of EPUB?

[RbnJrg]

Originally Posted by eschwartz

layouts in columns -- isn't that Fixed-Format? Totally different animal...

No, no. With epub3 you can have layout in columns in fluid format too.

footnotes in popup windows work in EPUB2 as well -- a renderer feature.

With epub3 you should have popup windows in any ereader that supports the protocol.

Oh, great, some new CSS3 styles, we were just dying to have those... might I ask which ones you felt were important?

Yes, of course. Please, read this thread:

https://www.mobileread.com/forums/sho...d.php?t=212300

Also css3 allows elements to be styled in various shapes (i.e think circle divs) and you can wrap your text around the edges of a curvy design. Please, read these articles:

http://www.sitepoint.com/css-shapes-...ngular-design/

http://sarasoueidan.com/blog/css-shapes/

Also you can have text-shadow, hollow text (text-stroke), text in perspective, text reflected, etc., etc.

Scripts are an abomination, and the only thing about EPUB3 that I believe must be immediately consigned to the flames, destroyed, annihilated, NUKED FROM ORBIT!!!!

With javascript you can change the layout of any epub ON THE FLY; things that are ok with some font-size, they can not be with a new size. Read this thread:

https://www.mobileread.com/forums/sho...d.php?t=265388

So I stand by my point, essentially, the only thing EPUB3 gives you (implies something you want) is audio, video, and MathML, and I didn't mention MathML, only because it answers a specific minority need (mathematical texts are a very small corner of the EPUB market).

Of course you have the right to sustain your opinion, but with css3 you can do a lot of things with less (much less) code. You can style chapter titles and to use layouts in a way not possible with css2.

Regards
Rubén

[Hitch]

Originally Posted by eschwartz

MathML -- good point.
layouts in columns -- isn't that Fixed-Format? Totally different animal...
footnotes in popup windows work in EPUB2 as well -- a renderer feature.
Oh, great, some new CSS3 styles, we were just dying to have those... might I ask which ones you felt were important?

Okay: I admit I wish I had MathML. But seriously, we can all MAKE this stuff,but we have ONE reader that can display it, for the love of heaven. Now, that's frustration.

And I wouldn't mind columns NOT in tables. That's a pipe dream, of course--or it will be egregiously complicated--outside of FXL.

Scripts are an abomination, and the only thing about EPUB3 that I believe must be immediately consigned to the flames, destroyed, annihilated, NUKED FROM ORBIT!!!!

Wow, is Jon contagious?

So I stand by my point, essentially, the only thing EPUB3 gives you (implies something you want) is audio, video, and MathML, and I didn't mention MathML, only because it answers a specific minority need (mathematical texts are a very small corner of the EPUB market).

Again, in fairness to MathML, it would be a larger part of the market, if we could use it. That's undeniable. I could pick up quite a lot of work, if I could wield that across the retailers. No argument. Of course, much like backlist fiction, it would be a temporary gold rush--and certainly not "low-hanging fruit," like the million+ original push with fiction was--but hey, a girl's gotta eat.

n.b.: I do get asked for "footnotes in pop-up windows," but as @e points out, that's the devices, not the coding. I give those who ask our standard gallery screenshots of our footnotes working in PPW and iBooks, and bobs-yer-uncle. And before somebody infers the wrong thing, NO, I absolutely tell them that it's device dependent.

Hitch

[Sarmat89]

Originally Posted by eschwartz

Create a custom column in calibre, and enter the names of translators and illustrators in their own fields.

End user should not do metadata hunt for himself. It should not rely on 3rd party utilities to keep his own databases. The book he gets from the store must be functionally complete by its own.

EPUB can still include private, namespaced metadata.

Custom metadata are useless if they are not standard. If DC was not adequate, the spec authors should have created the additional dictionaries.

(X)HTML/CSS already have a working system that they know how to use, which accomplishes what's needed.

A specific format allows to do that and more in a fraction of effort. Instead of designing and re-using stylesheets for every book... you can focus on design, not on stupid technicalities and 'layout tweaking'. It's a pure profit.

the people who would use automatic conversions anyway

Conversion is only the first step to the book. Than you can point to things, and say, 'it's a letter salutations', 'it's a chapter number', 'it is a footnote', instead of making up stylesheet classes for paragraphs. Much simpler, isn't it?

Well, you can certainly expect fonts, which is what Hitch was talking about.

AFAIK Kindle guidelines prohibit setting fonts for body text for customization and accessibility reasons. You don't need fancy fonts in E-book. Not all readers support embedded fonts. No one stop you from assigning font to "chapter>title label" in the exact same way you assign it to "p.chapter_no_2a". The difference is you don't know what you will get if you didn't do it in HTML; with a specific format, the user will have a nice, reasonable default from his reader+user stylesheets.

Might I add that man pages aren't even written in HTML? They're written in groff.

HTML was intended to eventually replace TROFF.

[RbnJrg]

Originally Posted by Hitch

n.b.: I do get asked for "footnotes in pop-up windows," but as @e points out, that's the devices, not the coding. I give those who ask our standard gallery screenshots of our footnotes working in PPW and iBooks, and bobs-yer-uncle. And before somebody infers the wrong thing, NO, I absolutely tell them that it's device dependent.

Hitch

Right now it's both Hitch; it's device dependent and apps dependent. For example, with Gitden Reader you can get pop-up windows for footnotes.

[RbnJrg]

Originally Posted by Toxaris

True, but there is also something I can do with ePUB2 which I cannot do with ePUB3.... Read it on a normal e-reader.

You are right; there are not many devices that are able to read epub3 ebooks. Hopefully this will change in the near future; so far you can read them (epub3 ebooks) in android apps (Gitden), in Readium, in Azardi and in ADE 4.x.

[Hitch]

Originally Posted by Sarmat89

End user should not do metadata hunt for himself. It should not rely on 3rd party utilities to keep his own databases. The book he gets from the store must be functionally complete by its own.
Custom metadata are useless if they are not standard. If DC was not adequate, the spec authors should have created the additional dictionaries.

Well, now we're simply at "is too, is not." It's absurd. You want 100 more types of metadata than I do, for my own books. Jane will want something else. That's the entire POINT of custom metadata. No one--no one--will ever anticipate every type of metadata that some gearhead wants. It's ridiculous. I know someone who actually categorizes her romances by what TYPE of romance it is. You think that XML will address that?

A specific format allows to do that and more in a fraction of effort. Instead of designing and re-using stylesheets for every book... you can focus on design, not on stupid technicalities and 'layout tweaking'. It's a pure profit.

(Sorry...the "pure profit" part left me gasping for air.)

Uh, no. Look, my friend: conversion is never going to be automated. How do I know this? I've tried. Everyone here, including my hero Tox, has tried to automate conversion. It does NOT MATTER whether you want to wrap <simpara> tags around a paragraph, or "p.norm" tags.

The conversion still has to be done with your hands and eyeballs, because--this seems to be the part that people who don't do this daily never understand--you will NEVER get the same file twice. NEVER. You'll get what I get: people who type like they're using a typewriter, hitting "enter" at the end of each LINE, not paragraph. You'll get people who use tabs. People who use "normal" for every element in the book. People who manually type all the superscripted footnote numbers, and manually position the corresponding note at the bottom of the page--for hundreds, if not thousands, of footnotes. Whether one uses XML or HTML for fixing those footnotes shan't make one iota's difference in what it takes to fix it.

Do you realize that what you're arguing is that typing ONE type of tag is faster and better than typing another? You're constantly conflating your desire for METADATA with the actual bookmaking process. It's the fatal flaw in your argument.

Speaking for those of us that DO do this everyday, none of us are sitting there writing custom CSS for *every* book. That's a daft idea on its face. I have House CSS, that we use for book after book. For both fiction and non-fiction, we have standarized stylesheets, from which we use the SAME CSS classes over and over. Why on earth do you think it makes two farts' worth of difference to the bookmaker whether she types <p>yadda</p> or <simpara>yadda</simpara>? Clue: it doesn't. In fact, I'd point out that XML, specifically book schema, has what, 101 child elements for a simpara, alone? Yeah, MUCH better.

You completely misunderstand how professionals make books, if you think that they get a source file and then sit around writing up custom CSS for each. That's daft. We may modify the appearance, for a given type of list; but the NAMING conventions--just like XML schema--stay the same.

More importantly, you're deliberately making it sound "easier" and "simpler," when it's SSDD. (Same Stuff, Different Day) to the bookmaker. It's of no mind whatsoever, if you have to look at a file (let's say, a Word file of a fiction ms, to make it easy) and decide whether it's a para, a simpara or a formalpara, (XML) versus looking at it and deciding that you're going to use a regular paragraph <p>, or some other type of paragraph <1after, 2after, first> that you have already created, long before, in a standardized CSS.

What idiot would NOT use a standarized CSS, even if it was an author who had 4 books to convert? Hell, back in 2009-10, it was the FIRST thing I did, once I realized I was going to be doing this for a while; I created a standardized CSS that I (still) use to this day, although obviously, it's been tweaked to keep up with changing devices and standards.

Conversion is only the first step to the book. Than you can point to things, and say, 'it's a letter salutations', 'it's a chapter number', 'it is a footnote', instead of making up stylesheet classes for paragraphs. Much simpler, isn't it?

Again, you keep surmising that every book made is the FIRST book ever made by that person, and that they're having to create CSS for the first time, ever. That's begging the question, to try to win the debate.

Either we're discussing commercial/repeat bookmakers, in which case the assumption is simply wrong, or we're discussing amateur, first-time bookmakers, in which case, surely you cannot disagree that learning all the ins-and-outs of XML Schema would be FAR harder for them, then the HTML-XHTML standards currently in place?

And if the bookmaker is COMPETENT, no, conversion isn't the first step; it's the entirety. If you mean, when you say "conversion," exporting the typed material to some other format, then, yes: "conversion" is the first step. But the real work is the formatting (aka conversion), and that is not made one iota simpler by using XML over XHTML or HTML. You're simply wrong.

AFAIK Kindle guidelines prohibit setting fonts for body text for customization and accessibility reasons. You don't need fancy fonts in E-book. Not all readers support embedded fonts. No one stop you from assigning font to "chapter>title label" in the exact same way you assign it to "p.chapter_no_2a".

That's right--two different ways--neither better than the other--for doing EXACTLY THE SAME THING. This is what we have all been saying, since the beginning of this discussion. It's not faster to do one over the other, and the result for the end reader is PRECISELY the same. You persist in trying to argue that XML is better for the BOOKS, which is a losing argument, when all you care about is categorization and searching on metadata and semantics. The XML/XHTML portion of this discussion is not winning the debate, because we all know that it's 6 of one, half-dozen of the other, for the bookmaker.

There's no longer a prohibition against using fonts (for Amazon/KDP). Has not been in some time. The only "rule" is, don't embed fonts that are already on the devices. My firm does a ton of WL (white label) work, and we embed fonts all week long.

The difference is you don't know what you will get if you didn't do it in HTML; with a specific format, the user will have a nice, reasonable default from his reader+user stylesheets.

Hunh? What do you mean? "You don't know what you will get if you didn't do it in HTML?" Of course you don't. How the hell else would you "embed" fonts? You're either working in HTML/HXTML, or some variant, because other mechanisms can't carry the entire font file. I literally don't understand your meaning.

HTML was intended to eventually replace TROFF.

Hmmm. As was (wait for it) DOCBOOK, way back when.

I think that you are still failing to make your case. You have yet to convince anyone here--and we're a pretty open-minded crew around here, if you overlook a person or two--that your idea of using XML will somehow improve bookmaking ITSELF. The whole semantics thing, frankly, seems to be YOUR hangup. You want to be able to categorize the books that you buy or make down to the gnat's ass. Fine, go ahead and do that. You can do it with Calibre, or by using the DC that's already available, IN the Spec. The fact that readers don't use it--that's not the ePUB Spec's issue.

I now want to know what books you've converted, and what tools you use to do the job, because honestly, from a bookmaker's standpoint, your argument doesn't hold water. I find it very hard to believe that you've made a lot of books, or that you're making them in code, because you'd know that the difference between one set of tags and another is moot. You wouldn't have made that argument.

You really need to stick to the argument that might hold water--that you WANT more metadata. Whether or not it's "better;" well, that's the argument you need to make. Not that YOU want it; but why it's better for the whole industry. The fact that you want it is nice, but hardly compelling. You need to make arguments that state facts, not opinions, if you want to sway other people's opinions. So far, you keep repeating what you're saying, that using XML or XML scheme is "better" without showing us, or demonstrating to us, WHY it's better. You claimed that there were plenty of XML readers, which there are not; you claimed that there are easily-available WYSIWYG XML editors, which there are not. You claimed that you are not talking about DocBook, but there's not one iota of difference between the old DocBook standards, and what you've said you want. (Don't believe me? Try this: http://www.docbook.org/tdg5/en/html/ch02.html ).

One last point: you keep ignoring the fact that DocBook WAS here. It came, and it went. It didn't stay. Assuming arguendo that your position is correct--that XML is "better," then why on earth didn't DocBook stick? Why did it fade into the sunset? Why isn't EVERYBODY using DocBook to make ebooks???? Answer THAT one, while you're at it.

So...we will all be here, no doubt, when you come back with your next assertions. Maybe.

[Hitch]

Originally Posted by RbnJrg

Right now it's both Hitch; it's device dependent and apps dependent. For example, with Gitden Reader you can get pop-up windows for footnotes.

Agreed. But 99.99% of my clients are using devices and intend to sell at retailers that sell to people with devices. I use

Originally Posted by RbnJrg

You are right; there are not many devices that are able to read epub3 ebooks. Hopefully this will change in the near future; so far you can read them (epub3 ebooks) in android apps (Gitden), in Readium, in Azardi and in ADE 4.x.

True, but ^. :-) I use Readium myself as a quick-n-dirty way to proof FXL ePUBs, for glaring errata, and tell clients to use it (oish) when they don't have an iPad, but want to proof their FXL ePUB books. It's a nice-enough reader.

Hitch

[eschwartz]

Originally Posted by RbnJrg

No, no. With epub3 you can have layout in columns in fluid format too.

That sounds suspiciously like a halfway house for fixed-format.

With epub3 you should have popup windows in any ereader that supports the protocol.

That still requires the ereader provides support for this, specifically. The most you can say is that now there is a meta tag to describe it, we might see more devices/apps implement it... but it's not like it used to be hard.

Once again -- popup footnotes are a feature of the renderer, not the format. If the renderer doesn't support popup footnotes, EPUB3 footnotes won't help. Especially for EPUB2. But if the renderer supports regular old link-based footnotes, they can do the same with EPUB2 as well.

There is no real functional gain IMHO.

Yes, of course. Please, read this thread:

https://www.mobileread.com/forums/sho...d.php?t=212300

Also css3 allows elements to be styled in various shapes (i.e think circle divs) and you can wrap your text around the edges of a curvy design. Please, read these articles:

http://www.sitepoint.com/css-shapes-...ngular-design/

http://sarasoueidan.com/blog/css-shapes/

Also you can have text-shadow, hollow text (text-stroke), text in perspective, text reflected, etc., etc.

Thanks.
I agree that does look pretty interesting.

With javascript you can change the layout of any epub ON THE FLY; things that are ok with some font-size, they can not be with a new size. Read this thread:

https://www.mobileread.com/forums/sho...d.php?t=265388

Now that I simply think is a bad idea.

Of course you have the right to sustain your opinion, but with css3 you can do a lot of things with less (much less) code. You can style chapter titles and to use layouts in a way not possible with css2.

Regards
Rubén

I don't really have anything against CSS3 per se, it's the idea of javascript in ebooks that gives me the willies.

[eschwartz]

Originally Posted by Hitch

Okay: I admit I wish I had MathML. But seriously, we can all MAKE this stuff,but we have ONE reader that can display it, for the love of heaven. Now, that's frustration.

And I wouldn't mind columns NOT in tables. That's a pipe dream, of course--or it will be egregiously complicated--outside of FXL.

So am I right (^^ x ^^) about two-column "not FXL" then?

Wow, is Jon contagious?

Well, I freely admit that my disapproval of javascript in ebooks is a personal opinion.

Jon does not have a monopoly on strongly-held opinions, even if he does control a disproportionate amount of the market.

Again, in fairness to MathML, it would be a larger part of the market, if we could use it. That's undeniable. I could pick up quite a lot of work, if I could wield that across the retailers. No argument. Of course, much like backlist fiction, it would be a temporary gold rush--and certainly not "low-hanging fruit," like the million+ original push with fiction was--but hey, a girl's gotta eat.

It would still be a small part of the market. But as you say, it would -- for a while -- become a very lucrative part of the market, due to the talent involved, the backlist of mathematical texts that could use it, and above all, the first-mover advantage.

Larger I will grant you.

[eschwartz]

Originally Posted by Sarmat89

End user should not do metadata hunt for himself. It should not rely on 3rd party utilities to keep his own databases. The book he gets from the store must be functionally complete by its own.
Custom metadata are useless if they are not standard. If DC was not adequate, the spec authors should have created the additional dictionaries.

So go complain to the Dublin Core committee, but what does that have to do with EPUB?

And you have no need to rely on calibre, you are free to edit the content.opf directly, or use Sigil, or calibre's Editor, or any other EPUB editor (should one exist).

HTML was intended to eventually replace TROFF.

Oh yeah?
As Hitch said, so was DocBook.

Anyway, groff can output HTML... amongst several other target formats. But I think using HTML as the original source is pretty rare. Usually people use Asciidoc, markdown, TeX, or DocBook (that again). Depending on whether they want to write it the easy way or the finely-controlled way.
(This becomes possible by having a very rigid standard and not deviating from it. But manpages are supposed to conform, not do interesting things...)

Well, anything under the umbrella of the GNU would much rather you read their own Texinfo documentation. But even they don't expect you to open up a browser first.

But first you say HTML was designed as a replacement for groff/troff, then you back down (?) and say it was merely intended to be used as a replacement.

Since groff/troff is still around and in use, going on 50 years later, I'd venture to say that there is something wrong with your conclusion, at the least.



Whether or not HTML once had any sort of informal or formal relationship to groff is irrelevant.
Because HTML has come a long way, and I certainly cannot fathom how you could argue NOW that it is "suitable only for writing man pages".

[RbnJrg]

Originally Posted by eschwartz

That still requires the ereader provides support for this, specifically. The most you can say is that now there is a meta tag to describe it, we might see more devices/apps implement it... but it's not like it used to be hard.

Once again -- popup footnotes are a feature of the renderer, not the format. If the renderer doesn't support popup footnotes, EPUB3 footnotes won't help. Especially for EPUB2. But if the renderer supports regular old link-based footnotes, they can do the same with EPUB2 as well.

There is no real functional gain IMHO.

You say well, there are tags for pop-up footnotes in epub3. I said it in another post, for example, with Gitden Reader (an android app to read epub3 ebooks) you can have pop-up windows for footnotes. So, pop-up windows not necessarily are device dependant.

Thanks.
I agree that does look pretty interesting.

Yes, those properties are very interesting. And you can't get it with epub2.

Now that I simply think is a bad idea.

Well, maybe in a couple of months you can think is not a very bad idea

I don't really have anything against CSS3 per se, it's the idea of javascript in ebooks that gives me the willies.

CSS3 is a good thing. You also can have hanging puntuaction and text-alignment (for example text-align-last) not available with epub2. I would bet that once you familiarize yourself with css3 you'll change many of your opinions

Regards
Rubén

[Jellby]

CSS3 is good, but it's not exclusive of ePub3. Any ePub2 reader can support CSS3 and still be ePub2 compliant, any ePub2 book can use CSS3 and still be ePub2 compliant. I'd guess any reader that can support ePub2 and ePub3, supports the same amount of CSS3 in both formats.

That is not the case for some other ePub3 "features": include a <video> tag and your book stops being ePub2 compliant, drop support for NCX and your reader stops being ePub2 compliant.

[HarryT]

Originally Posted by Solitaire1

I'm struck by how complex it seems to be to do something in EPUB that was so simple in another format. As an example, in the .pdb format indenting the first line of a paragraph and not putting a blank line between the paragraphs is so simple, yet in EPUB it seems like a major task.

Simply set your desired paragraph defaults in the CSS. Eg;

.p {
    text-indent: 1.5em;
    margin-top: 0;
    margin-bottom: 0
}

What's hard about that? It has the huge benefit over manually indenting each paragraph separately that, should you later decide that you want a different indentation of a different paragraph spacing, you only have to edit it in one place, and your whole book will change to match the settings. Immensely easier that formatting each paragraph individually.

Why do you find it to be a "major task"?

[Notjohn]

>You'll get what I get: people who type like they're using a typewriter, hitting "enter" at the end of each LINE, not paragraph.

I don't blame them for that. I still miss the DING! that the little bell would make when the carriage was five characters from the end of the line, as if Mr Remington and Mr Rand were cheering my creation of yet another line of glorious prose.

Hemingway by contrast thought of it as a battle:

But the mill
Chatters in mechanical staccato
Ugly short infantry of the mind
Advancing over difficult terrain
Making this Corona
Their mitrailleuse.

[kennyc]

Originally Posted by Sarmat89

EPUB seems to be the dominating format, but it is hardly adequate for the fiction.
It is based on HTML, which semantical elements are rudimentary and focused around computer manuals (tt, var, code, dd).
HTML mixes up logical and physical layout when creating the simplest fiction elements: letters, titlepages, poems, even chapter titles—they have to be imitated by CSS styles. If you take 5 EPUBs of similar structure, they will have 5 different ways to structure its elements.

Also EPUB cannot handle metadata: there is no support for genres, series, translations, artists...

Shouldn't the editors and publishers to embrace a new format which was designed with eBooks in mind?

Adequacy? Perfectly adequate.