On 10/10/2012 9:09 AM, Lee Passey wrote: [snip]

This file obviously needs a lot of work, and probably is more deserving of attention than many of the recent obscure and esoteric works for which raw page scans are adequate to serve the academic community. I'll try to fix it as best I can, but this will probably take me several weeks. I'll post iterations on my web server as I go along, and provide comments here as iterations are completed.

Iteration one is available at http://www.passkeysoft.com/~lee/pg14668.html. In this iteration I did the following: Removed all "style=''" attributes. Added a link to "gutenberg.css" for all styling. Encapsulated the Gutenberg boilerplate in <div class="gutenblurb">...<div>. My style sheet sets that class to "display:none" so I don't ever have to look at it again. Encapsulated the transcribers notes into <div class="fm notes">. Encapsulated the title page presentation into <div class="tp">. Changed book title headers to <h1>, pursuant to rule 4. Removed <p> from non-paragraphs on the title page. Some header normalization throughout the remainder of the file has been performed, but is not yet complete. Encapsulated the copyright information into <div class="copyright">. Made some headway in applying rule no. 1: <p> is reserved for paragraphs. e.g. "Preface" was changed from <p> to <h3>; the dateline at the end of the preface was changed from <p> to <div class="closer">. The blob of text starting at <h2 id="id00032> through the end of <p id="id00035">, which is obviously a table of contents, was converted to a table of contents using <ul>, <ol> and <li> elements, pursuant to rule no. 2. Ersatz paragraphs id00041, id00043, id00045, id00047, id00049, and id00051 were obviously tabular data, so I converted them to tables, pursuant to rule no. 3. As best I could, I restored diacritical markings to the words contained in these 6 tables. Letters containing diacritical marks can be represented in a number of ways in unicode. I chose to represent them as ASCII characters + combining diacritical marks because some of the characters had no other representation in unicode and I wanted to use a consistent code page. If the combining diacritical marks are ignored, the collation order of the words will be preserved (for whatever that's worth). The drawback to this approach is that I don't know how widespread support for combining diacritical marks is on HTML user agents. <p id="id00062">[Illustration:...]</p> was changed to <div id="id00062" class="illustration" title="..."><img src="" alt="..."/>. When an image cannot be located (which is always for this file), the alternate text will be displayed; when an image becomes available, the alternate text will not be displayed. This ought to be a rule, but probably not in the top 20. Some further illustrations have been converted, but not yet all. The vocabulary word list at the beginning of each chapter (e.g. ersatz paragraphs id00065, id00066, id00067, id00068) is problematic. Technically this is a list, but HTML has really bad support for floating columns. For the time being I have implemented them as tables, but I don't feel good about it. Suggestions are solicited. Words in the word list are obviously divided on syllables; the apostrophe in those words is a replacement for an acute accent indicating stress. I replaced those apostrophes with the unicode acute accent symbol (´). In the reading exercises, the paragraphs are numbered. I was tempted to place each paragraph as an item in an ordered list for automatic numbering, but decided not to. Opinions are welcomed. Other changes were made, relating to handwriting and correspondence, but I'm running out of time. More to follow in the next installment.

PG has a history of animosity to scholars and scholarly tastes, which I deplore.

I think the animosity is more directed to the idea that public domain books should be coded in painstaking detail -- and then locked up in a digital locker somewhere where no one can actually read or use them.

And they want TEI and not some silly home-brewed HTML.

And then they claim their semantic analysis entitles what they just did to new copyright status. And then they lock that TEI up in digital vaults that only other academics in their same consortium can even look at. PG should become concerned when people say they are doing semantic analysis, and are not simply typesetting a book.

No. It's none of PG's business how other groups handle their transcribing. Tearing other people down doesn't get anything done. If people say they are doing semantic analysis, and decide to lock up, there's no point in us caring one way or the other; we may as well treat it as if it had never been done in the first place. If they are doing semantic analysis and are making it available to the world, why on Earth would we want be jerks and cop an attitude because other people doing semantic analysis are doing things we don't approve of?

I disagree. To me this is just another way to engage in copyfraud, just like all the dimestore editions which include an introductory chapter of "scholarly analysis" from Prof. Joe Schmoe and then slap a new copyright notice back on the "derivative" work. PG needs to make sure that what they publish represents "typesetting" and NOT "semantic analysis." PG should speak out strongly against all people and all communities which engage in copyfraud -- including much of the TEI "scholarly" community. PG should speak out strongly for returning copyright back to the sensible origins that the founding fathers intended -- namely to allow that an author could make a reasonable profit off his own efforts during his own lifetime -- and *not* the current Mickey Mouse copyright laws which are effectively allowing printing corporations to hold a monopoly in perpetuity. One of rights of the purchaser of a work -- at the time they made that purchase -- was the reasonable expectation that copy prohibitions on that purchased work would expire in a reasonable amount of time -- and not be subject to constantly increasing durations.

