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

twisty little maze
by Bowerbird＠aol.com 26 Feb '12

26 Feb '12

telling, isn't it, that even the technocrats get lost inside the "twisty little maze" of a fellow technocrat. quite an admission. and speaking of a damning admission, i see another one of my antagonists has conceded defeat (but not said it directly). i wondered why greg would be replying to a request by lee for a plain-text converter, so i dug out lee's post from my kill-folder, and i see that he's finally looked at enough of the p.g. snowflakes to grok the problem presented by so many inconsistent methods. welcome to the table for the grown-ups, lee. you've graduated from the naive kiddie table. so now, of course, like everyone else who has come down this very same path before he did, lee seeks to be rescued by the plain-text files, the same files he's been condemning for years. how is _that_ for your week's supply of irony? and then, to top off this dessert with a cherry, marcello tells lee there is only _one_ converter that can turn a plain-text file into .html. right. there are ten tons of text-to-html converters, and many of 'em are specialized for p.g. work, including "gutenmark" and the one in guiguts. there are also many light-markup solutions -- watch me rub lee's nose in his piddle, lurkers -- which are open-source and will do the job, perhaps better than the tools mentioned above. i see that the latest version of some of these light-markup converters output to .html5 now, and not the outdated (x)html you might prefer, lee, so you'll want to seek out earlier versions. plus they're open-source, so you can always build on one, to create the output you want... but do not let marcello convince you that his inferior converter is the only one you can use. -bowerbird p.s. before you go too far down that road, lee, you might wanna go back and read the archives, where i've detailed the problems that lie there... you can now read those posts with smarter eyes.

1 0

Goals and scope (Re: Version control systems)
by Greg Newby 26 Feb '12

26 Feb '12

