February 2012 - gutvol-d - lists.pglaf.org

Re: [gutvol-d] Producing epub ready HTML
by Lee Passey 02 Feb '12

02 Feb '12

On Wed, February 1, 2012 12:20 pm, Robert Gibbins wrote: > Lee > > You were kind enough to offer to post my style sheets on your web site for > discussion if appropriate. > > I have attached the following files: [snip] About five years ago I conducted what I believe to be a very successful experiment designed to demonstrate that standard TEI files could be successfully viewed in a browser with the simple addition of a style sheet. Files demonstrating that experiment can be found at http://www.passkeysoft.com/~lee/tei/. I have taken the files you have provided, and deflated them at this same URL. At this point I haven't had the time to create any kind of fancy HTML page explaining these files (I'm congenitally incapable of "fancy") so what you will see here is simply a directory listing. If you could, I would appreciate it if you could put together a simple HTML page explaining what the files are and why they are interesting, I'll resolve any local links in it and put it up there as well. Thanks for your interest, Lee

1 0

Modified PG Files Posted
by Jim Adcock 02 Feb '12

02 Feb '12

I modified some PG files to remove some of their problems and posted them at: http://freekindlebooks.org/Aesop/aesop.html As you-all predicted a nuclear bomb went off and there is blood running in the streets.

1 0

it's wednesday, after noon, so let's get started
by Bowerbird＠aol.com 02 Feb '12

02 Feb '12

so, are we gonna do this crowdsourcing thing? or not? it's already wednesday, after noon, for crying out loud. when we gonna get started? give me some e-book #s. oh, and greg, i've decided you can host some of my files. because, hey, there's no place like the gutenberg ghetto! home sweet home! right alongside the other loser files! so, for starters, i'm gonna make some .epubs and .mobis. for each format, i'll have a version with block paragraphs, and a version with indented ones, and a "hybrid" version... i'll cross those with curly-quote versus straight versions, which gives, let's see, 2*3*2=12 different versions, so far, for every book i do, and that's just for warm-up purposes. next step will be .pdf, because those work nifty on tablets, and the ipad is still selling like hotcakes (and the fire too!), which means _24_ versions for every e-book that i do. yay! heck, make it 48... justified versus ragged-right is _vital_... so clear some disk-space away, greg -- fair warning! :+) i already have the batch file made, to churn them all out... this is so much fun. we shoulda done this a long time ago. so... when can we get started? just give me those book #s! -bowerbird

1 0

Re: [gutvol-d] it's monday, after noon, let's get the crowdsourcing started
by Lee Passey 01 Feb '12

01 Feb '12

