Register Guidelines E-Books Search Today's Posts Mark Forums Read

05-19-2009, 07:27 AM   #16
pepak
Fanatic

Posts: 594
Karma: 4150
Join Date: Mar 2008
Quote:
 Originally Posted by rogue_ronin Hmmm, another thought. Does it make sense to include the following two things?
It does make sense, but seems a bit too detailed to me. It may be interesting, but:
- the book should never leave your computer in the intermediate stages
- after version 1.00, most of the changes will be along the lines of "fixed typo on page 123 line 15".

Quote:
 #2: structure hints. Should someone have to examine the entire source for a clue to how it's been assembled? Or could you add something like this as a comment?:
Personally, I prefer the "no-clue" approach. If someone wants to see the clues, he can easily do that (for all books at one stroke) by modifying CSS, e.g.
Code:
h1.title:before { content: "Title: "; }
But once again, I must stress that I do the books for myself, to suit my needs, and not for public consumption. If you want to provide a standardized framework, the opposite approach might be better - if you use a proper tagging, hiding all "clues" would be even easier:
Code:
.clue { display: none; }

05-19-2009, 07:35 AM   #17
rogue_ronin
Banned

Posts: 475
Karma: 796
Join Date: Sep 2008
Location: Honolulu
Quote:
 Originally Posted by pepak You may want to contact a proofer or another - so you need an e-mail and possibly some IM. You can add them to the list (into parentheses, or something), but if the amount of data still increases, the list will become even less readable.
Hadn't thought of contacting them, that makes sense. Given the below comments, I think I would go with putting them into parentheses.

Quote:
 Do you have any specific reason why you don't want to use multiple meta's? Code:   Consistently, you could do all multiple-value metas this way, e.g. for author. Reason being, it makes sense to place a book by A. Smith and B. Johnson both among "Smith books" and "Johnson books".
I assumed that all the meta names needed to be unique. If they don't, then I'm for not numbering them, and just adding multiple meta's as necessary.

Quote:
 Personally, I prefer the SQL-standard of yyyy-mm-dd, which is easy to sort even in textual form.
Just as easy the other way, and closer to how we (well, americans) speak. At least I'm abandoning the american, mmm/dd/yyyy, which is the way it is because it's exactly the way we speak. Plus, I'll get confused if I do it that way, I know I will.

Oh, and looking at your example, I realize I didn't terminate the meta tags with />...

m a r

 Enthusiast
05-19-2009, 07:52 AM   #18
rogue_ronin
Banned

Posts: 475
Karma: 796
Join Date: Sep 2008
Location: Honolulu
Quote:
 Originally Posted by pepak It does make sense, but seems a bit too detailed to me. It may be interesting, but: - the book should never leave your computer in the intermediate stages - after version 1.00, most of the changes will be along the lines of "fixed typo on page 123 line 15".
Your analysis of my words is correct, but I might release earlier -- some of the sources I don't have, so I cannot go past 0.80 on that scale, yet there's no reason to keep them locked up on my hard drive. I should probably reword as follows:

Code:
   0.10 Initial Conversion
0.20 Cover and Frontispiece
0.30 Sections, Chapters and TOC
0.40 Endnotes and/or Blockquotes
0.50 Initial Spellcheck
0.60 Mdashes and Hyphens and Ellipses
0.70 Italics, Bold, and Pre-Formatted Text
0.90 Checked Against Canonical Source
1.00 Final Version -- Optimal
1.00+ Minor Error Corrections
I think that including it would suggest to someone how to add value and version it consistently. I can think of arguments for releasing at 0.50 and 0.60 as well.

Quote:
 Personally, I prefer the "no-clue" approach. If someone wants to see the clues, he can easily do that (for all books at one stroke) by modifying CSS, e.g. Code: h1.title:before { content: "Title: "; }
You've got me there, I can't follow you yet -- just starting to get into the CSS.

Quote:
 If you use a proper tagging, hiding all "clues" would be even easier: Code: .clue { display: none; }
I assume you mean to put the "clues" into a special container. I'm just thinking to put it into a comment. Could you explain more fully?