(New subject+thread) On Mon, Jan 30, 2012 at 08:54:18PM -0800, James Adcock wrote: > ... > Again, the direction I hear you guys heading in is that you-all want to > reinvent DP because you-all think you can improve-upon DP. Not saying you > can, not saying you can't. I'm just say that is not *what I heard* Greg > talking about. Thanks. This is just what I was thinking of pointing out (catching up on today's emails...). Below are details on what I was envisioning. The need I'm trying to address is reformatting or editing eBooks, not proofreading them. For starts, let's consider books that get into the PG collection in the usual way (i.e., culminating with a WWer posting them). I think we can do what's below while leaving the existing workflow out of scope. (It's not holy or untouchable or anything, just out of scope for what follows.) What I'd like is (as someone else nicely put it) a continual improvement opportunity, provided to essentially anyone, for eBooks in teh PG collection. This boils down to a handful of critical activities. It's mainly the third one (III) that involves crowdsourcing and new tools. I. making changes to the master file(s) [let's imagine that we retain the practice of every PG eBook having a small number of master files, in a small number of master formats]. The short list of master formats includes RST, HTML, TeX/TEI, and plain text (perhaps with light markup). Maybe this list will grow in the future; maybe it will shrink. The main feature here is that typos or fixes or additional master formats can be contributed. Challenges have been noted (revision wars; concurrent editing; bogus fixes; spam/inappropriate additions; inconsistent files...) II. from those master files, various other file formats can be [and are, currently] derived automatically. These include EPUB, Kindle variants, variations on HTML or text (especially if they were not previously provided), RTF, and a few others. Again, maybe this list will grow, maybe it will shrink. I do hope to offer conversion on-demand, which will let people select conversion options, and maybe even different conversion programs, for their purposes. The main features here mostly exist, but not as flexibly as I'd like to see. For example, applying a variant CSS. Or making a PDF with a specific font and paper size. Many challenges are technical, such as increased sophistication in dealing with text and HTML as master formats. Others need to be addressed by policy or social means, such as the ongoing tendency to use HTML for layout that is difficult to automatically convert. These, and others, have also been discussed deeply. III. from those master files, various other file formats that are created/contributed by individuals. I get offered these (via help@) practically every day. Usually EPUB, but also RTF/DOC, PDF. Often with typos applied. These are what I called "lovingly prepared," though of course some are better than others. These can be better than automatically-generated versions in various ways. They might have advantages over master files (for example, improved HTML). The main feature is that these would, in many cases, provide an improved reading experience (at least for some people, on some devices). If we accept that anyone could contribute such a new file (or set of files) for an existing PG eBook, then the main challenges I see are (a) how to help readers select among them, and (b) dealing with the fact that, over time, master formats will be fixed, but not these hand-crafted derivatives. I believe the solutions are related, and fairly easy. For (a), we need a community recommender system. Stars, batting average, +1, new/novell, etc. And, "dislike," "report a problem," "report abuse," etc. For (b), "time is on our side" (yes, it is). For a derivative format, we simply need to note when a master format was updated, but hand-derived ones were not. Plus, perhaps, a metric of how different the master format is from when the hand-derived one was created. Combined with (a), a recommendation would be attenuated based on such a metric. So, for example, a hand-derived file that gets a 90% quality rating from readers would slowly lose quality points as the master format is increasingly different. You get the idea... details TBD. Soooooooooooooooooo.... my main starting point was to ask about existing software for group editing. Version control systems seem a reasonable fit for this. Plus, sophisticated systems like TRAC also take care of managing users and their passwords. We do need to think of all the other stuff, but the basic idea was crowdsourcing for eBook formats/conversions/presentations. >From that standpoint, I've left many other (important!) things out of scope: proofreading (distributed or otherwise), tools for auto-conversion (we have some; others will plug-in but will be developed separately), and even arguments about master format (we have some, and better exposure of conversion tools and options will create a positive feedback loop to guide contributors to do a better job. And/or, open capabilities for OTHERS to fix the masters). Cataloging, metadata and supplemental info (such as author bios). Note especially that I don't envision developing tools to help potential contributors do the conversion. Not our bailiwick: there are entire ecosystems of tools already, and all we need to do is support the community of interested donors of resulting files (including pointing them at recommended tools). The PG toolchain for automated conversion should remain available (i.e., http://epubmaker.pglaf.org) I hope this helps clarify my original suggestion a little better. There has been some great discussion on this and related topics. -- Greg Dr. Gregory B. Newby Chief Executive and Director Project Gutenberg Literary Archive Foundation www.gutenberg.org A 501(c)(3) not-for-profit organization with EIN 64-6221541 gbnewby(a)pglaf.org

14 128

update on zero markup
by Roger Frank 26 Feb '12

26 Feb '12

Here's an update on my "zero markup" experiment. The idea was to create a document in UTF-8 text with no markup. A program then "sees" what a human would see: poetry blocks, epigraphs, block quotes, footnotes, etc. and render the other-than-text output accordingly. I wrote enough code to produce three books that are currently in smoothreading at DP. The goal was to make something that would be very easy for post-processors to use, especially at DP where the backlog is significant. I'm not claiming success on this one, though it does work. For one thing, the plain text cannot represent things like font size changes. Having the title line in a larger font on the title page is an example where that would make a visible and welcomed difference. The zml approach, taken purely, will have no "rend" attribute on an element. I allow the user to add presentation hints to any line that is centered, but it feels like I'm breaking the rules. There are other complications. As it's written, it generates valid and attractive HTML and the text can go up as well to PG without modification. But I suspect the HTML wouldn't make it through the PG ebook chain that creates the .epub and .mobi files. I cannot make any single HTML that is correct as input to both epub and mobi generators without resorting to a very low common denominator (such as nbsp's for poetry). I could have the generator make 3 separate files to be used for HTML and as inputs to epub and mobi generators. But PG understandably won't take that nor will they take actual .epub or .mobi files, also for good reasons. My choices are (1) abandon this and use RST for what's going to PG, or (2) find out what HTML will make it through PGs epub and mobi creating software so it doesn't fall out and use the text version instead. DP has a project underway to define the HTML subset that makes (2) work, which is very important to their PPers, most of which will not use PG-RST. PG-RST also isn't a good solution to produce books for other-than-PG repositories, such as for PG Canada. Bottom line: I have written a generator that takes a UTF-8 PG-submittable text and generates HTML--but that HTML is good, right now, only on a browser and not as a suitable input for any ebook-reader generators. I don't know where I'm going with this from here, if anywhere. --Roger

5 7

Producing epub ready HTML
by hmonroe1＠verizon.net 25 Feb '12

25 Feb '12

19 130

i mock you, and i laugh at you
by Bowerbird＠aol.com 24 Feb '12

24 Feb '12

three things... 1. where did all the yap dogs go? not that i'm complainin', mind you -- the silence is _golden_. but the recent whirlwind was just a bit puzzling. 2. if anyone here thinks they have the solution to "the problem of presenting poetry", in a way that works in .html, in a .mobi, and in an .epub, you should leave this dull backwater and get out and display your brilliance to the world-at-large, because nobody out there has found the answer to how to present a long line on a narrow screen. 3. per the ongoing search for a workflow to give project gutenberg and distributed proofreaders a "master format" that generates needed output, i mock you, and i laugh at you -- because i have demonstrated such a system, placed it right here under your nose, and repeatedly drawn attention to it, while you continue on your fruitless search, while i mock you, and i laugh at you, even as you obliviously continue searching, while i yet again show you my system, while you _still_ continue, while i mock you, and i laugh at you, while you... is it any wonder i mock you, and i laugh at you? look, folks, i'm doing it right now. _right_now_. can you see me mocking you? hear me laughing? best of luck with the search. have a nice weekend. -bowerbird

