Adequacy of EPUB?

[eschwartz]

Originally Posted by Sarmat89

Why should we use a DocBook when we make books, not computer documentation?

Because once you stop getting all hung up over what was the motivating factor behind the invention of DocBook, you will discover that it meets all of your defined specifications.

[DaleDe]

There are plenty of XML documents around, by the way. XHTML is of course an XML document as well but here is docx which is a zipped XML document as well. This is from our wiki.

A document containing: 'This word is bold.' would look like:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<w:document xmlns:ve="http://schemas.openxmlformats.org/markup-compatibility/2006"
    xmlns:o="urn:schemas-microsoft-com:office:office"
    xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships"
    xmlns:m="http://schemas.openxmlformats.org/officeDocument/2006/math"
    xmlns:v="urn:schemas-microsoft-com:vml"
    xmlns:wp="http://schemas.openxmlformats.org/drawingml/2006/wordprocessingDrawing"
    xmlns:w10="urn:schemas-microsoft-com:office:word"
    xmlns:w="http://schemas.openxmlformats.org/wordprocessingml/2006/main"
    xmlns:wne="http://schemas.microsoft.com/office/word/2006/wordml">
<w:body>
  <w:pw:rsidR="00F25A57" w:rsidRDefault="00F25A57">
    <w:r><w:t xml:space="preserve">This </w:t></w:r>
    <w:rw:rsidRPr="00FE579B">
      <w:rPr><w:b/><w:bCs/></w:rPr>
      <w:t>word</w:t>
    </w:r>
    <w:r><w:t xml:space="preserve"> is bold.</w:t></w:r>
  </w:p>
  <w:sectPr w:rsidR="00F25A57" w:rsidSect="00F25A57">
    <w:pgSz w:w="12240" w:h="15840"/>
    <w:pgMar w:top="1440" w:right="1800" w:bottom="1440" w:left="1800" w:header="720" w:footer="720" w:gutter="0"/>
    <w:cols w:space="720"/>
    <w:docGrid w:linePitch="360"/>
  </w:sectPr>
</w:body>
</w:document>

Dale

[Hitch]

Originally Posted by DaleDe

There are plenty of XML documents around, by the way. XHTML is of course an XML document as well but here is docx which is a zipped XML document as well. This is from our wiki.

A document containing: 'This word is bold.' would look like:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<w:document xmlns:ve="http://schemas.openxmlformats.org/markup-compatibility/2006"
    xmlns:o="urn:schemas-microsoft-com:office:office"
    xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships"
    xmlns:m="http://schemas.openxmlformats.org/officeDocument/2006/math"
    xmlns:v="urn:schemas-microsoft-com:vml"
    xmlns:wp="http://schemas.openxmlformats.org/drawingml/2006/wordprocessingDrawing"
    xmlns:w10="urn:schemas-microsoft-com:office:word"
    xmlns:w="http://schemas.openxmlformats.org/wordprocessingml/2006/main"
    xmlns:wne="http://schemas.microsoft.com/office/word/2006/wordml">
<w:body>
  <w:pw:rsidR="00F25A57" w:rsidRDefault="00F25A57">
    <w:r><w:t xml:space="preserve">This </w:t></w:r>
    <w:rw:rsidRPr="00FE579B">
      <w:rPr><w:b/><w:bCs/></w:rPr>
      <w:t>word</w:t>
    </w:r>
    <w:r><w:t xml:space="preserve"> is bold.</w:t></w:r>
  </w:p>
  <w:sectPr w:rsidR="00F25A57" w:rsidSect="00F25A57">
    <w:pgSz w:w="12240" w:h="15840"/>
    <w:pgMar w:top="1440" w:right="1800" w:bottom="1440" w:left="1800" w:header="720" w:footer="720" w:gutter="0"/>
    <w:cols w:space="720"/>
    <w:docGrid w:linePitch="360"/>
  </w:sectPr>
</w:body>
</w:document>

Dale

I use XML/Schema on my website. I'm not blowing smoke when I note that it's simply not as easy to use as HTML.

And I'd further note, that while the OP seems to be convinced that it would all be one big happy SCHEMA, my experience with SCHEMA is--it never is. Just as Apple screwed with what would, and wouldn't, work in their ePUB reader, iBooks, I've yet to see One Schema to Rule Them All. Google, for example, now has its own criteria for what markup/schema IT will accept for websites, versus what SCHEMA.org has for the SAME bloody elements.

There simply isn't an easy answer to this. And as I said previously: it's never going to happen, for the reasons I mentioned in detail.

Hitch

[RbnJrg]

Originally Posted by Sarmat89

On the other hand, can you create a mirrored text for every reader out there? If you cannot create an effect, you should use images or PDF.

