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

blah blah blah blah test case blah blah
by Bowerbird＠aol.com 09 Oct '12

09 Oct '12

don said: > Here is a PG project that needs some formatting help. i'd have to see the scans to know if that's true or not. > The HTML conversion would probably best be termed "fail". > Yet it should be a simple case. the .html was created by epubmaker, and yes, it's a disaster. > How would you want proofers to submit it > after "matching the scan"? where is a scan-set for this book? > What would you consider to be > a properly marked up copy > in the format of your choice? i can show you, but it'll have to wait until next week. > How should it get there from the previous step? by clicking a button. the same button that the "proofers" clicked, when they were cleaning it up, to check it, and ensure it displayed the way they wanted. *** however... it is important to note that this is _not_ the way to "test" this kind of thing. instead, you need to prepare a test-suite containing all the elements that are important, so as to test 'em all at once... but first you need to _decide_ on those elements. again, you guys are about 8 years behind on this. so you will need to move a bit faster to catch up... -bowerbird

1 0

PG catalog
by don kretz 09 Oct '12

09 Oct '12

I have converted the PG catalog into a mysql databases. There are some interesting anomalies. For a first example, the following ebooks have no title: | id | +------+ | 1070 | | 1071 | | 1072 | | 8817 | | 9116 | | 9117 | | 9118 | | 9119 | | 9120 | | 9121 | | 9122 | | 9123 | | 9124 | | 9125 | | 9126 | | 9127 | | 9128 | | 9129 | | 9130 | | 9131 | | 9132 | | 9133 | | 9134 | | 9135 | | 9136 | | 9137 | | 9138 | | 9139 | | 9140 | | 9141 | | 9142 | | 9144 | +------+ This should allow us to answer some of the statistical type questions about PG etexts. Don

5 10

Use any markup
by don kretz 09 Oct '12

09 Oct '12

What is important is to mark the semantic elements and their locations, which requires no more quantity of markup than I have shown. Sent from my Phone

1 0

Re: [gutvol-d] requirements feasibility plan
by don kretz 09 Oct '12

09 Oct '12

I'm not suggesting anyone use my markup. You can use any markup language you want. You could use tei or xhtml or probably zml. the same patterb Sent from my Phone ------------------------------ From: James Adcock Sent: 10/9/2012 6:17 AM To: Project Gutenberg Volunteer Discussion; lee(a)passkeysoft.com Subject: Re: [gutvol-d] requirements feasibility plan *>*This is the first and only requirement. Sorry, but in practice a couple more requirements: You have to find enough volunteers who are willing to write to your pet language requirements that PG / DP can afford to kiss off the volunteers who are still interested in writing in other formats. Volunteers may be interested in writing in other formats supported by the rest of the industry, for example, because they may not want to be “locked in” to solely writing for PG. You have to find tool-makers including editor creators to make the tools that make writing books to this standard reasonably pleasant and relatively foolproof. And these tools need to be supported on all the major OS’s. You have to find a systems “build master” who is willing to write the tools and actually support them to accurately compile your markup language to the formats which customer’s devices actually support, including html, epub, and mobi, and who is actually willing to fix these tools when they generate broken output. Perhaps most hard, you have to find someone who is actually willing to write support manuals and online help for all this stuff. And all this has to be done indefinitely into the future, for at least the next couple decades, so that PG is not left with an incompatible and unsupported pile of rotting compost, wasting 100,000s of volunteer hours.

1 0

Re: [gutvol-d] blah blah blah blah blah
by don kretz 09 Oct '12

09 Oct '12