On Tue, January 31, 2012 4:37 pm, don kretz wrote: >> I completely agree. >> >> Can we also agree that <a class="pgnum" id="pg00nn" title="nn"></a> >> satisfies all your concerns? >> >> > Sure, I've just improved the signal-to-noise ratio. Yours is a) just as > unambiguous; b) the same information is in there, but I'd say it's c) less > easy for users to apply (and miskey) and a bit more disruptive if you're > working on the text. I think that this conclusion is mostly a matter of opinion and personal preference. Personally, I think that putting meta-parsing content (the page number) in the middle of regular parsing content (the paragraph) /increases/ the noise. Besides, "<a class="pgnum" id="pg00nn">nn</a>" violates my number one rule, which is that every HTML master file must be readable in the absence of CSS. For me it is important that a page number /disappear/ when there are no styles beyond the default HTML styles. > It also biases the conceptual markup, which is what users should think > about, toward a specific format - i.e. html - when I like to emphasize the > importance of generality. People already too often think of each problem in > terms of the html solution to it. > > Just for an exercise i loaded one of the newer pg projects into my site. > Right away in the title page we had unclassed <h> tags with "style=#..." > That kind of stuff doesn't generalize anything. Go ahead and name names; which file was it? I automatically assume that any element with a 'style' attribute is wrong (I make a few exceptions for things like 'style="page-break-before:always"', but those exceptions are very limited. I also assume that any <style> element in the file is also wrong; but it is easier to deal with. > Another thing that's possible is to make up your own html tags. It's > perfectly legit according to the spec. Rather than use <span > class="sc">Arthur</span> you can just use <sc>Arthur</sc>. Your browser > will let you flavor it with the same css (although older IE needs a > one-line prompt in the css file.) If you do the same with <poem> and > <footnote>, people start to think a little more syntactically. And if it > intimidates you to try such a thing, you can still just regex the <span> > stuff back in. But mostly I prefer to use square brackets to emphasize that > it's conceptual markup, not html. And the publishing software I'm using > makes it easy to install this sort of thing. I have a toolbar with those > sorts of tags in the editor, for instance. > > That's having the software adapt to what's easiest for the user, rather > than vice versa. I sympathize with the notion, but I'm certain it's not a good idea to mix non-HTML markup into the file (which technically should be namespaced if you're going to do it). Again, my primary objection is that if CSS is not available the "new" markup is visually meaningless. If you really want to use this kind of semantic markup, you'd be better off abandoning HTML altogether and selecting some other XML vocabulary which is explicitly designed to capture this data; something like ... TEI! I'm a big fan of TEI. I only favor HTML for the practical reason that it is now so well established that people are comfortable using it, and that there are dozens if not hundreds of User Agents which are capable of rendering it. (About 5 years ago I produced a TEI .css file that caused TEI documents to render well in standard browsers without modification. I'll put that on the web site with Mr. Gibbens' documents.) I can't see expecting very many people to learn TEI. I /can/ see teaching people to use <i class="foreign"> when they encounter and italicized foreign word rather than using <foreign> directly. It's what they're used to. > Here's a better example. Right now I'm refactoring this markup from an EB > article (real example). > > <table class="nobctr" style="clear: both;"> > <tr><td><img style="width:856px; height:424px" > src="/vol12/3/images/img337.jpg" alt="" /></td></tr> > <tr><td class="caption"><span class="sc">Fig. 1.</span></td></tr></table> > > With conceptual markup, the equivalent (actually improved) result is > accomplished (an image that spans 100% of the column) with Of course it's an improvement because your example violates HTML rule no. 3: Tables should only be used for tabular data, and never merely for formatting. :-) > [illo src="/vol12/3/images/img337.jpg"]Fig. 1.[/illo] This is cleaner (assuming that "illo" really means "illustration") but absent CSS, XSL or some other sort of pre-processor the illustration wouldn't be presented and the text would just appear in the middle of ... something. I think this illustrates a question that should be answered: should the master format be something that can be consumed without modification or may it always require pre-processing? As near as I can tell, the only thing ReST has in its favor is that it satisfies the condition that it (hopefully) satisfies the white-washers' ITF requirement. If it doesn't, if it also requires pre-processing to make it useful, then I can think of nothing in its favor. [snip] > The DP html files are full of patterns like that, that can be automatically > refactored into the generalized equivalent to everyone's benefit. I believe this to be true, which is why Mr. Hutchinson's proposal is of so much interest. We should be able to grab the Perathoner/Haines/Widger files and automatically convert them to their generalized equivalents fairly quickly, ready for last minute tweaking to a file that can be used to create competent browser/Kindle/epub files programmatically.

1 0

a door on the other side of the car
by Bowerbird＠aol.com 01 Feb '12

01 Feb '12

remember how i described our recent discussion as the equivalent of the car full of clowns at the circus? well, another door, on the other side of the car, has now opened up, and clowns are spilling out of that... at d.p., they've started a new thread in the forums: > http://www.pgdp.net/phpBB2/viewtopic.php?p=821590#821590 go there yourself to witness the wide variety of reactions since the topic started just yesterday, but i'll include one of the posts for some flavor. > How does one tell compatibility, > if one does not have an epub reader? Does this > mean I and other PPers need an epub reader? > Which epub reader does one get-- > looking I see so many? All of them? > Are ALL epub readers compatible with each other? > Well, I will NOT buy one! > In this case that I now must ensure that > my html is compatible to an epub, > =I give up=. I am through. even if he doesn't "give up" right away, at the mere thought of the new task being imposed upon him, i'd guess that larry will seriously consider surrender once he finds out that not only are no .epub programs "compatible with each other", but there isn't even _one_ which correctly implements the standard as it's written. meanwhile... the clowns keep on coming continuously... -bowerbird p.s. people were pointed to the web-based epubmaker app, but there was some question that it was "broken" yesterday... nice way to kick off the thread, wouldn't you say? :+) p.p.s. there's already been an admonition "not to panic"...

1 0

iBooks Author EULA
by Jim Adcock 01 Feb '12

01 Feb '12

I would hope that no one on this forum or at DP would be silly enough to mess with Apple's new iBook Author software, but anyone considering doing so should first consider that Apple is asserting the right to exclusive distribution for fee over any and all things made with iBook Author. Which, I would think, is essentially an assertion of copyright by Apple over anything made with iBook Author. http://static.arstechnica.net/2012/01/23/iBooks_Author_License.pdf which is a particularly interesting assertion given that Apple acknowledges that iBook Author was written using Open Source software.

1 0

it's been four weeks already
by Bowerbird＠aol.com 01 Feb '12

01 Feb '12

it's been four weeks already. and still no one has told him. -bowerbird