You can have text mirrored for ereaders that support the property "box-reflect". This is a css3 property so you need an epub3 reader (that is, Gitden, Readium, Azardi, ADE 4.x). Also you should be able to read text reflected on Kindle (devices that support .kf8) and iPad (I'm not sure about Kobo). For example with this code:

1. In the .css file:

.reflect2 {
    font-size:2.5em;
    -webkit-box-reflect: below 0px -webkit-gradient(linear, left top, left bottom,  from(transparent), color-stop(25%, transparent), to(#FFFFFF));
    box-reflect: below 0px -webkit-gradient(linear, left top, left bottom,  from(transparent), color-stop(25%, transparent), to(#FFFFFF));
}

2. In the .xhtml file:

<h2 class="reflect2">Reflected Text</h2>

you'll have results as the following screenshoot of Sigil:



In ereaders that don't support css3, you can use SVG images to have text reflected. Of course, CoolReader is a bad epub lector, so you'll need a decent program.

If you want to know a bit more about reflections, read this page:

http://designshack.net/articles/css/...ons-in-webkit/

[Hitch]

Originally Posted by Sarmat89

You already have to tag 'every bloody element in a book' to make it stand out from body text. You do the same operations to assign your personal made-up style, as the predefined semantic style. This argument is rather absurd.

From reading this, I now know that you have no idea what you're talking about. You've obviously never used SCHEMA or XML to make a book, or you'd know that what I've said is correct, and your blithe dismissal is absolutely wrong. If you'd used something like DocBook, to make a book, you'd have a better understanding of this argument. Are there different paragraph classes in HTML, in an eBook? Sure. But the structure is completely different.

In XHTML, structurally, you care about Book-->Sections (if they exist)-->Headings-->Structure if any below headings, eg divs-->Paragraphs-->Spans/words/letters. That's it. In XML, the structure is everything. It has to be, by definition, very rigid, to do what you want it to. (Although, ironically, XML was supposed to be somewhat fluid by design.) You have the ability, in XHTML, to use a given class of paragraph style to suit multiple situations; you don't do that in XML.

Just ONE example; a reference page, let's say. See this for a simple example--this is just a reference page, mind you: http://www.docbook.org/tdg5/en/html/...ex-samprefpage

There is NOTHING simple about using XML to format books for epublishing, particularly as they become more complex. One of the posters here mentioned that he writes his books in DocBook--but he's a programmer. Why don't you ask him what he thinks about making it an industry standard, not merely for people who understand code, but for the million-plus authors out there, who can't even manage Word?

Why should we use a DocBook when we make books, not computer documentation?

If you don't realize that DocBook is exactly what you're talking about, you're even less well-informed than already realized. Why are you persisting in thinking that the wheel has to be reinvented? DocBook is right there, ready for you to make yourself happy.

Originally Posted by eschwartz

Because once you stop getting all hung up over what was the motivating factor behind the invention of DocBook, you will discover that it meets all of your defined specifications.

Exactly.

Hitch

[Sarmat89]

Originally Posted by Hitch

In XHTML, structurally, you care about Book-->Sections (if they exist)-->Headings-->Structure if any below headings, eg divs-->Paragraphs-->Spans/words/letters. That's it. In XML, the structure is everything. It has to be, by definition, very rigid, to do what you want it to. (Although, ironically, XML was supposed to be somewhat fluid by design.) You have the ability, in XHTML, to use a given class of paragraph style to suit multiple situations; you don't do that in XML.

It doesn't even make sense. XHTML must be a well-formed XML and have some kind of structure. It is no any different from a pure XML format.

<div class="letter">
<p class="lett1">Hello friend!</p>
<p>Blah</p>
</div>

and

<letter>
<salutation>Hello friend!</salutation>
<p>Blah</p>
</letter>

What is the difference? Those are both XML yet you claim the former is fundamentally more simple than latter.

[dgatwood]

Originally Posted by Sarmat89

It doesn't even make sense. XHTML must be a well-formed XML and have some kind of structure. It is no any different from a pure XML format.

I assume by "XML", Hitch meant "semantic markup". XML is just a specific set of rules for markup, where all of the tags must be balanced, the attributes have to be properly quoted, etc. It says nothing about the tags themselves.

XHTML is presentational markup (like HTML), and it just happens to be in XML format.

Most of the time, though, when we talk about XML, we're talking about good XML—semantic markup. That means that the tags themselves are meaningful.

HTML is partially semantic. Paragraph tags, though abbreviated, have meaning. A paragraph is a structural unit of content. Emphasis tags are another example. However, HTML and XHTML are more typically used presentationally, with tags like b (bold), font, hr (horizontal rule), etc., which define the appearance of the content rather than the structure of it.

To give you an example, here's the semantic markup for the first bit of the first chapter of "A Patriots Christmas" (a short story that is part of my Patriots book series):

<chapter>
<title>About eleven years after the events in Beyond the Veil</title>
<subtitle>(Dec. 24, 2401)</subtitle>
<para>’Twas the night before Christmas, and all through the house, Amanda was cleaning egg nog from her blouse, when what to her wondering eyes should appear, but Jen and Marc and their daughter so dear.</para>
<para>As Joseph ran to the door to see what was the matter, Amanda shouted down at him. *“Don’t forget that Jen and Marc are coming over tonight, so be on your best behavior.”</para>
<para>Joseph smirked at the lack of poetry, then threw open the door like a flash, just for good measure.</para>
<para>“Marc, Jen! *It’s so good to see you both!” he said. *“And who is this dashing young lady?”</para>

...

</chapter>

Other chapters have a series of para tags followed by one or more <section> tags that each wrap a bunch more <para> tags.

When I translate the markup from semantic markup (DocBook, in this case) to presentational markup (XHTML, in this case), the <chapter> tag effectively becomes a new file containing all of this:

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:svg="http://www.w3.org/2000/svg" xmlns:epub="http://www.idpf.org/2007/ops">
<head>
<title>Chapter I: About eleven years after the events in Beyond the Veil</title>
<link rel="stylesheet" type="text/css" href="nookstyles.css" />
<link rel="stylesheet" type="text/css" href="nookstyles2.css" />
</head>
<body>
<div class="chapter">
<div class="chapterheadbox"><div class="chapterheading">Chapter</div><div class="chapternumber">One</div>
</div><div class="title">About eleven years after the events in Beyond the Veil</div>

<div class="subtitle">(Dec. 24, 2401)</div>
<p>...</p>
...
</div>
</body>
</html>

and when there are section tags, you get

<div class="section">
...
</div>

wrapped around them, but if there are two sections back-to-back, you also get

<div class="sectionmark"><span>***</span></div>

between them. Notice that this mark div has absolutely no purpose other than presentation. (Of course, were it not for bugs in some ePUB readers, I'd be using CSS instead, but that's another matter.)

Also notice that the chapter tag exploded into the word chapter followed by a chapter number (written out), each in its own container, each styled separately, none of which was present in the original content.

What makes semantic markup useful is that software can examine it and reason about it programmatically. If a piece of software sees a bunch of random div elements, it has no way to know that a sectionmark div appears between sections. But if it sees a section tag, it knows that those are sections. And, for more complicated works such as programming documentation, it knows the difference between a section that's at the top level of a chapter and a section that's inside another section. If, for example, that software converts it to presentational markup, it might make each nesting level be indented further than the last.

The chapter number is a great example of this. When I started writing the content, I was dealing with manual chapter numbers, and it was a nightmare to keep fixing them every time I added a new chapter break. By changing the markup to simply treat each chapter as a unit, that becomes trivial. When the software produces the actual output, it just counts the chapters as it goes, and puts in the correct number.

And in nonfiction books, semantic markup can be even more meaningful. For example, when writing developer documentation, we would put certain bits of text in code font (monospace). Had we used presentational markup, these would be indistinguishable. However, if people mark them up correctly, you can tell whether that bit of text is a function (which should ideally be auto-linked to the function's documentation), a constant (same), the name of a command-line tool (which should be linked to a very different kind of documentation), etc.

None of those differences matter to the end reader. However, they can be important to tools that operate on the content, and they can provide you (as the CSS creator) with the ability to change formatting later on. For example, if you later decide that you want to change your house style so that all the function names end with (), you can add a tiny bit of CSS (using the ::after pseudo-element and the content property), and now every one of those function names now ends with (), but the constants (that were formatted in the same way) no longer are.

It is basically just like what you do in XHTML with div tags and classes, except that the tag names are standardized, which means that there are tools out there that can work with the content across organizational boundaries, confident that a paragraph really is a paragraph and a function name really is a function name.

[Hitch]

Dag:

Yes, I meant XML as semantic markup, as in Docbook.

Hitch

[Toxaris]

Originally Posted by Sarmat89

It doesn't even make sense. XHTML must be a well-formed XML and have some kind of structure. It is no any different from a pure XML format.

<div class="letter">
<p class="lett1">Hello friend!</p>
<p>Blah</p>
</div>

and

<letter>
<salutation>Hello friend!</salutation>
<p>Blah</p>
</letter>

What is the difference? Those are both XML yet you claim the former is fundamentally more simple than latter.

Wrong, in XHTML most sane ePUB creators would use something like:

<p class="letter">Hello friend!</p>
<p class="letter">Blah</p>

A lot easier and it also contains your precious semantics. It is still clearly defined as a letter. Styling is of course done in the stylesheet. No different than your XML example which also do not contain styling.

[Solitaire1]

dgatwood wrote the following as part of a post:

Originally Posted by dgatwood

The chapter number is a great example of this. When I started writing the content, I was dealing with manual chapter numbers, and it was a nightmare to keep fixing them every time I added a new chapter break. By changing the markup to simply treat each chapter as a unit, that becomes trivial. When the software produces the actual output, it just counts the chapters as it goes, and puts in the correct number.

I had the same issue with chapter numbers in my ebooks and solved the issue by using OpenOffice.org (OO.o). Rather than using manual chapter numbering or chapter breaks, I used OO.o's Fields function to create the chapter numbers. I created a field called "Chapter" and made the first "Chapter" equal to "1" and inserted the field into my ebook.

With each subsequent chapter I made "Chapter" equal to "Chapter+1." It made easy to correctly number the chapters, and if I inserted a new chapter the subsequent chapters would automatically be correctly renumbered.

[dgatwood]

Originally Posted by Solitaire1

I had the same issue with chapter numbers in my ebooks and solved the issue by using OpenOffice.org (OO.o). Rather than using manual chapter numbering or chapter breaks, I used OO.o's Fields function to create the chapter numbers. I created a field called "Chapter" and made the first "Chapter" equal to "1" and inserted the field into my ebook.

With each subsequent chapter I made "Chapter" equal to "Chapter+1." It made easy to correctly number the chapters, and if I inserted a new chapter the subsequent chapters would automatically be correctly renumbered.

Alas, the software I used originally lacked that level of capability.

Of course, I probably would have still translated to XML even if it did, because the custom software gives me a lot of control over the final markup that would have been hard to deal with otherwise:

• Drop caps are carefully positioned based on the letter and the text after it, complete with cut-ins (shape-outside), where applicable.
• "Special" pages (dedication, epigraph, title, verso/copyright, part separator) are SVG pages with a fixed layout.
• Cover art image size differs—the EPUB has a lower-resolution cover because of iBooks resolution limitations, whereas the Kindle has a higher-resolution cover so that it will look better after Amazon's kindlegen tool scales it down (grr).
• The Kindle edition uses very different markup to improve compatibility with KF7 devices (but resulting in something that can't pass EPUB validation).

and so on.

[Sarmat89]

Originally Posted by Toxaris

A lot easier and it also contains your precious semantics. It is still clearly defined as a letter. Styling is of course done in the stylesheet.

Now consider that not all readers support advanced selector syntax to format the first "letter" line different from the others: i.e. add bottom margin and inhibit page breaks.

[Toxaris]

Originally Posted by Sarmat89

Now consider that not all readers support advanced selector syntax to format the first "letter" line different from the others: i.e. add bottom margin and inhibit page breaks.

Again, that is the fault of the manufacturer of the reader (software), not the container/format. It is contained in the specification. You will never get a format which is 100% supported for all readers because quite simply reader creators are arrogant and think they know better and want to force that upon their users. Again, not a fault of the standard/specification/technology used.

It seems from what I gather that Coolreader specifically cares little about their users by ignoring perfectly fine and valid formatting.

[Hitch]

Originally Posted by dgatwood

Alas, the software I used originally lacked that level of capability.

Of course, I probably would have still translated to XML even if it did, because the custom software gives me a lot of control over the final markup that would have been hard to deal with otherwise:

• Drop caps are carefully positioned based on the letter and the text after it, complete with cut-ins (shape-outside), where applicable.
• "Special" pages (dedication, epigraph, title, verso/copyright, part separator) are SVG pages with a fixed layout.
• Cover art image size differs—the EPUB has a lower-resolution cover because of iBooks resolution limitations, whereas the Kindle has a higher-resolution cover so that it will look better after Amazon's kindlegen tool scales it down (grr).
• The Kindle edition uses very different markup to improve compatibility with KF7 devices (but resulting in something that can't pass EPUB validation).

and so on.

Not to digress, but, this:

whereas the Kindle has a higher-resolution cover so that it will look better after Amazon's kindlegen tool scales it down (grr).

...given that the cover is supplanted by the cover art that you upload at step 5 (or is it 6 now? The "Marketing image" upload, in any event...), why do you do this?

And after Dag replies, I return this thread to the control of its...starter.

Hitch

[eschwartz]

Originally Posted by Sarmat89

Now consider that not all readers support advanced selector syntax to format the first "letter" line different from the others: i.e. add bottom margin and inhibit page breaks.

So use the other CSS.

We have already established that XHTML is simpler than DocBook.
Now, we can add additional styling to the first letter, as an HTML class or an extra DocBook element.

But what makes you think reader apps written by developers who defecate on the EPUB standards, will be any better behaved when defecating on the DocBook standards?