One wonders about how wwers distinguish between calling a submission a "correction" (and presumably altering the existing distribution), and calling it a "new version" and giving it a new number with zero distribution credibility. If it's derived from the old version with the intent to only make corrections, is there a threshold number of corrections beyond which it becomes a new version with all the attending discredit? If I also add markup in addition to corrections, does that make it a new book number, or a new format for the old one? Seems like the original contributor could be presumed to have implicitly authorized, indeed welcomed, corrected versions as replacements, regardless of the magnitude of the resulting change. Don From: Jon Hurst Sent: 9/25/2012 4:27 AM To: gutvol-d(a)lists.pglaf.org Subject: Re: [gutvol-d] blah blah blah blah blah On 2012-09-25, Bowerbird(a)aol.com wrote: > > I would also like to do a LaTeX version, so will > > need a stage before you add your formatting -- > > it doesn't have to be my RTT, > > but the lines need to correspond. > > i'm just mounting the projects. > > somebody else will have to clean the text. > > and add the formatting. > > i mean, i _might_ do some of that stuff, but > i'm not making any guarantees that i _will_... > > but i doubt i will. i have bigger fish to fry... > > also, i think it's silly not to add the formatting, > so you'll have to _remove_ any that i've added. > (but that would strike me as immensely stupid, > because then you'll just have to add it back in.) So here we have a demonstration of the exact set of problems that I was trying to solve. You don't want to clean the text, due to your big fish frying activities. I don't particularly want to spend my (admittedly fishless) limited time cleaning the text either. Pretty much everyone on this list doesn't want to clean text that is not for their own solo project. There are 1000 odd people who will be glad to clean text for you and know what they are doing, but they live at PG and if you want to play there, you have to play by their rules. Greg has a hose full of people that will clean text for you, but if he turns it your way, you will have to train them first, and in your case you will not just have to train them to check that the word in the text is the same as the word in the image, you will have to train them in all things ZML as well. I don't want to start from your ZML. I'm sure ZML is lovely, but I want to work from the corrected text and images where the number of introduced errors is lowest. That is my preferred workflow, and I'm not prepared to compromise on it. Consider it a religious thing, that I am going to be utterly unreasonable about, and that nothing you say will ever change my mind on it. A workflow can go from RTT to ZML very easily, but the reverse is not necessarily the case. That was the point of the RTT. If you mandate that what comes out of your system is ZML and only ZML, then I'm not interested in working within your system. Finally, unless I am reasonably convinced that something useful will come of it, I am not going to proofread word 1. Useful means default PG download and that, at the very least, means preferred PG edition, and the existence of some sort of default download protocol. Posting a small selection of books on your own site while laudable means pretty much nothing at all in the grand scheme of things. So... we agree on the necessity of master scans, we agree that a default download protocol is a requirement before it is worth commencing any work. Let's narrow our focus to these two seemingly simple items. With these in place, people can roll up their sleeves. Maybe some will do redos as solo projects, maybe some will do them through your system, maybe one of the DP's can help make some RTTs. Without them, it is simply not worth starting anything... which you may recall was what I was trying to determine right at the start of all this dialogue, and more or less the first piece of advice you gave me. Cheers Jon _______________________________________________ gutvol-d mailing list gutvol-d(a)lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d

12 34

blah blah blah blah blah blah problematic
by Bowerbird＠aol.com 09 Oct '12

09 Oct '12

don said: > The first, and I think non-negotiable, requirement > is that whatever standard is selected it must have > a reasonably complete set of markup to capture > all the features of a book. Figuring out just what this > "reasonably complete" set of features is is nonetheless > problematic. you guys still haven't figured out the features of a book yet? you're off writing up the first draft, once again, as always, just the first draft, of your magical plans to rule the world, and you still haven't done the grunt work to know the basics? i've had a test-suite in place for about 8 years now, dudes... so, you know, as soon as you're ready to stop imagining, and _get_real_, i'll just be sitting over here, waiting... for godot... -bowerbird

1 0

p.g. times ten
by Bowerbird＠aol.com 08 Oct '12

08 Oct '12

just a thought before this sub-thread shrivels away... if you really want a "p.g. times ten", i would say that your only good bet will be with a wiki infrastructure. that would enable lots of people to contribute by negotiating a comparatively low entry-threshhold. you'd need to avoid the ossification plaguing wikipedia, but i don't think you'd end up with the animosity from "editors" asserting their power, to delete contributions, simply because the notion of matching the scans would give a rather objective criterion, compared to wikipedia, where a standard for "what's included" is more subjective. -bowerbird

1 0

feedback to jeroen on his question
by Bowerbird＠aol.com 08 Oct '12

08 Oct '12

