Re: [gutvol-d] seriously, feel free to ask any questions
ok, so it was pretty hilarious that i suckered the idiots into throwing every bit of their credibility into the pot, so they _lost_it_all_ when i showed the winning hand... i mean, they were _just_fine_ with having a war when they thought _they_ were winning; it was full-out attack-mode. they were tripping over each other, throwing rocks at me... it was only when they realized that they were gonna _lose_ that they started withdrawing, and getting as quiet as mice. but what i didn't fully appreciate was that my long play also engendered their _pride_. so now, even though they realize that light-markup is the way to go, it still makes them choke, and they can't get themselves to use it as the master-format. so it's business as usual, with every .html version as unique as a snowflake, meaning the p.g. library will have no future. marcello -- ironically, since he was the worst of the bunch -- has tried to install restructured-text as a default book-format, but the take-up over at distributed proofreaders is very slow... to his credit -- and there is very little for which we can give marcello much credit, but that's no reason not to grant it -- marcello realized that if p.g. cannot put worthwhile e-books on platforms from amazon and apple, the p.g. ship will sink. so he's _trying_ to do that. but he's also getting no help from the whitewashers, as shown by the recent post from al haines, where al actively distanced the whitewashers from the output marcello generates, saying "we have nothing to do with that." well, you know what, al?, maybe you _should_ have something to do with that. maybe you should rip that authority right out of the hands of marcello, and start doing that job yourselves... but the attack-pack here will never let you do that, will they? because they are too proud to _admit_ that they were wrong. (let alone that they were extremely cruel to boot...) -bowerbird
but what i didn't fully appreciate was that my long play also engendered their _pride_. so now, even though they realize that light-markup is the way to go, it still makes them choke, and they can't get themselves to use it as the master-format.
At least in this posting BB makes clear he intended course of action. Rather than as he has claimed previously that he is not attempting to "force" anyone one to do anything, rather here in this posting he makes it clear that he IS attempting to "force" people to do something: namely he is attempting to "force" PG to adopt ZML as a "master format" replacement for the already odorous requirement to submit txt70, thus "forcing" all PG volunteers to make a version of their volunteer submission efforts in ZML. Why does BB want to "force" volunteers to take such actions? Simply because he knows that they would not take such actions voluntarily - the vast majority of volunteers DO NOT want to support BB and do not want to write in ZML. What do volunteers want to write in? Overwhelmingly they want to write in HTML. Some would like to write in EPUB, and some would like to write in MOBI - or at least be allowed to submit in addition in EPUB or MOBI. A smaller fraction want to write in txt70 only. If in fact ZML were a superior format then BB wouldn't have to try to "force" volunteers to do anything - they would naturally flock to a tool that makes their efforts easier and more fun! Does HTML have problems? Absolutely. Namely it seems that the great majority of people posting to PG don't know or don't care about what it takes to write HTML that actually "works" on the great majority of reader devices that PG readers use. [But this problem could be "solved" if PG required that HTML that contains of one these obvious fatal flaws be fixed before submission. The problem could also be "solved" if PG were to document what it takes to write HTML that actually works on the great majority of reader devices] Does HTML have any advantages? Absolutely - at least ONE overwhelming advantage: Namely it is what volunteers overwhelmingly want to write in. Another advantage is that it has thousands of well-developed tools from 100s of professional suppliers. If somehow BB were able to "force" PG to replace the onerous txt70 requirement with an even more onerous ZML requirement the end result is clear: Namely that the volunteer transcribers will simply choose to post elsewhere than PG. Again, BB is simply attempting to once-again to re-litigate the last 40 years of markup languages, claiming vast superiority for his preference for the use of tilde ~ as the markup symbol of choice in his lightweight markup language, as opposed to say equal-sign = in reStructuredText. http://en.wikipedia.org/wiki/Lightweight_markup_language http://en.wikipedia.org/wiki/Markup_language My simple counter-suggestion is: Allow volunteers to submit in whatever one-or-more formats the volunteers want to submit in, as long as at least one format is non-encrypted non-compressed. You could even require one format be a txt-like format for archival purposes - as long as you don't require additional onerous hand-markup requirements on that txt-like format, such as IS required by ZML or txt70. PG can and should (as it has always done between some formats) auto-convert between supported formats. You should also allow and encourage volunteers to submit hand-conversions to the other formats when the original submitter declined to submit in those formats. Part of the current problem with PG is simply that PG does not allow volunteers to submit in the formats of their choice - rather PG forces anyone wanting to submit in EPUB or MOBI to instead submit in HTML - and then wait and see what kind of EPUB or MOBI the PG mechanizations spits out at public posting time - and then the volunteer gets to regret their HTML choices at their leisure.
James, I agree that it would be helpful if I could submit an EPUB and MOBI as well as HTML and plain text. I just submitted a book of poetry a week or so ago which looked great as HTML but was unreadable (bad indenting) if you just converted the HTML to a MOBI. The HTML was designed to look as much as possible like the printed book. I had to do some reformatting to get it in shape for the Kindle. I then posted corrected EPUB and MOBI to archive.organd the Kindle Store. Unfortunately, the vast majority of downloads for this book were from PG. Plus the Kindle Store will take PG's version, put a generic cover image on it, and make it a free book on the Kindle Store. So most Kindle owners downloading the book have gotten a badly formatted text. The corrected HTML is used to generate the EPUB and Mobi did not work as well as a web page as my submitted HTML did. The book is this one: http://www.gutenberg.org/ebooks/38174 My own Kindle Store version is this: http://www.amazon.com/Vidyapati-Bangiya-Padabali-Krishna-ebook/dp/B006HJT1XU/ref=sr_1_2?s=digital-text&ie=UTF8&qid=1323379363&sr=1-2 Some SOB made a quick and dirty version for Kindle Store which is here: http://www.amazon.com/Vidyapati-Bangiya-Padabali-Krishna-ebook/dp/B006GVNURC/ref=sr_1_1?s=digital-text&ie=UTF8&qid=1323379363&sr=1-1 I'm not making any money on this. I just want readers to get a decently formatted book. James Simmons
Part of the current problem with PG is simply that PG does not allow volunteers to submit in the formats of their choice – rather PG forces anyone wanting to submit in EPUB or MOBI to instead submit in HTML – and then wait and see what kind of EPUB or MOBI the PG mechanizations spits out at public posting time – and then the volunteer gets to regret their HTML choices at their leisure.
_______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d
On Thu, Dec 8, 2011 at 4:26 PM, James Simmons <nicestep@gmail.com> wrote:
James,
I agree that it would be helpful if I could submit an EPUB and MOBI as well as HTML and plain text. I just submitted a book of poetry a week or so ago which looked great as HTML but was unreadable (bad indenting) if you just converted the HTML to a MOBI. The HTML was designed to look as much as
The problem is the WWers need the ability to regenerate or edit all formats to correct errata and add the PG boilerplate, which means they need both source files and the tool chain (if non-standard). PDF and MOBI/palmdoc are, IIRC, not really editable formats... -R C
On 12/08/2011 10:26 PM, James Simmons wrote:
The HTML was designed to look as much as possible like the printed book.
That was the error. Had you used a simpler formatting, it would have come out better.
Plus the Kindle Store will take PG's version, put a generic cover image on it, and make it a free book on the Kindle Store. So most Kindle owners downloading the book have gotten a badly formatted text. Some SOB made a quick and dirty version for Kindle Store which is here:
I'm not making any money on this. I just want readers to get a decently formatted book.
*LOTS* of people automatically convert every new book from PG and cram it into the Kindle/iBooks/Google store. If you want your book to go unscathed through all these automatic converters you have to use only the simplest of HTML. -- Marcello Perathoner webmaster@gutenberg.org
So most Kindle owners downloading the book have gotten a badly formatted text.
Elizabeth Castro http://www.elizabethcastro.com/epub/, I think it is, has some suggestions re how to "correctly" format poetry. A general problem with poetry is that it should in theory indent on wrap, not outdent. What to do when alternative lines already indent, as in your case, is beyond my competence in poetry [which ends with ... walls] Why your coding of poetry using spans should make the PG mechanizations so unhappy I don't see why. Be aware that Marcello's epubmaker [which is what PG uses to make epub and mobi] does considerable "rewriting" of the submitted html when converting to mobi (via epub) in order to try to work around the shortcomings of kindlegen -- where kindlegen doesn't handle many of the more "esoteric" [read: that which should be avoided] features of html, such as nesting and multiple inheritance (and float left, and float right, and ....) One common, and documented by Amazon, problem with kindlegen, is that the definition of mobi and the html to be submitted to kindlegen, does not include padding, nor does it include the merging of top and bottom margins. I think it also doesn't say that top and bottom margins are rounded to the nearest 1em. So, for example, if someone puts a top-margin: 0.5em bottom-margin: 0.em on their paragraph styles they are actually specifying that they want a 2em spacing between paragraphs in the mobi file. Ouch.
On Thu, December 8, 2011 2:26 pm, James Simmons wrote:
I just submitted a book of poetry a week or so ago which looked great as HTML but was unreadable (bad indenting) if you just converted the HTML to a MOBI.
Most people know that MOBI is just HTML encapsulated in a compression format. Many people don't realize, however, that Kindle only understands HTML version 3.2, and does /not/ understand style sheets. Many people /believe/ that style sheets are supported because the KindleGen program goes through a limited number of styles and actually converts them to their HTML counterparts. Thus, if you create some centered division of text by doing: <div style="text-align:center">...</div> KindleGen will actually convert that to <center>...</center> before storing it. You attempted to indent your poetry by using style attributes, e.g.: <p> <span style="margin-left: 2em;"><i>Not my way of Salvation, to surrender the world!</i></span><br> <span style="margin-left: 4em;"><i>Rather for me the taste of Infinite Freedom,</i></span><br> ... I do not believe that KindleGen has any built in rule that can convert "style='margin-left:x'" into anything the Kindle can understand. In this case, you would have been better off using the tried and true method of using non-breaking spaces to do the indentation (or maybe create a new HTML-to-Kindle preprocessor that Marcello can run before running KindleGen). A second problem you have here is...(wait for it)...tag abuse. You have taken a quote from another source (the poem) and told the device that it was a paragraph just like any other paragraph in the book. KindleGen will believe you, and carry that markup forward. Then, when you tell your Kindle "indent all paragraphs 5 characters" it will look at the first line of your poem and say "we're starting a new paragraph, I'd better indent that first line 5 em." I would have marked that verse as: <blockquote class="poem"> <div class="verse"> <i>Not my way of Salvation, to surrender the world!<br /> Rather for me the taste of Infinite Freedom,<br> ... Unlike <p>, <div> contains no semantic baggage that could violate your expectations.
The HTML was designed to look as much as possible like the printed book.
I can certainly appreciate the desire, but there are better ways to go about it. We all want to use the latest and greatest technology, but practically we must understand that when we do some old applications are going to get left behind (and Kindle is definitely an old technology). My general rule is to be suspicious of any style attribute. Sometimes they're best solution, but whenever you use one stop and consider what will happen if the device/software can't handle them. Style definitions should be separate from the content. If a <blockquote> needs to be indented in a manner different than it's default, instead of adding a "style" attribute to the <blockquote> element, add a class definition (it's OK for an element to belong to several classes) and add a style sheet definition for that class. E.g.: <style> .poem { margin-left: 5em } </style> <blockquote class="poem">...</blockquote> I prefer making stylesheets external to the HTML file. One reason is so that I can easily substitute my own style preferences for those of the publisher. (Justified paragraphs on a handheld device? gross.) A second is for testing purposes. Try constructing your file using only element classifications and true HTML elements, and then add all the styling necessary to make it "look as much as possible like the printed book" into an external style sheet. At this point, rename the style sheet (.css) file so your browser cannot find it. Does it still look acceptable? This is probably how it's going to look in the Kindle. Fiddle around here as much as you need to to get an acceptable, even if not perfect, look. Then go back and edit your style sheet file to make the result "look as much as possible like the printed book." HTH
Hi James, Whether I would say BB wants to force or would prefer is a matter of no particular interest. My opinion is that in any collaborative environment there should be conventions in place. Otherwise, you have a anarchy of formats and tools that require a lot of work to maintain and eventually get into an e-book. I do agree that most do not know what HTML(5) really is and how to use it effectually for a particular task. It is like driving a car. Just because you have a drivers license, does not mean you are a good driver. As for the all those nice and neat HTML-tools, well 99% are junk. After searching for decades I am still looking for a decent tool either non-commercial or not. I find the best tool for writing HTML is a plain text editor!!!! It should have some nice features though. I believe PG should change its philosophy towards e-books. 1) ereaders are widely available and free 2) the e-book can have a close enough resemblance to the original to satisfy most. 3) only a minority still have and use hardware where they can not use an e-book 4) the e-book can be converted to plain vanilla text easily, if: a) guidelines are in place for the CSS b) guidelines are in place for tagging features Basically, it is what PG has wanted from the start: free and accessible books/texts. --- And, later on aesthetic form for the texts/books. regards Keith Am 08.12.2011 um 21:24 schrieb James Adcock:
but what i didn't fully appreciate was that my long play also engendered their _pride_. so now, even though they realize that light-markup is the way to go, it still makes them choke, and they can't get themselves to use it as the master-format.
At least in this posting BB makes clear he intended course of action. Rather than as he has claimed previously that he is not attempting to “force” anyone one to do anything, rather here in this posting he makes it clear that he IS attempting to “force” people to do something: namely he is attempting to “force” PG to adopt ZML as a “master format” replacement for the already odorous requirement to submit txt70, thus “forcing” all PG volunteers to make a version of their volunteer submission efforts in ZML. Why does BB want to “force” volunteers to take such actions? Simply because he knows that they would not take such actions voluntarily – the vast majority of volunteers DO NOT want to support BB and do not want to write in ZML. What do volunteers want to write in? Overwhelmingly they want to write in HTML. Some would like to write in EPUB, and some would like to write in MOBI – or at least be allowed to submit in addition in EPUB or MOBI. A smaller fraction want to write in txt70 only.If in fact ZML were a superior format then BB wouldn’t have to try to “force” volunteers to do anything – they would naturally flock to a tool that makes their efforts easier and more fun!
Does HTML have problems? Absolutely. Namely it seems that the great majority of people posting to PG don’t know or don’t care about what it takes to write HTML that actually “works” on the great majority of reader devices that PG readers use. [But this problem could be “solved” if PG required that HTML that contains of one these obvious fatal flaws be fixed before submission. The problem could also be “solved” if PG were to document what it takes to write HTML that actually works on the great majority of reader devices] Does HTML have any advantages? Absolutely – at least ONE overwhelming advantage: Namely it is what volunteers overwhelmingly want to write in. Another advantage is that it has thousands of well-developed tools from 100s of professional suppliers.
If somehow BB were able to “force” PG to replace the onerous txt70 requirement with an even more onerous ZML requirement the end result is clear: Namely that the volunteer transcribers will simply choose to post elsewhere than PG.
Again, BB is simply attempting to once-again to re-litigate the last 40 years of markup languages, claiming vast superiority for his preference for the use of tilde ~ as the markup symbol of choice in his lightweight markup language, as opposed to say equal-sign = in reStructuredText.
http://en.wikipedia.org/wiki/Lightweight_markup_language
http://en.wikipedia.org/wiki/Markup_language
My simple counter-suggestion is: Allow volunteers to submit in whatever one-or-more formats the volunteers want to submit in, as long as at least one format is non-encrypted non-compressed. You could even require one format be a txt-like format for archival purposes – as long as you don’t require additional onerous hand-markup requirements on that txt-like format, such as IS required by ZML or txt70. PG can and should (as it has always done between some formats) auto-convert between supported formats. You should also allow and encourage volunteers to submit hand-conversions to the other formats when the original submitter declined to submit in those formats.
Part of the current problem with PG is simply that PG does not allow volunteers to submit in the formats of their choice – rather PG forces anyone wanting to submit in EPUB or MOBI to instead submit in HTML – and then wait and see what kind of EPUB or MOBI the PG mechanizations spits out at public posting time – and then the volunteer gets to regret their HTML choices at their leisure.
_______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d
And, later on aesthetic form for the texts/books.
Writing, formatting, and publishing books is an art form. When people "transcribe" books leaving out that artistry, and transgressing the rules of the last 500+ years of formatting books then they have in fact failed in their transcription. Having said that it is possible to maintain the artistry of the original book while transcribing it and publishing it in "more modern form." In fact looking back at books published turn of the century one can find books which were 100 years ahead of their time, and books that languished 200+ years behind their time - both in terms of quality, artistry, and in the quality and techniques used to format that book - so this is not a new issue. Bottom line truth: Much of what PG publishes looks like crap -- even when that which the volunteer transcriber submits was a reasonable effort in the first place. Is it possible to read something that looks like crap? Yes. Should PG "customers" be subjected to reading something that looks like crap? No. Should PG "customers" be told to "go somewhere else" if they don't like looking at crap? No. Rather PG should take a good hard look at what they are publishing, stop making excuses, and do what is necessary to stop publishing something that looks like crap. IMHO.
On 12/09/2011 08:58 PM, James Adcock wrote:
And, later on aesthetic form for the texts/books.
Writing, formatting, and publishing books is an art form. When people "transcribe" books leaving out that artistry, and transgressing the rules of the last 500+ years of formatting books then they have in fact failed in their transcription.
Every art form depends on the medium. When the medium changes, the rules also change. When people "transcribe" from an unflexible and uncustomizable paper substrate to a flexible and customizable electron substrate, and do not adapt the rules, they have failed.
Bottom line truth: Much of what PG publishes looks like crap -- even when that which the volunteer transcriber submits was a reasonable effort in the first place.
This is a typical Adcock rant. Don't even ignore him, as they say in Vienna. -- Marcello Perathoner webmaster@gutenberg.org
This is a typical Adcock rant. Don't even ignore him, as they say in Vienna.
You deny that much of what PG posts looks like crap??? I can see making excuses about how hard it would be to fix the problem, but to deny that the problem exist in the first place??? Let's turn it around: What at PG doesn't look like crap? Answer: Much of the submitted HTML doesn't look like crap, because most people care enough not to submit something that looks bad. Now mind you, their HTML coding choices may be bad, but the rendering itself typically doesn't look bad -- when you read it using a "top 3" web browser on a desktop. And their choices may be ignorant of how bad their choices will look when rendered into epub or mobi....etc. And you may ask the question why they don't test their own HTML converted to epub or mobi using their own tools (such as kindlegen) -- since in practice they cannot use the PG tool chain? But, to deny the problem in the first place???
participants (8)
-
Bowerbird＠aol.com -
James Adcock -
James Simmons -
Jim Adcock
-
Keith J. Schultz -
Lee Passey -
Marcello Perathoner -
Robert Cicconetti