Those two sentences have no connection. You do not further the cause of the public domain by attacking certain derivative works that some people find useful. If people need semantically analyzed works, then they should make semantically analyzed works.

Nonsense. PG has a long history of running into problems with people who claim to have made a useful contribution to a "derivative work" when in fact all they are trying to do is bung up the works to keep copies from being made. The academic community is not more immune to this behavior than anyone else. The keyword you use above is "useful." Is this "academic work" useful? Nope. It's just another excuse to find another way to lock up books which are out of copyright so that the public cannot in practice use that which is already theirs -- namely everything that has risen to the public domain. And you cannot use the book in the university's library anymore either -- because they dispose of the physical copies once they have digitized them.

Lee, I don't remember seeing your numbered rules. Where are they? They all look right to me so far. Do you want a blog id on readingroo.ms? This would be easier to follow if it accumulate somewhere. Otherwise I'll start a new category and copy them over. Don On Wed, Oct 10, 2012 at 3:20 PM, Lee Passey <lee@passkeysoft.com> wrote:

On 10/10/2012 9:09 AM, Lee Passey wrote:

[snip]

This file obviously needs a lot of work, and probably is more deserving

...

of attention than many of the recent obscure and esoteric works for which raw page scans are adequate to serve the academic community. I'll try to fix it as best I can, but this will probably take me several weeks. I'll post iterations on my web server as I go along, and provide comments here as iterations are completed.

Iteration one is available at http://www.passkeysoft.com/~** lee/pg14668.html <http://www.passkeysoft.com/~lee/pg14668.html>.

In this iteration I did the following:

Removed all "style=''" attributes. Added a link to "gutenberg.css" for all styling.

Encapsulated the Gutenberg boilerplate in <div class="gutenblurb">...<div>. My style sheet sets that class to "display:none" so I don't ever have to look at it again.

Encapsulated the transcribers notes into <div class="fm notes">.

Encapsulated the title page presentation into <div class="tp">. Changed book title headers to <h1>, pursuant to rule 4. Removed <p> from non-paragraphs on the title page. Some header normalization throughout the remainder of the file has been performed, but is not yet complete.

Encapsulated the copyright information into <div class="copyright">.

Made some headway in applying rule no. 1: <p> is reserved for paragraphs. e.g. "Preface" was changed from <p> to <h3>; the dateline at the end of the preface was changed from <p> to <div class="closer">.

The blob of text starting at <h2 id="id00032> through the end of <p id="id00035">, which is obviously a table of contents, was converted to a table of contents using <ul>, <ol> and <li> elements, pursuant to rule no. 2.

Ersatz paragraphs id00041, id00043, id00045, id00047, id00049, and id00051 were obviously tabular data, so I converted them to tables, pursuant to rule no. 3.