jeroen said: > Please inspect one of my most recent submissions ok. :+) > in German, so the text won't distract), since much of a structural approach involves a grasp of the underlying _meaning_, text never "distracts"... i'll let jim give a detailed analysis of how well the file acts when ported to .epub or .mobi, but i can give you a few thoughts on my opinions of it, since you asked... first, though, you can do a good test yourself, just by: 1. ripping out the stylesheet, and examining the text; 2. setting width on the body to something like 500px. if your markup still works under those circumstances, the odds are much higher it'll work in reader-machines. won't tell you everything, but it will tell you quite a bit. *** now on to my reactions... although i can't be positive, because of the german, it seems to me that this markup is quite acceptable. (aside from troubles specific machines might have.) i'm not sure if the tables will work with a small width, so that'd be something to check, and fix if necessary. pagenumbers always present a problem, because they get mixed in to the text. the best solution for that is to make them easily visible to a reg-ex, for removal... in this particular book, the square-brackets work fine, because you don't have any other occurrences of them, but that won't always be the case, so i'd recommend that you add an additional component, such as [#69]. or -- if a number-sign seems too intrusive to you -- you could use nbsp around the bracketed pagenumber. your "inhalt" links jump to the actual place in the t.o.c. that match the jump-point, which is something i have often thought about doing, but usually decided against, relying instead on a jump to the top of the t.o.c. page. in working with your file, i think my instinct was right. when i jump back to a table of contents, i don't wanna see the contents _from_that_point_down_, i want it all. or at least i want the contents _around_ the jump-point. (if browsers didn't put the target-point at the _very_top_ of the window, but instead showed some context-lines, which is something that i've always argued they should, i might prefer your method. but as it is, i prefer mine.) the most solid recommendation i would have, though, is for you to re-think your policy on creating link id's... right now, they are some weirdish alphanumeric string, which might have some rhyme or reason to it, i didn't bother to try to figure it out, but it's still far too cryptic. i generally use the text of the jump-point itself, so that people who are looking at the text can _guess_ the link and almost always be correct, with a very high certainty. it's often the case that we think of the id element as an internal reference that only the computer needs to know, but it actually serves to create a deep-link into the text, so it has to be human-readable and even "make sense". anyway, that's my feedback, based on a quick once-over. -bowerbird

2 1

Re: [gutvol-d] blah blah blah feasibility blah
by James Adcock 08 Oct '12

08 Oct '12

>Jim, why don't you do instead of preaching? Offer to prepare HTML for post-processors that don't like preparing HTML, but can give you files marked with a reasonable extension of DP markup of your choice. Carlo, why don't we turn the question around: Why do you object to volunteers fixing broken html formatting, where that html formatting clearly doesn't work on one or the other of the major platforms? Why should PG et al be allowed to fix scanno errors, but not formatting errors? As I have said many times I *do* do what I preach -- I *commonly* download PG books in html format and then edit those html formats and fix the common formatting errors in order to allow them to be pleasantly read on my ebook readers, and then I compile those files locally to epub or mobi8 format -- because I personally do not enjoy reading "scrambled eggs" -- and in a few minutes I can usually create a book which is much more pleasant to read than that posted on PG. What I cannot do is resubmit those fixes to PG, so that other people can also avoid having to read "scrambled eggs." Why not allow others to enjoy the html formatting bug fixes I have already made?

1 0

Simplifying markup
by don kretz 08 Oct '12

08 Oct '12

I suggest that planning in terms of semantic markup in place of presentation markup could simplify the task of preparing texts for PG. If the semantic elements are properly identified, the software can easily apply the appropriate markup for each device. Here are a few items from the DP formatting guidelines. *Chapter Headings* Format chapter headings as they appear in the image. A chapter heading may start a bit farther down the page than the page header and won't have a page number on the same line. Chapter Headings are often printed all caps; if so, keep them as all caps. Mark any italics or mixed case small caps that appear in the image. Put 4 blank lines before the "CHAPTER XXX". Include these blank lines even if the chapter starts on a new page; there are no 'pages' in an e-book, so the blank lines are needed. Then separate with a blank line each additional part of the chapter heading, such as a chapter description, opening quote, etc., and finally leave two blank lines before the start of the text of the chapter. Old books often printed the first word or two of every chapter in all caps or small caps; change these to upper and lower case (first letter only capitalized). While chapter headings may appear to be bold or spaced out, these are usually the result of font or font size changes and should not be marked. The extra blank lines separate the heading, so do not mark the font change as well. See the first example below. *Replace with* Identify chapter headings with a chapter heading tag; e.g. <chapter-heading>Chapter 1.</chapter-heading>. The software will then be able to find the first letters of chapters and apply drop-caps if you really want them and the device supports them. *Section Headings* Some books have sections within chapters. Format these headings as they appear in the image. Leave 2 blanks lines before the heading and one after, unless the Project Manager has requested otherwise. If you are not sure if a heading indicates a chapter or a section, post a question in the Project Discussion, noting the page number. Mark any italics or mixed case small caps that appear in the image. While section headings may appear to be bold or spaced out, these are usually the result of font or font size changes and should not be marked. The extra blank lines separate the heading, so do not mark the font change as well. *Replace with* Identify sections with section tags, and identify the section heading, if any, with section-heading tagls. Other Major Divisions in Texts Major Divisions in the text such as Preface, Foreword, Table of Contents, Introduction, Prologue, Epilogue, Appendix, References, Conclusion, Glossary, Summary, Acknowledgements, Bibliography, etc., should be formatted in the same way as Chapter Headings, i.e. 4 blank lines before the heading and 2 blank lines before the start of the text. *Replace with* Note that the instructions say to use chapter heading formatting rules, hopefessly defeating any expectation that chapter heading formatting rules will unambiguously tell the software where the chapters are. Instead, just mark the divisions with the proper tags (<toc>, <intro>, <prologue>, etc.) and the headings with the proper tags (<toc-heading>, etc.)

1 0