1 0

don't be a politburo mid-level bureaucrat
by Bowerbird＠aol.com 01 Feb '12

01 Feb '12

i said: > bullshit, bullshit, bullshit. i have to remember to sprinkle in a smiley or two, every once in a while, just to remind all of you that i do indeed write every post with a smile on my face. :+) and yes, i get exasperated, and frustrated, but i also have a good time, because what else is there in life? besides, some of the crap that people try to pull here is -- quite honestly -- extremely amusing, at least to me. and so it is that i take up the latest message from greg... *** greg said: > You're fractionally wrong. We often forward > such reports to Marcello (sometimes others) so that > they can use it as feedback towards improvements. you should document that process, so we could actually _see_ that improvements are being made, however slowly. > But generally you are right. My response > when such things arrive in help@'s mailbox > is along the lines of: > - our auto-conversion is not always accurate, > and is particularly thrown off by some fancy > layout that is found in some of our HTML; and > - we do not currently have a mechanism to tune those > files, or add custom fixes to the collection, however, > - we are hoping to have such capabilities in the future. ok, greg, are you tone-deaf? :+) <--smiley do you know how that sounds to people out there? it sounds like you don't care. or let me put it to you as robert gibbins recalled it: > The response at the time could probably be > summarised as "yes, we know about that, go away" we know. now go. that's the message you're sending. your response sounds as if it was generated by some mid-level bureaucrat in the bowels of the politburo... even worse is how it totally displaces responsibility. your conversions suck because your converter sucks. let me repeat that. because it needs to sink in: your conversions suck because your converter sucks. no, it's not because of the "fancy layout" in the .html, which your volunteers submit, which would officially make it "their" fault, in the mind of marcello, anyway. no, it's primarily because marcello's converter sucks. is the .html to blame as well? of course. definitely. but guess what? that's _your_ fault too! at least it's juliet's fault. i made it perfectly clear, to _everyone_, that her "you can do stuff however you like" recruiting of postprocessors was gonna bite all of you in the butt, as soon as you had to rework their files for any reason, but y'all ignored my advice, and now y'all are suffering the consequences of your willful choice of that option... that's _your_ fault. not their fault. _you_ are to blame. you allowed d.p. postprocessors to make "snowflakes", instead of consistent books with dependable markup, so now you have to live with the ramifications of that. but don't blame them for your mistake. take the blame. and accept the responsibility that now you will have to include their "design preferences" within the workflow you want them to adopt. because you have no choice. their only "reward" for postprocessing those d.p. texts is that they can make their .html product "look nice"... they're accustomed to that, and you can't take it away. if you did, you would lose 90% of your postprocessors. you'll lose some of 'em just by _trying_ to take it away. or by dumping a system on them without consultation. you should have made them active contributors from the very _beginning_ of the process, for it to succeed. you put 'em in charge; now you can't boss 'em around. *** but the worst part of all is that your workflow is stupid. .rst was a lousy choice. (which is why i laid that trap.) and marcello's typically graceless implementation isn't helping your cause. (who ever thought that it would?) and, lest we forget, the output you generate is _crap_. then, to top it off, you ignore some good suggestions! an example of that is in this post to which i'm replying, which is a response to a suggestion coming from jim... he informs you that his tests showed that: > I have confirmed that changing the > [p] formatting statement in the css from: > margin-top: 0.50em; margin-bottom: 0.50em; > to: > margin-top: 0.51em; margin-bottom: 0.49em; > is in fact a reasonable practical solution to the problem. i assume this is for the kindle, since it comes from jim, and since the kindle does funky stuff with the margins. so how should you respond to this? you should say something very much like this: > thank you so much for doing this sleuthing! > we're going to go confirm that this fix works, > on the kindle, and doesn't have any bad effect > on any of the other formats we auto-generate. > this might take a little time, but if it does work, > we will confirm that to you within a few hours, > and have the change incorporated by tomorrow. > and again, thanks for figuring out this glitch! > please let us know about other improvements > that we can make. we appreciate your input... that's how you should respond to a suggestion like that. to _every_ suggestion that will improve your conversions. with _immediate_ feedback and testing and incorporation. because those awful conversions are the most important problem on your radar-screen at this point in time, greg. i shouldn't have to tell you how many .epubs and .mobis are being downloaded while we debate this issue to death. you need to _act_, and you need to act _right_now_... go! and get back to this list that you made jim's change today! -bowerbird

1 0

how to improve the p.g. book files
by Bowerbird＠aol.com 01 Feb '12

01 Feb '12