1 0

Re: [gutvol-d] update on zero markup
by Bowerbird＠aol.com 23 Feb '12

23 Feb '12

ok, let's refresh. we had 8 years of having me preach z.m.l -- zen markup language, originally known as zero markup language -- on this listserve, during which time it was discussed often, and usually in a quite contentious manner, at least until i proved beyond any doubt that it works. so all my antagonists, who were telling me all along that it would never work, then lost all their credibility in our little poker game. and yes, they're still very bitter about that. then roger, who has been around for a while, waltzes in, announcing he has this new idea, which he calls "zero markup language" (and abbreviates to "zml"), and he parrots back the explanation i have been giving for years, seemingly without any awareness that what he is talking about is the exact same thing that i've been preaching for the last 8 years. i'm amazed that no one even _tells_ roger, and make weekly posts after that, asking if anyone is ever going to tell him, or not. finally, after an "update" from roger on his work on his idea, i break the news to him... *** let me begin by saying i don't care if roger decides to work on z.m.l. i think it's great. i would even guide him, if he wanted that... or if he prefers working independently, fine. i don't even care if he doesn't want to give me any credit for the idea. he wouldn't be the first guy here to be so small-minded... almost no one has told me that i was right, on anything, even as they adopt my ideas, quietly, and without creating much fanfare. but still, i was amazed by this brazen act of roger coming in and parroting my idea... and i was puzzled as well... did he know what he was doing? how could he not know? did he really not know what z.m.l. is? again, how could he not know? but he seemed not to know! well, if he really didn't know, then he couldn't have been giving me any _credit_ for the idea, and if he wasn't giving me any credit for that, how could he diss me in general, which he did, on many occasions? (not as bad as some guys on this listserve, it's true, but _he_still_did_... don't deny it, roger, or i'll dig out examples.) it just seemed _bizarre_. and it still seems bizarre, because roger still hasn't said, straight-out, if he realized that he was just parroting back my idea, or if he truly thought he came up with it on his own. *** instead, what roger _did_ say was this: > Technology that a developer won't release > might as well not exist. what a big pile of b.s. this is. it's very typical of the blaming-the-victim double-bind tactic that's commonly used by the perpetrator in an abusive relationship. here's the truth of the matter: i _have_ "released this technology". indeed, i thrust it into the face of this listserve over and over again, when no one here wanted to hear it, even as i was punished severely because i persisted, and my message repeatedly ignored... because i was right, and i knew i was right, and i wasn't gonna let a wolf-pack of know-nothings chase me away, no matter how vicious they got. then, over the years, i showed demo after demo, proving the proof and tightening the noose, until nobody in that wolf-pack could deny i was right. oh, they still ignore me. and they still want to claim that -- because they have _ignored_ it -- that i've never "released" anything. yeah, right. you can't have it both ways, folks. i have offered stuff, time and time again, and you won't say that you want it, _so_you_don't_get_it_. -bowerbird

1 0

rewrapping p.g. to an existing scan-set
by Bowerbird＠aol.com 22 Feb '12

22 Feb '12

that didn't work. you can see those edits here: > http://zenmagiclove.com/prapr/pnp-858-edits.html -bowerbird

1 0

crowdsourcing
by Bowerbird＠aol.com 21 Feb '12

21 Feb '12

jayvdb said: > Thanks for the smile you're welcome, john... ;+) for those of you who do not know, jayvdb is a volunteer administrator at wikisource, and he pops up here from time to time to let p.g. know wikisource is a friendly competitor, not one who will embarrass you in hostile ways as it eats your lunch... and speaking of noisy chewing... that indicates that your mouth is out of alignment, john, meaning when i looked, your interface still doesn't show the book's linebreaks when text is juxtaposed with scans, which makes proofing much harder. i thought you were gonna fix that? or did i look at everything wrong? your chewing will be so much more efficient if your mouth gets aligned. plus your smile will look even better! ;+) -bowerbird

1 0

crowdsourcing
by Bowerbird＠aol.com 21 Feb '12

21 Feb '12

don said: > Here is the same article at Wikisource. that chewing noise you hear in the background is the sound of someone else eating your lunch. -bowerbird

2 1

still too busy. still the weekend.
by Bowerbird＠aol.com 19 Feb '12

19 Feb '12

roger said: > "Discuss next week"? still too busy. still the weekend. and still scheduled for next week. > You can have the last word. well, since you have no comeback, i'd say that's a foregone conclusion. and yes, i will set the record straight. given that agenda, though, i can say that what you did was galling, and appalling, and bordered on too incredible to believe, but i also found it extremely entertaining. moreover, you did not _intend_ any harm, so it doesn't even begin to approach being the worst thing that's been done on this list. you harmed yourself more than you hurt me.

1 0