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

bass-ackwards
by Bowerbird＠aol.com 10 Feb '12

10 Feb '12

keith said: > Evidently, everybody has not to some > very important views mentioned here. i can't parse that, keith. sorry. > P.G does not have any rules that could > be used by independent contributors. sure they do. but they're all kind of vague. and none of them are really enforced. reminiscent of this famous line: > the code is more what you'd call > "guidelines" than actual rules anyway... > From recent statements DP has some > consistency rules, but many ways of > doing the same thing. That is not good. right. because everyone's doing the job manually. if you give them a good tool that does the job, and does it quickly and easily, they will use that instead. and since the tool will do the task _consistently_, the output will be uniform, instead of snowflakes. the problem is that everyone approaches this as "the postprocessors have to change what they do". but the postprocessors _do_not_want_to_change_, because "change" sounds too much like hard work. but the reality is that -- if you did this correctly -- the approach would be "we'll help you do your job". with a bonus later of "and hey, it's working better!", when they learn that this new and easier workflow actually creates derivative formats that are superior. everyone's doing it bass-ackwards. you gotta show the postprocessors that this is in their best interests. you've gotta make their life easier, not more difficult. > ANA is an attempt to provide guidance > towards developing consistency rules. well, i haven't paid much attention to your scheme, keith, because you're re-doing something i already did, a long time ago, and i did it more systematically. further, i turned my work into an actual test-suite, so it's something with value for my programming... i have shown that my code can handle the test-suite, so i have good confidence it can handle most books people will throw at it. that's why you do a test-suite. otherwise, you waste your time on 300-page books that consist of little more than plain old paragraphs, and fool yourself that you "accomplished" something. > Once you have those, one can > develop tools that abide by these rules. again, you're 5 years behind me. i mean, it's nice that you're on the right path. but beyond that, there's not much i can say... > DP has no such consistent model. even if d.p. had a consistent "model", what matters is what the volunteers actually _do_. rules do _not_ guarantee consistency... they merely "promise" it... besides, "rules" are a non-starter over at d.p. sorry. the people over there don't want to learn your rules. they already paid their dues, creating their own way. they _might_ want to save their own time and energy. so that's the only avenue that's gonna succeed there. (and since many postprocessors do it for the fun of it, it's not even clear that "saving time" will be appealing. but, realistically, it's the only shot you've got. really.) so build 'em a tool that will save 'em time and energy. like the one i've built. because they aren't gonna want to use the one i built... because i laugh at their stupidity, and mock their pride, and i will enjoy it immensely if i can say "i told you so!" so they sure aren't gonna give _me_ that satisfaction... but if you code it, or don does, or hunter does, they will. and hunter has the leading edge right now, because he isn't going to make them change their workflow one bit. i would tell them to throw away their silly pseudo-markup. don would have 'em start using _his_ silly pseudo-markup. but hunter? he will let them continue on their merry way... so it's definitely hunter who is the one who could do this. unfortunately, he keeps threatening to pull out of the job. > those that have a say about how and what gets done are > competent in their individual fields, yet they seem to have > very little competence in the fine art of computer science. no comment. :+) -bowerbird

2 1

hunter could do it with guiguts
by Bowerbird＠aol.com 09 Feb '12

09 Feb '12

keith said: > This project belongs to dp! > I thought this is PG. A PG list and want to improve PG. the first rule of _cleaning_ a spill is to _stop_ the spill. it does no good to "fix" p.g. books if d.p. keeps sending "broken" stuff, especially in numbers which overwhelm all of the other contributors. plus, honestly, books that come from d.p. are more consistent than all the others. so any p.g. "change" _must_ start at d.p. that's just life. fortunately, that's not as bleak as it might sound. because it wouldn't be _that_ hard to change the d.p. way. the ironic thing is that, all along, my suggestions would have _saved_ work for the d.p. postprocessors... really! they expend lots of energy turning plain-text into .html. my converter-routine does that with the click of a button. that same button also creates .mobi, .epub, and .pdf too. and all these files are clean, consistent, and dependable. the key is to save the time and energy of postprocessors. *** after a while, i decided i didn't like d.p., because they are _mean_, so i didn't care if i saved their energy, so instead, i taunted them, and mocked their stupidity, which ensured that they _would_not_adopt_ my suggestions that would've saved _them_ a good deal of their time and energy, which i took as the perfect situation, as it punished their cruelty _and_ still allowed me the luxury of saying "i told you so"... it's sweet to make your enemies weep and gnash their teeth. but any of you, if you wanted to help d.p. _and_ p.g., can show them how they can save their own time and energy by adopting this text-to-html-plus workflow right now... indeed, hunter could _transform_guiguts_ into such a tool. (the reason people use guiguts is to save time and energy.) he just needs to reverse-engineer my workflow and scripts. heck, i'm even here to answer his questions, if he has any... then every book that d.p. sent to p.g. would contain: 1. .txt version. 2. .html version. 3. .mobi version. 4. .epub version. 5. .pdf version. (maybe too hard. or not. whichever.) no fuss, no muss. easy as pie, and it's a complete package, plus it all _works_. and the best part of all? well, that would be that you don't need to bow down to marcello no more. of course, if you'd rather have me snicker at your stupidity, and mock you mercilessly as you weep and gnash your teeth, well, that'd be o.k. with me too. i like to say "i told you so"... -bowerbird