As best I could, I restored diacritical markings to the words contained in these 6 tables. Letters containing diacritical marks can be represented in a number of ways in unicode. I chose to represent them as ASCII characters + combining diacritical marks because some of the characters had no other representation in unicode and I wanted to use a consistent code page. If the combining diacritical marks are ignored, the collation order of the words will be preserved (for whatever that's worth). The drawback to this approach is that I don't know how widespread support for combining diacritical marks is on HTML user agents.

<p id="id00062">[Illustration:...**]</p> was changed to <div id="id00062" class="illustration" title="..."><img src="" alt="..."/>. When an image cannot be located (which is always for this file), the alternate text will be displayed; when an image becomes available, the alternate text will not be displayed. This ought to be a rule, but probably not in the top 20. Some further illustrations have been converted, but not yet all.

The vocabulary word list at the beginning of each chapter (e.g. ersatz paragraphs id00065, id00066, id00067, id00068) is problematic. Technically this is a list, but HTML has really bad support for floating columns. For the time being I have implemented them as tables, but I don't feel good about it. Suggestions are solicited.

Words in the word list are obviously divided on syllables; the apostrophe in those words is a replacement for an acute accent indicating stress. I replaced those apostrophes with the unicode acute accent symbol (´).

In the reading exercises, the paragraphs are numbered. I was tempted to place each paragraph as an item in an ordered list for automatic numbering, but decided not to. Opinions are welcomed.

Other changes were made, relating to handwriting and correspondence, but I'm running out of time. More to follow in the next installment.

______________________________**_________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/**mailman/listinfo/gutvol-d<http://lists.pglaf.org/mailman/listinfo/gutvol-d>

Iteration one is available at http://www.passkeysoft.com/~lee/pg14668.html.

Things you are doing which make people (and products) unhappy: Inclusion of javascript in a book. Use of italic for body text. Combining diacriticals seems to seriously hose a lot of products.

Italics are used only once in the file, and then only for a single word.

Combining diacriticals are not well supported among user agents, especially

Well, call it what you like but the "Dear Santa" stuff -- whatever you want to call it -- drives real readers nuts. the less capable ones like the Kindle. Not sure a Kindle even knows what a combining diacritical is. However, they hose many more "capable" products too. Haven't seen any product anywhere which supports them well. Do you know of one?

On Wed, October 17, 2012 10:43 pm, James Adcock wrote:

...

Italics are used only once in the file, and then only for a single word.

Well, call it what you like but the "Dear Santa" stuff -- whatever you want to call it -- drives real readers nuts.

Don't blame me, blame McGuffy. Back when I was in elementary school one of the things we were taught was how to do cursive writing (I understand there is a movement in education to quit teaching this subject). This is also one of the subjects which is attempted to be taught in the McGuffy reader. The "Dear Santa" section you refer to is presented as an exercise in orthography; students are presented with a letter in cursive, ostensibly written to Santa Clause, which they are instructed to imitate. The cursive nature of this section is problematic. Presumably, the /best/ solution would be to include an image of the letter, as was done in the Microsoft word and PDF versions of the document at Project Gutenberg, and this is an alternative I may return to. In the interim, what I did was to transcribe the letter, then mark it with <div class="write"> to indicate that it should be rendered as handwriting. There are other "slate exercises" in the book that I have not yet marked up, and I will probably treat them in the same way. The associated CSS file specifies the font to use (cursive), which you are apparently unhappy with. Just download the file, and change your standard gutenberg.css file to use the font that /you/ are most comfortable with. Or don't use a CSS file at all, and get a less appealing version, which is still superior to that provide by Project Gutenberg. (You can do this online with IE and Firefox by selecting "no styles" in your browser options). The whole point of CSS standard usage is that you can obtain a CSS file that most closely represents your tastes, and those choices will be reflected in all files.

...

Combining diacriticals are not well supported among user agents, especially the less capable ones like the Kindle.

Not sure a Kindle even knows what a combining diacritical is. However, they hose many more "capable" products too. Haven't seen any product anywhere which supports them well. Do you know of one?

I used the free Microsoft Visual Web Developer (http://www.microsoft.com/visualstudio/eng/downloads#d-express-windows-deskto...) to edit this file, and it handled the combining diacriticals just fine. IE 8 and Firefox 16 recognize and display the marks, but don't back up quite far enough to be crystal clear. I haven't yet created the ePub version, so I can't comment yet on how they are handled in ADE or CoolReader. The main problem is what to use as alternatives. About 3/4 of the combined characters have single value code points scattered throughout the Unicode charts. But the remaining 1/4 of the characters have no single value alternatives; combining diacriticals is the /only/ way to represent them. By using combining diacriticals I can represent /all/ of the characters used by the book, and I limit myself to a single Unicode range (0300-036F). By using combining diacriticals I have preserved the content of the original book, and if there are devices that do not support this portion of the Unicode standard it should be trivial to run a transformation on the file to convert those characters to something that the device in question supports. Life is full of trade-offs.

On 10/19/2012 6:17 AM, James Adcock wrote:

This is stupid.

Ahh, I see you are a graduate of the BowerBird/Perathoner school of rhetoric. Do go on...

The job of the typesetter is to make intelligent typographical decisions -- including understanding how the limitations of the media he is targeting is going to affect those choices.

Perhaps, but it begs the question, "who is the typesetter?" Back in ancient times, books were read from flimsy sheets of processed wood pulp, mass-produced by applying dyes from large machines called "printing presses." Back in those days, a quasi-priesthood developed called "typesetters." Like their forerunners, the masons, this society spent years developing the arcane knowledge of how best to represent words on pages. These "typesetters" existed because setting up a printing press was an expensive proposition, and once the presses started rolling you would have thousands of copies before they would stop again. If you were going to successfully sell the book, it was important that the layout and typography would appeal, if not to the majority of readers, at least to the plurality. Printing a book to appeal to the tastes of a single reader was the ultimate vanity publishing, and simply impractical. I have noticed a tendency among human beings--certainly not universal, but common--to become dogmatic about their beliefs. Eventually, the practical, empirical lessons about typesetting best practices, learned from observation and empirical evidence, became articles of faith: "There is but one way to layout a book, and it is /my/ way! If you, lowly reader, don't like the way your book looks you are a sinner, and need to return to values of the masses, which /I/, of course, represent!" This is, of course, a bit of an exaggeration (but only a bit). Most professional typesetters have a practical understanding of the competing needs of media and audience (and business) and on the whole produce generally acceptable products. It's typically only the wannabe typesetters who are dogmatic about the rules. The advent of the transformative power of computers truly upset that applecart. And in a triumph of close-mindedness, it is amazing that so many people have not only failed to grasp the extent of the upset, they deny that the apple cart as tilted at all. Suddenly, the ultimate vanity publishing was no longer impractical, it became common (see, e.g. the much discussed Huck Finn, and just about any other work produced by David Widger). Yet these vanity publishers still clung to the 19th century typesetting dogma: "If it looks good to me, it will look good to everyone! and anyone who does not agree is just an outlier and of no consequence!" These vanity publishers quickly learned that computers have lowered the cost of entry which had previously barred them from publishing, but they still don't understand the algorithmic power of the computer, which would allow them to segregate the layout of a book from the structure of a book (or perhaps they are simply to committed to their own layout dogma to care).

The idea that the end customer is going to edit your file simply doesn't work.

True. Thankfully, I don't believe in that idea. I believe that it is possible to create an e-book file which has embedded within it all the hooks necessary to allow it to be /programmatically/ typeset according to a wide range of needs and tastes. I clearly don't have all the answers yet, indeed I may have very few of them, but I'm relying on certain clear-headed individuals like Don Kretz, Carlo Traverso, Jeroen Hellingman and even Joshua Hutchinson, all of whose opinions I respect even when I disagree, to help me find those answers. I am not an adherent of the typesetters sect. I don't pretend to be, I don't want to be, and I'm probably not even qualified to be. I'm simply trying to build a framework where a real typesetter can come along an say, "add this style here, this style there, and this style over there, and you will have an e-book that satisfies your personal esthetic. Whether an end user is going to edit a file depends, I guess, on just how sophisticated an end user he his. I don't expect, or even want, an end user to edit the framework file. Tweaking a standard CSS file is fine for the sophisticated user. What I really would hope for is for computer literate members of the Society of Typesetters to come along and build a significant number of CSS files all of which apply layout to the same elements, but in different ways. The end user's job is then to simply say, "I like Adcock formatting, or Widger formatting, or some other, better formatting, so I will get one of the corresponding CSS files and put it next to the downloaded file; I will then see things how I like." A default CSS file can be provided for people who aren't picky, and those who like the current VT-52 format can skip the formatting altogether. The ePub format is a bit challenging in this regard as most ePub user agents do not let you replace a CSS file included in the zip file (although many, not including ADE, let you disable internal styles; Cool Reader lets you not only disable the pubisher's CSS it also allows you to specify a user CSS file that overrides the internal CSS). I currently have a prototype web-based ePub creator running at readingroo.ms. That plain-jane user interface allows you to specify a Gutenberg e-text number, and then to upload your own preferred CSS file. The resulting ePub will then conform to your own preferences as expressed in /your/ CSS file. /That/ is what my idea is.

If you want to get people to buy into your view of how the world ought to be coded -- at least make something that looks half attractive and is readable.

You forgot to add the words "to me" at the end of your sentence. Fortunately, I created something that looks attractive /to me/ and which /I/ find highly readable. And because everyone in the world likes what I like, the current state of the file is obviously in its highest and best state. I see no reason to create a file that appeals to /you/, because my values represent the world at large, and if you don't find them appealing, then you are obviously living in a state of sin, and you should repent and accept my dogma. (Is there an emoticon for "tongue-in-cheek"?) You know those references above to "vanity publishers" who are blindly committed to their own dogma? Just so we're clear, I want you to know that I include you, Mr. Adcock, in that group.

Some of your facts are ok, but I think you might put them together a little more constructively. There's a legitimate argument that, if we hope many people are going to be involved proofing a text, the instructions need to be clear, simple, and few; and they should be matching the image, plus as little markup as possible to capture the essential semantics (to be defined.) Few would expect DP proofers to be applying complex formal markup like TEI, ReST, or latex. ZML is the only markup that anyone has suggested might have a chance, but it has other issues. So positive suggestions, and especially working examples, should be welcome. --------------------------- On the other hand, once the handwork is done, a version of the text that is exhaustively constructed with all the essential semantics (to be defined) clearly identified and located would, it is supposed, make it possible to write mapping modules to generate formatted texts that convey the structure and meaning of texts clearly and attractively. We have few examples of such a "master text" that has proven capable of providing the source for clear and attractive ebooks in various formats. --------------------------- I think no one is advocating any form of text that serves both purposes simultaneously, so that apparently leaves another step in the process - converting proofed text into some master text. Not many have offered to discuss how this would be done. Which leaves the suspicion that some might expect the DP "post-proofer" volunteers to fill this role. That seems an unlikely scenario to me. But however it is accomplished, it would probably (it seems to me) to depend heavily on the path provided by the essential semantics (to be defined.) -------------------------- I mentioned the McGuffey text as a possible test case for a discussion with real examples of alternatives. I thank Lee Passey for picking up the cue. I find it tedious to endure advocates who only discuss their own ideas, so this will have at least two of us for a while, anyway. I'm currently using the McGuffey text, and learning from how Lee has applied XHTML as markup, presumably as an example of text format #2 above; and I'm building a list of candidates for "essential semantics". It will be interesting to me to see how Lee views his construction from the same perspective. In the meantime, I'm using the resources of the WordPress installation on readingroo.ms see how much of the semantic content of McGuffey is available (as bowerbird would like it to be) inherently in the plain text, and how much needs to be added, by constructing views that allow different versions of text to be viewed in parallel, and edited. The host has the essential capabilities of a linux server, including utilities for I think all the formats commonly mentioned (except ZML), so if anyone thinks their preference would be interesting and helpful, I think that could be pretty easily accommodated. But two of us is enough for me to start. On Sat, Oct 20, 2012 at 12:52 PM, James Adcock <jimad@msn.com> wrote:

All that has happened is that Lee has once-again confirmed that there are two camps of belief among readers of this forum.

One group believes that they can simply do semantic markup "of everything" and then someone else can apply the formatting decisions later and everything will just "magically work."

The other group doesn't believe this works, that on the contrary someone needs to make good "engineering judgment" decisions on formatting now rather than expecting someone else to do it later, and that in general there is not a limited set of semantic markups that can be uniformly applied such that the problem can be well-divided and the "engineering judgment" decisions about formatting can be made later.

This second group says: "Hey, if the first group cannot even show good 'engineering judgment' about displaying their own semantic markup in an attractive and sensible way using ONE set of formatting decisions -- namely their own -- then how likely is it that their semantic markup is going to prove to be useful to someone else implementing a different set of formatting decisions at some latter date?"

_______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d

On 10/21/2012 07:44 PM, Lee Passey wrote:

So yes, I want to define a uniform set of semantic inflection (class attributes) that can be applied to HTML files that will allow them to be used as a master file [...]

You want to specify a set of PG-proprietary extensions to HTML that mimic the semantic tags of TEI. How is the shoehorning of PG texts into Yet Another Proprietary Markup Language going to help the spread of PG ebooks? -- Marcello Perathoner webmaster@gutenberg.org

Let's take the McGuffey book as an example to review these points and provide an example for doing them properly. On Sun, Oct 21, 2012 at 10:02 PM, James Adcock <jimad@msn.com> wrote:

Let’s back up a step, and see if there is some areas we can agree on, namely there are a variety of areas that pretty much every book has which are “simple as dirt” yet the books PG posts are still not handling these “simple everyday items” in a robust and reader-enjoyable manner.****

** **

**1) **Paragraphs. PG is still serving books, frequently, like all the time, with broken paragraph formatting.

I can think of cases I've seen where paragraphs have not been handled properly; but I have no idea if they are the same as yours. As it stands, your assertion about broken paragraphs wouldn't be helpful for me as a text provider because I probably think I have marked all my paragraphs properly; you may disagree and you may be right; but there's no information I can use to fix what's wrong.

****

**2) **TOC. Hard to implement in HTML and to get it to work “right” on the major platforms.

I don't understand why we are manually constructing tables of contents in the first place. All the chapters need to be located; all the chapter headings need to be identified and positioned; and all it takes is some software to create a guaranteed accurate TOC from the text.

****

**3) **Blockquotes. Similar issues to paragraphs.

Same comment as paragraphs. A problem I see is that some things are marked as block quotes that aren't block quotes, simply because they are formatted like block quotes.

****

4) Illustrations. Hard to get right. Will work on some platforms and not others. Some submitted illustrations don’t work on some platforms.

Agreed, and this one will need discussion.

**5) **Covers. Every book should have them, and they ought to be easy to implement.

Shouldn't they be easy to auto-generate from metadata?

****

**6) **Title page. Again, pretty much every book should have them, and they should be easy to implement. The title page info should not have to also be submitted redundantly 12 other places.

I don't understand the "12 other places" comment.

****

**7) **PG Boilerplate. Should be implemented in an attractive and non-obtrusive manner, which does not scare off the readers, nor make PG look like idiots, and should be written in such a manner as to convince most readers that the boilerplate is actually a good thing to their advantage.

Agreed. But Greg needs to agree and commit to do something about it.

****

**8) **Statement that this book is “risen to the public domain” and what that means. The implication that PG is giving away this book is false, because the book is not PG’s to give away. Rather, the book belongs to the public in the first place.

Probably true but I'm not sure who would disagree, or what the significance is.

****

**9) **A clean, fun, positive-feedback way to submit books to PG, such that people WANT to submit books to PG, rather than do so grudgingly.

Yes.

****

**10) **A clean, fun, easy, robust way to preview and “smooth read” one’s work and formatting and “conformance to standards” testing before submitting it to PG.****

**

Yes.

**

So what I claim we need is a simple method, using universally available and well-supported tools, to do these kinds of “dirt simple all the time” things, and do them in a way that actually works on BOTH the submitters side, and PG’s side of things. Such support need not be implemented in terms of this, that or the other language. Nor does it matter much whether it is implemented client side or server side or a mix thereof.****

** **

**

Agreed. That's why I want to challenge any proposers to provide at least a prototype of what is being proposed, in the form of examples collected in one place so they can be remembered and compared. A list server like this is a very poor medium for refining and comparing anything. It would also help to avoid reactions that categorize proposals as categorically bad and make general statements about the proposer's character or intelligence. Or fail to provide a better alternative, with real examples we can compare with each other. Yes, bowerbird, I know you're providing the last item. Not so much on the others.

**

** **

_______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d

Re: 1) Paragraphs. PG is still serving books, frequently, like all the time, with broken paragraph formatting. Explain "broken paragraph formatting". Give examples. 5) Covers. Every book should have them, and they ought to be easy to implement. They're easy to create, but it's up to the book's submitter to create/provide them. (Not sure if custom covers have been discussed in this forum, but I think they have.) Don't expect PG to create them for you. I've done a number of custom covers over the past few months, e.g. 41020, 41021, 41022. I keep it simple--a solid color background, with title and author, and if necessary, volume information. 6) Title page. Again, pretty much every book should have them, and they should be easy to implement. The title page info should not have to also be submitted redundantly 12 other places. I'm baffled as to what this means. Every source book has one, or it probably couldn't be copyright-cleared. As a WWer, I can safely say that submissions without all of a title page's info are rare, and usually from beginners. As to submitting info in 12 other places--rubbish. Info has to be entered only once, in the copyright clearance submission form. That info is carried over to when the finished book is uploaded for WWing, at which time the uploader can make corrections to the info. The only time I have to enter info again is in the metadata section of one of my RST-based projects (e.g. 41020, 41021, 41022). 9) A clean, fun, positive-feedback way to submit books to PG, such that people WANT to submit books to PG, rather than do so grudgingly. A brass band, maybe? 10) A clean, fun, easy, robust way to preview and "smooth read" one's work and formatting and "conformance to standards" testing before submitting it to PG. Another baffler. How (and why) is PG supposed to provide smooth-read facilities to submitters? Independent producers are expected to proof/SR their submissions, and make sure they meet PG's standards, before uploading. (Those standards are well documented, but whether you like them or not, or are willing to meet them or not, is up to you.) I've SRed every one of my 1200+ submissions (just over 1100 to PG-US, over 100 to PG-Canada), and enjoyed, or was interested by, almost all of them. (I did learn early in my PG activity that I'm only a so-so on-screen SRer, so I do all my SRing from a paper print-out, away from my computer.) Al -----Original Message----- From: gutvol-d-bounces@lists.pglaf.org [mailto:gutvol-d-bounces@lists.pglaf.org] On Behalf Of James Adcock Sent: Sunday, October 21, 2012 10:02 PM To: 'Project Gutenberg Volunteer Discussion' Subject: Re: [gutvol-d] Basic simple test case. Let's back up a step, and see if there is some areas we can agree on, namely there are a variety of areas that pretty much every book has which are "simple as dirt" yet the books PG posts are still not handling these "simple everyday items" in a robust and reader-enjoyable manner. 1) Paragraphs. PG is still serving books, frequently, like all the time, with broken paragraph formatting. 2) TOC. Hard to implement in HTML and to get it to work "right" on the major platforms. 3) Blockquotes. Similar issues to paragraphs. 4) Illustrations. Hard to get right. Will work on some platforms and not others. Some submitted illustrations don't work on some platforms. 5) Covers. Every book should have them, and they ought to be easy to implement. 6) Title page. Again, pretty much every book should have them, and they should be easy to implement. The title page info should not have to also be submitted redundantly 12 other places. 7) PG Boilerplate. Should be implemented in an attractive and non-obtrusive manner, which does not scare off the readers, nor make PG look like idiots, and should be written in such a manner as to convince most readers that the boilerplate is actually a good thing to their advantage. 8) Statement that this book is "risen to the public domain" and what that means. The implication that PG is giving away this book is false, because the book is not PG's to give away. Rather, the book belongs to the public in the first place. 9) A clean, fun, positive-feedback way to submit books to PG, such that people WANT to submit books to PG, rather than do so grudgingly. 10) A clean, fun, easy, robust way to preview and "smooth read" one's work and formatting and "conformance to standards" testing before submitting it to PG. So what I claim we need is a simple method, using universally available and well-supported tools, to do these kinds of "dirt simple all the time" things, and do them in a way that actually works on BOTH the submitters side, and PG's side of things. Such support need not be implemented in terms of this, that or the other language. Nor does it matter much whether it is implemented client side or server side or a mix thereof.

To answer the question about custom cover creation, I use Irfanview. I create a new empty image (under the Image menu), and choose a background color. I then select the area for the text to be inserted, and use Irfanview's Edit, Insert Text into Selection function (Ctrl-T) to add the text, using whichever font/color/size/alignment I choose. Any graphics software should be able to do much the same.

-----Original Message----- From: gutvol-d-bounces@lists.pglaf.org [mailto:gutvol-d-bounces@lists.pglaf.org] On Behalf Of James Adcock Sent: Monday, October 22, 2012 7:26 AM To: 'Project Gutenberg Volunteer Discussion' Subject: Re: [gutvol-d] Basic simple test case.

...

Don't expect PG to create them for you.

Well, PG does create them for me -- it drops the "Big Blue PDA of Death" in there for me -- it would be better if it left off covers entirely, or auto-generated a simple cover with title and author on it.

...

I've done a number of custom covers over the past few months, e.g. 41020, 41021, 41022. I keep it simple--a solid color background, with title and author, and if necessary, volume information.

What tool, if any, do you use to generate these?

...

As to submitting info in 12 other places--rubbish. Info has to be entered only once, in the copyright clearance submission form. That info is carried over to when the finished book is uploaded for WWing, at which time the uploader can make corrections to the info.

Take a look at what epubmaker does, for instance.

...

9) A clean, fun, positive-feedback way to submit books to PG, such that people WANT to submit books to PG, rather than do so grudgingly. A brass band, maybe?

There is something seriously wrong when it is easier to submit a book commercially to Amazon than donate one's work to PG.

...

10) A clean, fun, easy, robust way to preview and "smooth read" one's work and formatting and "conformance to standards" testing before submitting it to PG. How (and why) is PG supposed to provide smooth-read facilities to submitters?

Again, I have tools that I can use on my end that work pretty well for me in this regard, but then PG won't allow me to use these tools, and instead requires me to down-grade my efforts to their "standards." The "guess what will happen" aspect of epubmaker is a particular pain.

...

Independent producers are expected to proof/SR their submissions, and make sure they meet PG's standards, before uploading. (Those standards are well documented, but whether you like them or not, or are willing to meet them or not, is up to you.)

The "World of Al" is one where the high priests preach an unchanging world with an unchanging religion where nothing can change, and nothing can get better. It must always remain the same. Certainly "well documented" is total BS as many conversations here have discussed. One *might* be able to find a particular piece of documentation somewhere on some PG or DP server if one knows about it to begin with, but one will find that the documentation(s) contradict each other everywhere. And unless you know in great detail what you are looking for to begin with, you will never find the documentation.

_______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol> -d

Why? Amazon doesn't care. Amazon makes everything publisher's problem, where PG wants to take responsibility for the works it does.

This statement would imply you haven't tried reading PG books on e-book reader devices.

On 10/21/2012 06:38 PM, Lee Passey wrote:

I believe that a text can be marked up using HTML in such a way that, 1. it can be viewed in any HTML user agent with an adequate, even if not perfect, presentation; 2. it can be combined with one of a number of external CSS files to create a presentation good enough to satisfy any individual reader; and 3. it can be programmatically transformed into any other non-HTML based format (e.g. PDF, RTF).

3. can only be achieved if you duct-tape sematic extensions onto HTML. Those semantic extension would be PG's properietary ones. Nobody else in the world would use them. You admit yourself that transformation comes cheap, so what makes you think that a proprietary markup used only at PG is better than an open markup used by the whole academic world like TEI? The learning curve toward your proprietary extension would be just as steep as toward TEI. Minus the extensive documentation and lots of use cases and an active discussion list stuffed with the world's best professionals, which TEI has and you have not.

But so far, no one has offered any evidence that I am wrong, so I guess I will go on being a "voice crying in the wilderness."

The lack of falsification doesn't confirm a hypothesis. Some evidence would confirm it. So how about showing us some?

Thankfully, this criticism does not apply to me, because the example I provided of McGuffy's reader is presented in an immaculate, pleasant, elegant and sensible way. It is inconceivable that anyone could not view that presentation as the epitome of fine markup.

For all the sensational work you did with it, you didn't even manage to spell "McGuffey" correctly. But I'm sure your markup is awesome! -- Marcello Perathoner webmaster@gutenberg.org

On 10/19/2012 7:47 AM, Scott Olson wrote:

For what it's worth, my browser renders the "Dear Santa" letter in Italic Comic Sans. :-/

The rule in the default CSS file is: .write { font-family: cursive; font-style: italic } This rule will query your operating system for the default cursive font. On MS Windows systems the default cursive font is Comic Sans MS. For information on how to change default fonts on Windows on a per-user basis see: http://www.shallowsky.com/blog/tech/web/firefox-cursive-fantasy.html. If you are a sophisticated user you can download the .html file and gutenberg.css, and change the above line to whatever floats your boat. To make it non-italic, remove the "font-style:italic" clause. Instead of "font-family:cursive" change it to one of the cursive fonts you have installed on your system. (Note: These are edits to the .css file, not the .html file. Don't touch the .html file unless you're certain you know what you're doing.) I'm pretty sure there is a way to change the default font families on MSWindows in a global fashion, and I'm sure there is a way to set the default font families on all other desktop OS's as well. But I'm not interested enough in the problem to do the necessary research. Perhaps someone else here is. I'm not going to dictate your choice of font, as the net result would probably be pissing off someone else (Mr. Adcock seems to get pissed off easily about trivial matters). I want to give you the tools to easily make the decision yourself.

On 10/10/2012 4:20 PM, Lee Passey wrote:

On 10/10/2012 9:09 AM, Lee Passey wrote:

[snip]

...

This file obviously needs a lot of work, and probably is more deserving of attention than many of the recent obscure and esoteric works for which raw page scans are adequate to serve the academic community. I'll try to fix it as best I can, but this will probably take me several weeks. I'll post iterations on my web server as I go along, and provide comments here as iterations are completed.

Iteration one is available at http://www.passkeysoft.com/~lee/pg14668.html.

I spent the evening doing some servlet programming on readingroo.ms. In case anyone cares, the most recent version of my reworking of the McGuffey reader is now found at http://readingroo.ms:8080/PG2ePub/cvsget/14668/14668.html. If you want an ePub version, derived from this file, you can get it by going to http://readingroo.ms:8080/PG2ePub/GetEPub.jsp and entering the eText number 14668.

On 10/25/2012 8:38 AM, James Adcock wrote:

...

If you want an ePub version, derived from this file, you can get it by going to http://readingroo.ms:8080/PG2ePub/GetEPub.jsp and entering the eText number 14668.

Suggest you check your generated epub against: validator.idpf.org

Why? 1. The software is a work in progress, and obviously still error-prone; 2. ePub depends almost exclusively on the correctness of the underlying HTML, and will likely always contain errors; 3. epubcheck, run locally is a more effective and efficient way to validate ePubs; and 4. most errors detected by the validator are harmless schema errors. Feel free to renew your suggestion this time next year, at which time #1 may be resolved.