don said: > OK, I'm willing to listen to how I can improve any > "book files" (whatever they are) PG provides today. are you kidding? have you ever even _looked_ at any of the output -- .mobi or .epub -- that is being generated by p.g.? don't you feel any need to inform yourself before you speak? > What great secret do you share with them > that the rest of us aren't privy to? um, it's no "great secret" what the obvious flaws are, don... because -- d'uh -- the obvious flaws are terribly _obvious_. but, since you don't seem to be able to _see_ the obvious, i'll give you a few examples to sharpen your observation... first, the e-books start with legalese. you know that, right? and maybe you're accustomed to it, and you've "accepted" it, but if you want an improved product, move it _all_ to the end. what usually comes next is the title-page gunk of the p-book. that's typically too much information, too fast, and undesired. you should open with the equivalent of the cover of a p-book; that is, the title (and subtitle, if any) and the author (and the co-creators, if there were any), contact info, creation date of this latest version, and the e-book's canonical online address. that's all! all of this info should present itself compactly, on one screen, even if the end-user has their fontsize cranked up fairly high... p.g. e-texts _often_ get this "cover-page" screen badly wrong. *** next should come the table-of-contents. _without_question_. people should know -- with certainty -- where the t.o.c. is, and it should be in a convenient location, so let's make it standard. nor should this be one of those sprawling 10-screens things... indeed, _this_ table of contents should fit _on_a_single_screen_. even if, once again, the person sets their font-size fairly large... if you've got one of those sprawling table-of-contents monsters, make that the _next_ section, and call it "the extended contents". but the second screen should be a compact overview of the book, and a quick way to jump even to the sections at the very end of it. another thing which you can consider is to split up the monster. let's say the book has 5 sections, with 10 chapters in each one... the table-of-contents in the front could just list the _sections_. then, at the start of each section, you have another linked list, which gives the person all the chapter names for that section, plus links to the previous and next section-headers. this allows the reader to gracefully page through the sections of the book, getting a good idea of the chapters contained within each one... this is far preferable to a sprawling table-of-contents up front, where the screen-breaks will never coincide with each section... there are other ways you can make this work, too. for instance, p.g. has a book along the lines of "365 recipes"... yep, there's a recipe for every day of the year. pretty nifty, eh? so in that book, i turned each month into its own section, with the appropriate number of entries for the days of that month... depending on the book, there might be other ways that you can separate the table of contents into chunks that are meaningful. again, the idea is to make something that works as an _e-book_. that's the ideal, anyway. but, getting back to our reality... project gutenberg derivative formats often botch the t.o.c. badly. in many books, the items get joined together in one big jumble... in the worst cases, not al that atypical, the links don't even work. this sets a bad impression even before the person starts reading, not to mention the worse fact that it hurts the t.o.c. functionality. on the one hand, i know that the problem largely revolves around the fact that it's difficult to anticipate all of the t.o.c. snowflakes... so i'm tempted, for half a second, to excuse marcello's poor work. on the other hand, it shouldn't be that difficult to detect the t.o.c., and do whatever work is necessary to make it work in a useful way. (sorry, marcello, i tried to be nice, because i know you're a big fan.) *** a list of illustrations might come next, if the book has any... even if there wasn't one in the p-book, there should be one in the e-book. there's no law against improving the product. *** after that, you can put the obtuse crap from the title-and-verso. but... as far as most front-matter goes, it's not a bad idea to _move_it_ to the end of the book. an introduction should stay in the front, obviously, and a dedication doesn't take much effort to skip over, but a lot of the other stuff that's often presented as front-matter could -- quite easily -- be read at the end, and be just as useful. if you _do_ leave this stuff up front, though, you absolutely must give the person a link to skip it, and jump right into the book... do p.g. derivative formats do any of this? no, sadly, they don't. so these are ways that those formats could easily be improved. *** this is just to get you started, don. if you need more input, on matters involving the interior, i can give that to you as well. but you really should look for yourself. -bowerbird p.s. oh, and i know that a _lot_ of you other people are just as uninformed as don is, but -- unlike don -- you're too stupid to even ask any questions to get the knowledge you are lacking...

4 5

that error-report
by Bowerbird＠aol.com 01 Feb '12

01 Feb '12

al- i see that that error-report is on a burton book that jon noring used to talk about all the time... so i am highly suspicious that this error-report is just him yanking your chain, and that he has a clean copy of the text that he's holding back, because he wants to put you on a gerbil wheel. so i'm not gonna do any more work on this one. cheer up, though, because there are only 333 actual places with errors, and it looks like it is a solid report, not peppered with false-alarms. so if it is from noring, he's not being dishonest, just being "much less helpful than he could be"... either way, though, i don't feel like helping him, even in a roundabout indirect way like this one... -bowerbird

1 0