3 2

pride. and prejudice. incremental. improvement. .epub.
by Bowerbird＠aol.com 09 Feb '12

09 Feb '12

here's an .epub version of "pride and prejudice". > http://zenmagiclove.com/prapr/prapr-epub.epub greg, please enter that in your not-a-tournament. *** since i went on record yesterday as knowing that very few of you are even _looking_ at these files, i feel no need to go through a long exposition of "here's the .html file, and here's the .opf, and...", blah blah blah blah blah blah blah. if you _want_ to look at those files, i assume you already know that an .epub file is a .zip with another extension, meaning you can just unzip it to get all the pieces. so have at it. or not. it makes no difference to me. i'm _showing_ this to you, because i know that you have a major need for this information, but if you want to keep your head stuck "in the sand", fine... but let's be clear: i'm not _building_ this for you. there is a big world out there that _will_ be glad to _use_ the one-source-file workflow i've developed. _glad_, i tell you. heck, perhaps even _overjoyed_. *** oh, and yeah, i'm not going to look at this .epub in a half-dozen viewer-programs, like with the .mobi. i expected those to work the same, more-or-less, since amazon has built a dependable consistency... .epub viewers, on the other hand, are a rat's nest, where i _know_ there will be major inconsistencies. so many, in fact, that i have no interest or intent to address 'em, in any way, shape, or form, thank you. we might be able to ignore these inconsistencies _if_ there was even one program which supported the entire standard, without any exceptions at all. but alas, there isn't even _one_ such app. not one. *** too many _idiots_ bought in to .epub, whole-hog, because it was the "open standard" they wished for. fine, you got your way, idiots, so now we have the "open standard" you always promised us, meaning we have the consistent rendering you promised us. except, no, no we don't. in fact, the _consistency_ resides in the _proprietary_ system from amazon... explain _that_, you idiots. and what have we gotten from "the open standard"? well, there's that inconsistent rendering across apps, of course. but we've also got multiple d.r.m. systems. adobe is wrapping their .epubs in their d.r.m. system. and apple wraps their .epubs in another d.r.m. system. and barnes&noble has their own system, for the nook. and kobo... no one can figure out what kobo is doing, including kobo itself. so the whole notion that you could buy your .epubs at any store you wanted, and read them on any machine? that didn't happen. and if you really thought it would, you're an idiot. because the companies who run stores want you to use their .epubs on their machines... d'oh. because, you know, it's good for their business model. and the companies who sell machines want you to buy your .epubs in their stores, because, surprise surprise, that happens to be good for their business model too. and if you really thought that these _businesses_ would sacrifice their _profits_, so you could buy cheap .epubs one place, and cheap viewer-machines in another place, well, you know, your idealism is nice, but you are naive. a.k.a. stupid. a.k.a. an idiot. a.k.a. a blooming idiot... so we're stuck with d.r.m. in multiple forms. just great. *** and apple, of course, after "embracing" .epub, recently "extended" it, with release of their ibook author tool... most of us know the third "e" in this e-book "strategy". so, is the i.d.p.f. -- the official "parent" of .epub -- concerned about all of this fragmentation? hell no. i.d.p.f. is the tool of corporate publishing dinosaurs, who _want_ e-books to be as complicated as possible, so they can maintain their p-book business for a while. because, you know, they have boat-payments to make... this is what happens when we let capitalists run the show. -bowerbird p.s. this .epub was built from a single 800k .html file, which means that it will choke primitive epub-viewers, like adobe's. maybe i will change that; maybe i won't. we probably should cut the not-ready-for-prime-time, rather than continue catering to adobe's incompetence.