m a r

 05-19-2009, 09:37 AM #19 rogue_ronin Banned   Posts: 475 Karma: 796 Join Date: Sep 2008 Location: Honolulu Device: Nokia 770 (fbreader) So, minor update after discussion above: Code:  A Princess of Mars  I'm sort of liking this; I think it achieves two things -- it is parseable for utilities/macros and it is human-readable and human-editable. Oh, and completely invisible to a person just reading the book. Hopefully it puts everything that you need to know about the following file right at the top, where you can use it to re-write CSS, or pick a version number, or whatever. If for some reason a person only had this file, would it be easy to recreate the rest? I guess the final thing it could need is a manifest of image/sounds that it references. m a r
05-19-2009, 10:10 AM   #20
pepak
Fanatic

Posts: 594
Karma: 4150
Join Date: Mar 2008
Quote:
 Originally Posted by rogue_ronin I assume you mean to put the "clues" into a special container. I'm just thinking to put it into a comment. Could you explain more fully?
You should definitely read up on CSS, it will make things a lot more clear. But, without going into details, there are three main "identifiers" of what a given CSS option-set should affect:
something { ... } - this CSS applies to tag something
.something { ... } - this CSS applies to any tag that has (or contains) a class something
#something { ... } - this CSS applies to any tag that has id (or name) something.
You can combine and nest these identifiers, but that's not important. The important thing is that if you put your "clues" into your document as either a special tag, or as a tag with a given class, you could style them using CSS quite easily, including the possibility to hide the clue altogether.

E.g. <h2><clue>Chapter:</clue> Chapter 10</h2> could use a styling such as clue { display: none; }.

The problem with the above example is that there is no clue tag in XHTML - you would have to define it yourself. That's why you may want to prefer to use e.g. a span: <h2><span class="clue">Chapter:</span> Chapter 10</h2> and hide it with .clue { display: none; }.

Quote:
Nope. I will add to it if someone starts it, but I don't want to start it myself.

 05-19-2009, 10:14 AM #21 pepak Fanatic   Posts: 594 Karma: 4150 Join Date: Mar 2008 Device: Sony Reader PRS-505 But, on the other hand, it would be just as simple to use:

Chapter 10

and .chapter:before { content: "Chapter: "; }, which saves on one tag, or even

Chapter 10

...

...

, which keeps an extra tag (div), but makes a clear distinction of where a chapter begins and ends (h2 only marks where the chapter's title begins and ends, not the chapter itself; it is only implied that a chapter ends where a next chapter begins, but that may not necessarily be true for all books).
 05-20-2009, 04:27 AM #22 rogue_ronin Banned   Posts: 475 Karma: 796 Join Date: Sep 2008 Location: Honolulu Device: Nokia 770 (fbreader) Okay, I read the W3C Schools CSS tutorial yesterday, I'm following you better. 'Course, I'm not a wizard. Yet. Yeah, I posted above you with my current solution. I'll be adding a manifest, then I think I'm pretty complete with meta -- but of course, I'm still open to suggestions/improvements. I don't want to clutter the markup with too many classes and pseudo-classes. At least for the meta-info, I'd pretty much like to keep it all in the head, and use it consistently so that it becomes easy for anyone to write new CSS, to extract data for conversion to other formats, etc. And I think I disagree with you only because I don't want any of this stuff to appear in the book as one reads (except for some stuff in the verso) so there's no reason to add more code to obscure it or reveal it. It's just there for tools/utilities, and for reference when someone wants to look under the hood for any reason. Meta on the structure is just a polite thing: "Here's every element, class and relevant ID we're using in the document, and how we're using them -- no need to try to determine it all again by hand and eye." Not home now, but I'm gonna keep going with this. I'll add the manifest next, then I think I'll move on to determining elements and classes and etc. for the various pieces of a book. Your comments about vs.
s are right on (and thanks for educating me regarding
s.) I'll definitely be doing that, or some variant of it. m a r
 05-20-2009, 05:05 AM #23 gwynevans Wizard     Posts: 1,344 Karma: 1065246 Join Date: Nov 2007 Location: UK Device: Sony 505 (retired), iPad2, iPhone 3GS & Nexus 7 3G There's some CSS 'RefCardz'(!) at DZone that might be worth a look - http://refcardz.dzone.com/refcardz/corecss-part1 - http://refcardz.dzone.com/refcardz/corecss2 & - http://refcardz.dzone.com/refcardz/corecss3 Registration required, but it's a legit site.
05-20-2009, 11:56 AM   #24
rogue_ronin
Banned

Posts: 475
Karma: 796
Join Date: Sep 2008
Location: Honolulu
Quote:
 Originally Posted by gwynevans There's some CSS 'RefCardz'(!) at DZone that might be worth a look - http://refcardz.dzone.com/refcardz/corecss-part1 - http://refcardz.dzone.com/refcardz/corecss2 & - http://refcardz.dzone.com/refcardz/corecss3 Registration required, but it's a legit site.
They look good, but I'm remaining anonymous!

m a r

 05-21-2009, 08:43 AM #25 rogue_ronin Banned   Posts: 475 Karma: 796 Join Date: Sep 2008 Location: Honolulu Device: Nokia 770 (fbreader) Brevity is the soul of wit! Back home again for a while, so here we go... I think this will do as a tentative final format for the head, and all meta info. You can't use
s in the head, right? Code:  A Princess of Mars  Using the format of "item :: description" for the comments/info. The structure hints are the actual tag, the manifest uses relative path. I guess that leaves me with only two questions remaining for meta info: 1) If
s can be used in the head, then maybe the BEGIN and END comments should be changed to
05-21-2009, 08:56 AM   #26
pdurrant
The Grand Mouse

