Quote:
Originally Posted by ProDigit
I find that an epub should work perfectly without these lines of code.
HTML can, why MUST epub have an author or a title?
What if the Author does not want to put his name there?
|
It needs a title; it doesn't need an author.
The author can use "Unknown" or "Redacted" or "anonymous" or "decline to state" or a pseudonym of choice--or not put in an author. But the book needs a title so that the software can identify it.
It needs a title in the same way that a digital file needs a name. HTML doesn't, because it's not designed to be read by software that uses "title" to list & sort files.
The
Epub format construction guide goes into detail about what is and is not required.
Quote:
|
About trimming, I can do in HTML what I can do in epub,only 3 times smaller.
|
Then why aren't you just making HTML files and releasing those? ("Because most ebook readers won't read HTML, and when they do, they don't support all the features I want to include." Which, um, leaves you with "use a format designed to work for most books," which includes features that aren't directly important to your book.)
Epubs were designed to include both metadata and navigation options that HTML has problems with, and to run on remote devices with strict memory limitations.
Quote:
|
The only purpose it serves is have nice hyperlinks and background scanning, and database sorting capabilities. It serves a purpose somewhere I suppose, but I don't think it should automatically be a necessary part of the code.
|
Hyperlinks, background scanning, and database sorting options are not bloatware options in ebooks.
Quote:
If I can do something simple in HTML, why make it complex in epub?
Why not make ePub compatible with HTML, and leave it simple where it needs to be simple?
|
Because it needs to support options that aren't important to you.
Quote:
Like, this would be a nice toc for me:
Code:
<title>Table of contents</title>
[1:"Chapter 1"]link/to/1st.document[/1]
[2:"Chapter 2"]link/to/2nd.document[/2]
[3:"Chapter 3"]link/to/3rd.document[/3]
[4:"Chapter 4"]link/to/4th.document[/4]
[5:"Chapter 5"]link/to/5th.document[/5]
Would be an example of a very efficient code that automatically assumes first document is first to be displayed in the book, is called "chapter 1",and knows the location of that chapter.
|
That's basically what it is. It takes more characters to describe because it supports options you don't care about--subset categories, links within documents, readable metadata.
Quote:
now compare that to this:
[code]<ncx version="1"
xml:lang="en">
<head>
content="95e823ba-8f88-4c44-9f9d-b22ff04d5358" />
</head>
|
That, you can change. Pick a unique DocID system of your own. You don't have to use the random string of numbers and letters. Many people use ISBNs for the DocID.
Quote:
<docTitle>
<text>Table of Contents</text>
</docTitle>
<navMap>
<navPoint id="d362620c-c3f8-45e2-8e63-2a62a2757f81"
playOrder="1">
<navLabel>
<text>Book title</text>
</navLabel>
<content src="content/CompleteA_revised_split_0.html" />
</navPoint>
|
<navPoint id="5809ab0e-a3b1-446b-b4d8-ad487a1e546b"
playOrder="2">
<navLabel>
<text>Chapter</text>
</navLabel>[/quote]
You don't need the long random-number strings. You can rename the ID points to make sense & be easy to follow:
Code:
<docTitle>
<text>Deliver Us</text>
</docTitle>
<navMap>
<navPoint id="navPoint-1" playOrder="1">
<navLabel>
<text>Deliver Us</text>
</navLabel>
<content src="Text/03Titlepage.xhtml"/>
</navPoint>
<navPoint id="navPoint-2" playOrder="2">
<navLabel>
<text>Disclaimer</text>
</navLabel>
<content src="Text/05Disclaimer.xhtml"/>
</navPoint>
...and so on.
Quote:
|
Looking at the very basics, it's saying the same thing;and in an ebook reader both can be showing exactly the same on the screen; namely, that I want it to display a toc directing to the first 5 chapters; and use that toc to play back chapter 5 after 4 after 3 after 2 after 1, after the toc. But see the amount of code that's been implemented to reach to such result in current version epub!
|
Because not everyone builds them the same way you have. Saying "it should be simpler because I don't care about the other options" is pointless. A person might want multiple navLabel sections inside a navPoint, which you can't do with a single-level "ToC Label: URL" arrangement.
Quote:
|
Trimming code may not make a lot of sense for regular books, but it does for bibles, and dictionaries,and encyclopedia's with tons of chapters, pages, and reference notes.
|
Very long and complex books have always been problematic for publishing. This is not a sign that the publishing standards are flawed; it's a sign that you're working on a book that pushes the limits of the format.
Bibles are often printed in small type on very thin paper because if they were printed on normal paper, they'd be several volumes long. Trying to cram a small-encyclopedia-length work into a single volume is going to be troublesome.
If it helps, there's a build-epub-from-scratch tutorial at the
Spontaneous Derivation wiki. It goes through the bare minimum requirements for an epub's structure.