1 0

this list is archived
by Bowerbird＠aol.com 09 Feb '12

09 Feb '12

keith said: > If the deleted messages are delete trashed, > I do not have the link! this list is archived, keith: > http://lists.pglaf.org/mailman/private/gutvol-d/ for instance, here's the list of this month's posts, by date: > http://lists.pglaf.org/mailman/private/gutvol-d/2012-February/date.html here's the file with all of the messages so far this month: > http://lists.pglaf.org/mailman/private/gutvol-d/2012-February.txt.gz -bowerbird

2 1

there has to be at least one lurker
by Bowerbird＠aol.com 09 Feb '12

09 Feb '12

keith said: > I just uese calibre as a viewer ok, then mocking laughter it will be. :+) > could you just send me your mobi file. just did. let me know if it didn't come over... but once again, was there a reason you couldn't just download it? > http://zenmagiclove.com/prapr/prapr.mobi also the related files: > http://zenmagiclove.com/prapr/prapr.zml > http://zenmagiclove.com/prapr/prapr.html > http://zenmagiclove.com/prapr/prapr.ncx > http://zenmagiclove.com/prapr/prapr.opf > http://zenmagiclove.com/prapr/prapr.jpg *** and, for those who might have missed this fact, while being buried with posts on "hypotheticals"... i've posted 3 honest-to-goodness real examples in the past few weeks, with almost zero feedback. these include "pride and prejudice", "aesop's fables", and -- the most wide-ranging -- my 2012 test-suite. real books. with real words. in real files. real. really. i wish i could make myself think there was no criticism because people did a very close examination and found that there was simply nothing they could improve upon. but let's face it. we all know that that was not the case. nobody even looked at any of it, let alone "examined" it. because i sprinkled all kinds of little flaws throughout, just to see if anyone would mention them. nope. nada. which is fine, folks. i'm quite used to being ignored here. doesn't bother me. it's no different than writing a blog that nobody reads, which is what i'd be doing otherwise. except that i know that there must be at least one lurker out there who is getting a kick out of the fact that all of these posts are flying back and forth about "how to do it", when one of us is actually doing it, out in the real-world, and mounting demos, as proof, while everyone else talks and just _ignores_ the proof and continues jabbering on, as if they were still in search of a solution for the problem. i mean, seriously, there has to be at least _one_ such lurker. but maybe that's a dream too. maybe it's me. and just me. -bowerbird

2 1

it's all fun and games until someone loses their life
by Bowerbird＠aol.com 08 Feb '12

08 Feb '12

keith said: > What does it look like in calibre! i don't think you understand. i don't care what it looks like in calibre. at all. not the slightest bit. not a damn. not one iota. and if you -- or anyone else -- _does_ care, i will laugh at you. and mock your stupidity. or else give you a stern lecture about how you must discard e-book-converters which create crappy code, like calibre or marcello's monster. because when you allow shit like that to exist, you threaten the quality-of-life for the planet, our system-of-wisdom already too precarious. so which of the two would you prefer, keith? the stern lecture? or the mocking laughter? -bowerbird

2 1

Re: [gutvol-d] just for the fun of it
by Bowerbird＠aol.com 08 Feb '12

08 Feb '12

keith said: > Just for the fun of it, > you could try Calibre on the Mac! i would not consider that "fun". i would be more likely to call it "torture". i've looked at the mark-up calibre generates. and i have dealt with its asshole programmer. both of those have made me allergic to calibre. if it works for you, and meets your needs, fine. but i have absolutely no use for it. none at all. > Or just e-mail the file any reason you can't download it from the site? -bowerbird

2 1

pride. and prejudice. incremental. improvement.
by Bowerbird＠aol.com 08 Feb '12

08 Feb '12