Posts: 26,766
Karma: 76586132
Join Date: Jul 2007
Location: Norfolk, England
Device: NOOK ST GlowLight
I don't think you should be so prescriptive about the order of things between the cover and the parts.

Indeed, in a fiction ebook I much prefer to nearly all that stuff at the back of the book, with links to it from the contents menu.

Quote:

 05-21-2009, 09:12 AM #27 rogue_ronin Banned   Posts: 475 Karma: 796 Join Date: Sep 2008 Location: Honolulu Device: Nokia 770 (fbreader) So, you would have: Cover Table of Contents Parts, Chapters, etc Everything that normally comes before the Parts Afterword, etc. Is that right? Do you do this so that you can get right into the book? Does your reader have a touchscreen, or way to navigate links? m a r
05-21-2009, 09:38 AM   #28
pdurrant
The Grand Mouse

Posts: 26,766
Karma: 76586132
Join Date: Jul 2007
Location: Norfolk, England
Device: NOOK ST GlowLight
Personally, I'd have

Cover
Title Page
(Possibly Dedication)
Parts
Everything else

I generally read Mobipocket format eBooks. They have a "Go To" menu that's usually populated with links to Start of Book, Table of Contents, etc. So to navigate in the book, I just bring up that menu and choose.

For example, the book I'm reading now "Morality for Beautiful Girls" has the following items on the "Go To" menu:

First Page
Last Page

So getting to the Table of Contents takes the same time no matter where it is. So there's no point in having it at the front, although this book does do that.

I have a CyBook, so no touch screen. When reading a book it's quite quick to being up the main menu, select to the Go To menu, and then choose a desination from there.

Quote:
 Originally Posted by rogue_ronin So, you would have: Cover Table of Contents Parts, Chapters, etc Everything that normally comes before the Parts Afterword, etc. Is that right? Do you do this so that you can get right into the book? Does your reader have a touchscreen, or way to navigate links? m a r

05-21-2009, 09:49 AM   #29
pepak
Fanatic

Posts: 594
Karma: 4150
Join Date: Mar 2008
Quote:
 Originally Posted by rogue_ronin Back home again for a while, so here we go...
- I think you will have trouble with authorfirst/authorlast/illustratorfirst/illustratorlast if a book has multiple authors/illustrators.
- The classes seem superfluous: Personally, I prefer to use classes only to modify the default structural information. E.g. <h1>, as the "top header", is always used for title, unless class specifies something else. Similarly, <p> is always a common paragraph; I will only add class if I want to specify that it is not a normal paragraph after all.
- Not sure what would the navigation buttons be used for.