well, ok, for the .mobi i created yesterday, i've looked at it in a couple different ways. 1. it looks good in my mac desktop kindle app. 2. it looks good in my iphone kindle app. 3. it looks good in my ipad kindle app. 4. it looks good in my mac desktop kindle previewer. 5. last but not least, it looks good on my kindle. i tried to look at it in amazon's cloud reader > http://read.amazon.com but i can't see how to import "personal documents". the only thing i disliked enough to _change_ was the limp paragraph indentation on the iphone app. i'd try to increase that, but only if it wouldn't make the indentation _too_big_ in all the other viewers... oh yeah, i'd also give a little more breathing room to the chapter-navigation links above the headers, because sometimes finger-presses on them instead activated the "next page" area of the right-margin, or the "toggle bookmark" area at the upper-right... and headers too could stand a bit more whitespace. but i consider it to have attained success now, and will go on to .epub. unless someone has criticism? speak now. or later i will just say "sorry, too late". *** also, just so it's clear, it's no surprise that this book should render quite nicely on all of these platforms. after all, this is a very simple book, consisting of the basics -- paragraphs, in chapters, with frontmatter. if your system can't handle a book that's this simple, you're in trouble. because this thing is a "baby" book. so i am sure that the p.g. mobi for this book displays fine too. (ok, except maybe with spacey paragraphs.) what _is_ significant here, though, is that we got a consistent, acceptable appearance on all platforms with virtually _no_styling_ at all... (and the little bit that we did use was auto-applied by the converter.) this is a very important takeaway. now take a long look at the .css that marcello uses... it's a mess of gobbledygook, a steaming pile of shit. and it's a mirror which reflects the fact that there is a corresponding pile of complex tag-markup as well, creating a dense, complicated mess that's difficult to even get your head around, let alone come to master. that's the wrong way to do it. it's over-complicated. it's smarter to start simple, and build up minimally, with constant vigilance against tolerating any bloat. *** moreover, what we most typically hear, from e-book "designers", are complaint after complaint about how they tried to do something, but the viewer-app didn't give them the result that they had been led to expect. and hey, i can agree that if you specify a right-indent of 3ems on a blockquote, that's what you should get. but it doesn't do any good to _cry_ if you don't get it... you need to accept the reality of what actually happens. and work within those constraints. that's the way it is... and, given the situation that you're _not_ gonna get the right-indent on a blockquote that you asked for, then perhaps a "solution" is _to_stop_asking_for_it_. to stop banging your head against the cement wall is _not_ to "give up", but rather to do the sensible thing. it's also important to keep in mind that even when we decide to stop asking the kindle for a right-indent on our blockquotes, it doesn't mean that we have to stop asking for a right-indent on our other output-formats. if the .epub viewer-programs support it, that's great! when we convert to .epub, we'll specify a right-indent. finally... i _reject_ the contention that we have to "dumb down" the books in order to put 'em on the mobile platforms. as the current example shows, we can get _nice_output_ -- the kind we would hope for, and specify ourselves -- from almost all these machines, even the smallest ones. yes, we _might_ have to give up a few things, such as the right-indent on blockquotes when converting to a .mobi. but i don't believe that qualifies as "a dumbing-down"... it's a minor quibble, one we can hope will be fixed soon, but certainly not one that should cause us great despair. so i'd encourage you to wipe that "dumbing-down" idea from your brain-space. we do _not_ have to accept that. and it is most assuredly _not_true_ that using a _simple_ system is the equivalent of "dumbing-down" our approach. indeed, i'd say that over-complicating things to the point where the whole thing falls apart is really the _dumb_ path. -bowerbird

2 1

five weeks now
by Bowerbird＠aol.com 08 Feb '12

08 Feb '12

five weeks now, and still not one word... -bowerbird

1 0

APA : Goals
by Keith J. Schultz 08 Feb '12

08 Feb '12

Hi All, Lets start moving on to the real work now. For any good specification we need some goals to test if it fits the use it is intended for. 1) a basis for a master format for PG 2) a basis for testing if a format can be used to mark up a book that is used and accepted by PG 3) a basis for a mark up language or needed features 4) a basis for what should be used to constrain the use of features in any given mark up language so that the file can be accepted by PG 5) a basis for building converters to the master format 6) should be able to capture the original layout of the book 7) should consider that it is to be used for creating derivative works in the output formats PG supports 8) should be strict! That is avoid having more than one way to mark up a feature. 9) will not based on any mark up language I think that wraps that up fairly, good. Did I miss anything? Of course I am assuming PG will adopt this in the end or at least sanction it as a best practice. So: 10) used by PG as a guide. regards Keith.

2 2