Quote:
 You can't use
You can't.

Quote:
 1) If
s can be used in the head, then maybe the BEGIN and END comments should be changed to
s?
You can't. Even if you could, that would make the metainformation visible, which is not a good thing, IMO.

Quote:
 And 2) When/if there are more than one author or illustrator, should there be a numbering system -- as there are 4 entries for each name, would it be easier (or necessary) to parse based on numbers or positioning?
I would combine all info about one author into one meta, then used multiple instances of said meta to describe multiple authors:
Code:
<meta name="author" content="Raymond E. Feist|Feist|Raymond E.|feist@midkemia.com" />
<meta name="author" content="Janny Wurts|Wurts|Janny|" />

05-21-2009, 12:25 PM   #30
rogue_ronin
Banned

Posts: 475
Karma: 796
Join Date: Sep 2008
Location: Honolulu
Quote:
The REB1100 has a GoTo menu, also. (Only 7 items, but still useful.) And I usually automatically populate it with a TOC link, First Page link and a Verso link (info about the book.) In addition, I add Next Chapter, Last Chapter and TOC buttons at each chapter heading. So you can just bounce through the book -- but that's for a touch screen of course, or for some other way of selecting links.

Given that you're looking to jump to the TOC, nothing about the structure I've offered would stop you from populating that GoTo menu exactly as you've described, and getting to it immediately. If you don't have a limit on the number of entries, you could include every chapter and other element too (Preface, About the Author, etc.) The difference only comes when you page manually through the book.

There are two things, I think, that your comments (thankfully) suggest to me.

One is that there is a difference between the format for the reader and the purpose of the XHTML specification that I'm trying to work out. Given a comprehensive, rational spec, anyone could transform it easily (ridiculously, scriptably easily) into any form, order or format that works for them and for their hardware. Slap it into Calibre, you've got ePub -- properly separated, etc. rbmake would love this spec, (you might have to use some regex on it for new-pages, but rbmake itself lets you do that) and smack it right into an RB file. I'm sure that the mobipocket converter would recognize it -- might even be able to generate that TOC automatically, but I've no experience with it. I'm certain that someone expert could do it easily.

It's an archiving spec, essentially, although it's readable by anything that reads HTML. It's hardware neutral. It's easily parseable. It's human readable. It is as simple as possible, without losing information. It accurately represents the structure of a book.

Second, if I do this properly, with meta and structure strictly controlled, CSS can do things like change layout such that you reorder the book (at least I think so; wizards please chime in.) At the very least, the CSS would be able to suppress any undesired pieces of the book, given that they will be properly labeled (ie: div.frontispiece { display: none } ) . Just offer you a custom CSS file -- easy to do -- and every book that you get from this spec will appear as you wish it to.

As a corollary to the above ideas: I like opening books and seeing the stuff before the TOC. Real, physical books I mean. I know that we're not talking about the same thing, and that we're not bound to forms that grow from different media -- but I like the traditions of offering you the mental framework of reading, the experience of it. I'm not a typography nut, nor do I read every detail of the printing history of a book when I open it. But I think that the stuff that opens a book (aside from the modern addition of advertisements) are a reflection of the wisdom of crowds -- generations of people kept the best practices and added new ones when they thought of them. The structure of a book is integral to the way it works, and it works in more ways than reading the stories, and I'd like to support that if I can.

So this is a long way of saying that we can both have what we want from this; but the archival nature of the spec means (to me) that the structure of books must be reflected in the structure of the spec. Traditionally, Prefaces appear before TOCs -- but TOCs usually make reference to them, which is great in the new world of links.

When I finish this, I'll convert A Princess of Mars into it; take a look at it (in your browser, even) and I think you'll like the functionality, and hopefully I'll even make a CSS that adds beauty to it. We'll see.

Thanks for provoking me,

m a r

 Tags html, library, meta, structure, xhtml