keith said:
I honestly, thought that you were serious about creating a useful tool, but I must sadly admit you are not
what? you cannot see how a tool that turns a plain-text file into .html and .epub and .mobi would be _useful_ to p.g., d.p., and the world at large? seriously? are you daft? because i can assure you that _some_ people have no trouble at all seeing it. no trouble. at all. meanwhile, p.g. (as run by marcello) stumbles along trying to make r.s.t. (1) work, and (2) acceptable to d.p.
It is very sad. A very poor joke. It, also shows that you have no real interest in helping the PG community in any way.
the p.g. community? you mean the people who insulted me for years on this listserve, and attacked me viciously in a wolf-pack? _that_ community? including the marcello, who put up a _website_ trying to spite me? (little did he know how badly all that would backfire when he had to eat his words and adopt light markup, _proving_ i was right! ironic that he saved all my i-told-you-so's. next he'll probably sic the paparazzi on me.) in case there is any doubt left in your mind, let me assure you that i have zero interest in "helping" _that_ particular community... i'm quite sure there are some good people here, but that vicious attack-pack sure shut them up...
Nor due do you have any respect for the PG cause!
i paid my due respect to p.g. for _many_ years, and i continue to serve the cause of electronic-books, and i have zero need for your assessment of that... so, are we clear on _that_ too? but cheer up, keith! nothing to be sad about! :+) -bowerbird
Hi BB, it is useless. I could quote your own words, recently posted here to prove that I am not daft at all. I am aware or the peeves on the list. But, that has nothing to do what ever is going on right now! Or, is it? Rhetorical … ciao Keith Am 23.02.2011 um 11:07 schrieb Bowerbird@aol.com:
keith said:
I honestly, thought that you were serious about creating a useful tool, but I must sadly admit you are not
what? you cannot see how a tool that turns a plain-text file into .html and .epub and .mobi would be _useful_ to p.g., d.p., and the world at large?
seriously?
are you daft?
because i can assure you that _some_ people have no trouble at all seeing it.
no trouble. at all.
meanwhile, p.g. (as run by marcello) stumbles along trying to make r.s.t. (1) work, and (2) acceptable to d.p.
It is very sad. A very poor joke. It, also shows that you have no real interest in helping the PG community in any way.
the p.g. community? you mean the people who insulted me for years on this listserve, and attacked me viciously in a wolf-pack? _that_ community? including the marcello, who put up a _website_ trying to spite me?
(little did he know how badly all that would backfire when he had to eat his words and adopt light markup, _proving_ i was right! ironic that he saved all my i-told-you-so's. next he'll probably sic the paparazzi on me.)
in case there is any doubt left in your mind, let me assure you that i have zero interest in "helping" _that_ particular community...
i'm quite sure there are some good people here, but that vicious attack-pack sure shut them up...
Nor due do you have any respect for the PG cause!
i paid my due respect to p.g. for _many_ years, and i continue to serve the cause of electronic-books, and i have zero need for your assessment of that...
so, are we clear on _that_ too?
but cheer up, keith! nothing to be sad about! :+)
-bowerbird _______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d
On Wed, February 23, 2011 3:07 am, Bowerbird@aol.com wrote: [snip]
meanwhile, p.g. (as run by marcello) stumbles along trying to make r.s.t. (1) work, and (2) acceptable to d.p.
Meanwhile, b.b. stumbles along trying to make z.m.l. (1) work, and (2) acceptable to p.g. I've no doubt that as a markup language ReStructured Text is superior to z.m.l. But any markup language relies on conformance and discipline to be useful, and discipline is what Project Gutenberg is utterly lacking in. My own view is that almost any markup language could satisfy (1), but that no markup language will be able to satisfy (2). [snip]
i paid my due respect to p.g. for _many_ years, and i continue to serve the cause of electronic-books, and i have zero need for your assessment of that...
I'll not discourage those who want to participate in the cult of the Bowerbird, but understand that neither cooperation, collaboration, compromise nor consensus are basic precepts of that faith. If you can accept his infallibility you should have no problems.
Hi everyone, I'm mostly just a passive observer of the incessant flame wars on this list, but I do have a small contribution to make tonight. There are mainly 4 things I'd like to say: 1) Kudos to Bowerbird for being so obstinate, notwithstanding Marcello's funny collection of quotes (my site is intended to focus on quotes, good as well as atrocious ones, so I really appreciated that webpage) 2) Bowerbird, as of right now, has zero creditibility in my eyes. :-o Why? Because you simply *can't* be a proponent of ZML, which is supposed to stand for zero (zero!) markup, while contributing to this mailing list in such an obnoxious manner as Bowerbird does. I mean his unspeakably ugly HTML emails. Breaking news for Bowerbird, in case he hasn't noticed this after all these years: HTML in discussion mailing lists is an abomination, and a symptom of the worst kind of shoddy amateurism, ignorance, arrogance and/or narcissism on the part of the contributor. Everyone on this list submits their posts in the standard, nice plain-text -- but not the most vociferous proponent of *zero* markup! So, Bowerbird, please just stop. If you will choose to continue flooding this list with those obnoxious HTML-formatted emails, my only conclusion from that would be that you don't even know how to disable HTML in your email editor -- and that likely isn't the image that a *programmer* would like to cultivate about themselves. As a European, I was always surprised why there are so many jokes about AOL users on the Internet; AOL has never played a big role here in Europe; but I trust that Bowerbird, through his obstinacy in holding on to obnoxious HTML in discussion emails, doesn't aspire to become *the* explanation for the motive behind all those "AOL user" jokes! :-D It's not only that HTML emails are extremely ugly in all circumstances other than newsletters, ads, or congratulatory messages -- but as AOL produces them, they apparently also *constantly* break the standard threading of messages from this list. Bowerbird, please *stop* and employ some decent email software, for the love of the almighty. It's just horrible to see that, whenever anyone else says something on this list, their messages get properly threaded (on my iPad and iPhone) -- but whenever Bowerbird joins the debate in that execrable HTML style, this completely explodes a thread to a thousand pieces, so that it's hard to see who's talking about what, in reaction to whom. 3) One practical contribution to the current BB converter debate from me. Although I haven't tried Bowerbird's converter yet, I have seen Jane and others mention "curly quotes". As a professional translator I'd just like to make everyone, and especially the software creator Bowerbird, aware of what a tricky subject curly quotes are. Every language has its own conventions for curly quotes. So, in case Bowerbird intends for the converter to be able to handle non-English files, too, he will also need to pay attention to the various shapes of curly quotes in the various languages. For example, curly quotes in English go “like this”, but in many European languages such as German or my native Slovak, curly quotes go „like this“, which is totally different from English. And let's not even mention French texts, where quotation marks have approximately « this shape ». 4) Just like HTML in emails is an abomination, so is PDF when talking about e-books. I completely agree with James Adcock that PDF should be completely disregarded in the discussions of e-books. By all means, there should be *converters* allowing for any PDF file to be easily converted into EPUB, MOBI, etc., and such free and extremely easy-to-use tools already are available (see this great free webpage: www.2epub.com ). I assure everyone that the *only* reason why some people download and/or produce e-books in the PDF format is because they don't know any better -- the main reason is their ignorance, and nothing else, because no one in their sane mind would prefer an unwieldy format imprisoned in a fictitious paper-bound unverse, over a free-flowing format such as EPUB, MOBI, or even HTML; and that applies not only to smartphone screens but also to larger devices such as the iPad. I read e-books on my Kindles (small & DX), the iPad, and the iPhone every single day -- but the only use I've ever found for PDFs is when reading comics which are, basically, nothing but a series of pictures, for which purpose PDF seems ideal. But for *text*-based files? No way! :-p -- Yours, Alex. www.aboq.org [processed by "The Bat!", Version 4.2.10.12]
On Wed, February 23, 2011 11:10 am, a@aboq.org wrote:
ZML, which is supposed to stand for zero (zero!) markup
Not quite correct. BowerBird originally intended for z.m.l. to stand for Zero Markup Language under the impression that the structure of a document could be intuited without explicit markup. I believe he later concluded that /some/ markup was necessary, so he developed some markup rules which he felt a user would not recognize as such unless she or he was specifically looking for them, such as a certain number of blank lines before a single short line was a header at some level, and a whitespace character in column zero means word-wrapping should be suspended. (So far, he has not come up with a way to indicate an indented block.) He apparently believes that this markup is IOTTMCO (Intuitively Obvious To The Most Casual Observer), so the 'z' was modified to stand for Zen; you would understand the markup if only you spent enough time meditating under the Bodhi Tree. I like to think of BowerBird's markup as s.m.l., for Spousal Markup Language: there are rules, but you have to figure them out for yourself, and they are subject to change.
Not correct. We were using most of these techniques before zml. . . . On Wed, 23 Feb 2011, Lee Passey wrote:
On Wed, February 23, 2011 11:10 am, a@aboq.org wrote:
ZML, which is supposed to stand for zero (zero!) markup
Not quite correct.
BowerBird originally intended for z.m.l. to stand for Zero Markup Language under the impression that the structure of a document could be intuited without explicit markup. I believe he later concluded that /some/ markup was necessary, so he developed some markup rules which he felt a user would not recognize as such unless she or he was specifically looking for them, such as a certain number of blank lines before a single short line was a header at some level, and a whitespace character in column zero means word-wrapping should be suspended. (So far, he has not come up with a way to indicate an indented block.)
He apparently believes that this markup is IOTTMCO (Intuitively Obvious To The Most Casual Observer), so the 'z' was modified to stand for Zen; you would understand the markup if only you spent enough time meditating under the Bodhi Tree.
I like to think of BowerBird's markup as s.m.l., for Spousal Markup Language: there are rules, but you have to figure them out for yourself, and they are subject to change.
_______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d
Am 23.02.2011 um 18:03 schrieb Lee Passey: [snio, snip]
My own view is that almost any markup language could satisfy (1), but that no markup language will be able to satisfy (2).
While I will agree pretty much with 1) the problem is 2) The Problem is that d.p simply refuses to have a concise Mark-up langauge. That a Language that has a fixed set of markup commands and also enforce the rules thereof. Instead the they use a system where the contributors have to much freedom. I have offered to develop a tailored language, but also demand that it will be used. I would have help with the tool chain, etc. I would have work closely with them so that they would have exactly what the want. The Philosophy is simple. Develop a "medium" mark-up that can represent the content and structure of a book. Develop conversion routines that output end formats for the readers. You can even add source information so that you have a master format that can aide in site management. You can use RST, XML, HTML-like, etc. The only thing that needs to be done is it has to be designed. That should take no longer than a half of an year. So sure there is tons of books already in the old formats. But, they can be converted, naturally with some loss. The reason that the lighter mark-up is being preferred is simple. It is not convoluted and less possibilities for people to break out! In other words not much to enforce. The restrictions and enforcement is kind of built in. regards Keith.
On Thu, February 24, 2011 1:58 am, Keith J. Schultz wrote:
Am 23.02.2011 um 18:03 schrieb Lee Passey:
[snip, snip]
My own view is that almost any markup language could satisfy (1), but that no markup language will be able to satisfy (2).
While I will agree pretty much with 1) the problem is 2)
The Problem is that d.p simply refuses to have a concise Mark-up language. That a Language that has a fixed set of markup commands and also enforce the rules thereof. Instead the they use a system where the contributors have too much freedom.
I think that the problem lies more at the feet of Project Gutenberg than Distributed Proofreaders, but I think we both agree that the problem is political, not technical. A solution is possible, it is just not acceptable. While BowerBird, Mr. Hutchinson, Mr. Perathoner and I regularly disagree on details, I think we all agree that a single markup system, consistently adhered to, is required for any system to do automatic conversions between formats (I usually agree with Mr. Adcock, and believe that he and I could come to a meeting of the minds rather easily). But until Project Gutenberg is prepared to throw its weight behind some standard, nothing will be accomplished. Because I do not believe that Michael Hart or the other Powers That Be that control Project Gutenberg will ever endorse any particular markup language, fully or in part, discussions about what the ideal markup would be are useless in this venue (except to the extent that they are of academic interest). People who care about electronic preservation of books and their pleasing presentation need to find a different organization to work with to accomplish that goal.
I have offered to develop a tailored language, but also demand that it will be used.
But that demand will never be accepted.
I would have help with the tool chain, etc. I would have work closely with them so that they would have exactly what they want.
The core controllers of Project Gutenberg only want "more". Quantity is everything, quality is nothing. Unless your tool chain can provide "more", it is of no interest to PG.
The Philosophy is simple. Develop a "medium" mark-up that can represent the content and structure of a book. Develop conversion routines that output end formats for the readers.
I agree 100%.
You can even add source information so that you have a master format that can aide in site management.
You can use RST, XML, HTML-like, etc. The only thing that needs to be done is it has to be designed.
From a practical standpoint, HTML is the markup that has won in the marketplace; there's no reason not to adopt HTML as the basis for all markup. While HTML is indisputably the best markup language to adopt, by itself it cannot capture the unique structure of a book. As I believe you are suggesting, for representing books, HTML (or any other markup language) must be further constrained by standardized best practices, and refined by a standard set of semantic classes.
That should take no longer than a half of an year.
No, it should not. There are some things I feel passionate about (<p> should only be used for paragraphs, not for anonymous blocks) and other things I do not (what is the best representation for a thematic break, frequently represented in books by a dingbat?). But I believe that if a core group got together in a spirit of cooperation and compromise this kind of a specification could easily be created. But this kind of specification will never be adopted, endorsed or even promoted by Project Gutenberg, so there is some question as to its value.
So sure there is tons of books already in the old formats. But, they can be converted, naturally with some loss.
But that which is already lost breaks my heart. I believe the effort needs to be restarted with the goal of lossless digital transcriptions. A good digital edition of _Frankenstein_ seems much more important to me than a new edition of _History of the Ojibway Indians from 1830 to 1895_.
The reason that the lighter mark-up is being preferred is simple. It is not convoluted and less possibilities for people to break out! In other words not much to enforce. The restrictions and enforcement is kind of built in.
I have some degree of trepidation with the use of "light" as a modifier for "markup," because I don't understand what it means. Markup that is constrained, in that there is one, and only one, method to mark a specific construct is a good thing. Limiting the markup elements to a specific set of tags is also probably a good thing, although we must be mindful of Herr Einstein's famous recommendation: "things should be made as simple as possible; but no simpler." Discarding structure because there is not a convenient way to represent it is what got Project Gutenberg into this problem in the first place. "Light" in the sense of "easy to overlook" is probably /not/ a good thing. I believe that markup should be explicit, not implicit. How good are you at distinguishing between 4 blank lines and 5 blank lines? Could you easily tell the difference between a line that starts with a tab character, and one that starts with eight spaces? (This distinction is important in creating Makefiles, and yet it still trips me up from time to time). You may not recognize that a line starts with one and only one space character, but you certainly can't confuse the meaning of a line that starts with <center> and ends with </center>. But these arguments (fun arguments, interesting arguments, worthwhile arguments, but arguments nonetheless) are probably best made in some other forum, because whatever the outcome they are irrelevant to Project Gutenberg. OTOH, this is a free and easy forum, so we /could/ have those arguments here so long as we all recognize that any application or implementation of any consensus would have to be applied in an organization other than PG. On a related note, about 7 years ago the community at alt.binary.ebooks confronted the problem of HTML support in e-book hardware and software and came up with a recommendation as to how to mark up books using HTML to be most compatible with hand-held devices. If anyone's interested I could probably drag up that spec and post it here. Cheers, Lee
What is misquoted below is that we will not annoint any author of any markup language as "King" at the expense of all other efforts. As volunteers we encourage people to try their own alternatives. What too many people here want is to have fewer alternatives. As we have always said: "Run it up the flagpole, and if people salute, you have victory." However, WE are not going to declare you victor beforehand, after, it will be obvious simply by the statistics of downloads. . . . Right now, for all the argumentation against them, it would appear that most downloads are .pdf files and go to Kindles...go figure!!! mh On Thu, 24 Feb 2011, Lee Passey wrote:
On Thu, February 24, 2011 1:58 am, Keith J. Schultz wrote:
Am 23.02.2011 um 18:03 schrieb Lee Passey:
[snip, snip]
My own view is that almost any markup language could satisfy (1), but that no markup language will be able to satisfy (2).
While I will agree pretty much with 1) the problem is 2)
The Problem is that d.p simply refuses to have a concise Mark-up language. That a Language that has a fixed set of markup commands and also enforce the rules thereof. Instead the they use a system where the contributors have too much freedom.
I think that the problem lies more at the feet of Project Gutenberg than Distributed Proofreaders, but I think we both agree that the problem is political, not technical. A solution is possible, it is just not acceptable.
While BowerBird, Mr. Hutchinson, Mr. Perathoner and I regularly disagree on details, I think we all agree that a single markup system, consistently adhered to, is required for any system to do automatic conversions between formats (I usually agree with Mr. Adcock, and believe that he and I could come to a meeting of the minds rather easily). But until Project Gutenberg is prepared to throw its weight behind some standard, nothing will be accomplished.
Because I do not believe that Michael Hart or the other Powers That Be that control Project Gutenberg will ever endorse any particular markup language, fully or in part, discussions about what the ideal markup would be are useless in this venue (except to the extent that they are of academic interest). People who care about electronic preservation of books and their pleasing presentation need to find a different organization to work with to accomplish that goal.
I have offered to develop a tailored language, but also demand that it will be used.
But that demand will never be accepted.
I would have help with the tool chain, etc. I would have work closely with them so that they would have exactly what they want.
The core controllers of Project Gutenberg only want "more". Quantity is everything, quality is nothing. Unless your tool chain can provide "more", it is of no interest to PG.
The Philosophy is simple. Develop a "medium" mark-up that can represent the content and structure of a book. Develop conversion routines that output end formats for the readers.
I agree 100%.
You can even add source information so that you have a master format that can aide in site management.
You can use RST, XML, HTML-like, etc. The only thing that needs to be done is it has to be designed.
From a practical standpoint, HTML is the markup that has won in the marketplace; there's no reason not to adopt HTML as the basis for all markup. While HTML is indisputably the best markup language to adopt, by itself it cannot capture the unique structure of a book. As I believe you are suggesting, for representing books, HTML (or any other markup language) must be further constrained by standardized best practices, and refined by a standard set of semantic classes.
That should take no longer than a half of an year.
No, it should not. There are some things I feel passionate about (<p> should only be used for paragraphs, not for anonymous blocks) and other things I do not (what is the best representation for a thematic break, frequently represented in books by a dingbat?). But I believe that if a core group got together in a spirit of cooperation and compromise this kind of a specification could easily be created.
But this kind of specification will never be adopted, endorsed or even promoted by Project Gutenberg, so there is some question as to its value.
So sure there is tons of books already in the old formats. But, they can be converted, naturally with some loss.
But that which is already lost breaks my heart. I believe the effort needs to be restarted with the goal of lossless digital transcriptions. A good digital edition of _Frankenstein_ seems much more important to me than a new edition of _History of the Ojibway Indians from 1830 to 1895_.
The reason that the lighter mark-up is being preferred is simple. It is not convoluted and less possibilities for people to break out! In other words not much to enforce. The restrictions and enforcement is kind of built in.
I have some degree of trepidation with the use of "light" as a modifier for "markup," because I don't understand what it means. Markup that is constrained, in that there is one, and only one, method to mark a specific construct is a good thing. Limiting the markup elements to a specific set of tags is also probably a good thing, although we must be mindful of Herr Einstein's famous recommendation: "things should be made as simple as possible; but no simpler." Discarding structure because there is not a convenient way to represent it is what got Project Gutenberg into this problem in the first place.
"Light" in the sense of "easy to overlook" is probably /not/ a good thing. I believe that markup should be explicit, not implicit. How good are you at distinguishing between 4 blank lines and 5 blank lines? Could you easily tell the difference between a line that starts with a tab character, and one that starts with eight spaces? (This distinction is important in creating Makefiles, and yet it still trips me up from time to time). You may not recognize that a line starts with one and only one space character, but you certainly can't confuse the meaning of a line that starts with <center> and ends with </center>.
But these arguments (fun arguments, interesting arguments, worthwhile arguments, but arguments nonetheless) are probably best made in some other forum, because whatever the outcome they are irrelevant to Project Gutenberg.
OTOH, this is a free and easy forum, so we /could/ have those arguments here so long as we all recognize that any application or implementation of any consensus would have to be applied in an organization other than PG.
On a related note, about 7 years ago the community at alt.binary.ebooks confronted the problem of HTML support in e-book hardware and software and came up with a recommendation as to how to mark up books using HTML to be most compatible with hand-held devices. If anyone's interested I could probably drag up that spec and post it here.
Cheers, Lee
_______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d
Hi, Their is one big aspect which all these years hardly, anyone has been understand or grasp. That is the difference between the inner structure of a master format and the external representation to be used by the ebook makers. A properly, crafted markup language that is not bias to a particular cause can be used in many contexts and still produced the desired output. But, as long as all the "Kings" are ignorant of computer science they will not get very far, because they believe that they can use available tools which were not designed for purpose with a few adjustments. You mention PDFs. Remember when somebody suggested using them almost 20 years ago! regards Keith. Am 24.02.2011 um 23:12 schrieb Michael S. Hart:
What is misquoted below is that we will not annoint any author of any markup language as "King" at the expense of all other efforts.
As volunteers we encourage people to try their own alternatives.
What too many people here want is to have fewer alternatives.
As we have always said:
"Run it up the flagpole, and if people salute, you have victory."
However, WE are not going to declare you victor beforehand, after, it will be obvious simply by the statistics of downloads. . . .
Right now, for all the argumentation against them, it would appear that most downloads are .pdf files and go to Kindles...go figure!!!
mh
You mention PDFs. Remember when somebody suggested using them almost 20 years ago!
Current status of PDFs is that Adobe has adding a "reflow" bit to the standard in recognition that people reading documents on electronic devices NOT paper want to be able to read those documents in sizes appropriate to display on those devices. Problem is that the reflow bit doesn't work with many common PDF layout techniques that overlay text on graphic elements, or on layout techniques that combine graphic elements with textual elements. Now some "PDF" devices ignore the reflow bit and reflow PDF documents "without permission" and other "PDF" devices ignore the reflow bit and never reflow the document even if it would be appropriate to do so on that device.... In summary: given the presence of "reflow" or the need to perform reflow because different display devices can be much larger or much smaller than a standard sheet of paper, the problems of the new improved "PDF" file format essentially become identical to the problems one is always already running into using HTML, MOBI, and EPUB file formats.
Ahh, Jim, I love the way you quote out of context and miss use them to your our purpose. Am 27.02.2011 um 23:47 schrieb Jim Adcock:
You mention PDFs. Remember when somebody suggested using them almost 20 years ago!
Current status of PDFs is that Adobe has adding a "reflow" bit to the standard in recognition that people reading documents on electronic devices NOT paper want to be able to read those documents in sizes appropriate to display on those devices. Problem is that the reflow bit doesn't work with many common PDF layout techniques that overlay text on graphic elements, or on layout techniques that combine graphic elements with textual elements. Now some "PDF" devices ignore the reflow bit and reflow PDF documents "without permission" and other "PDF" devices ignore the reflow bit and never reflow the document even if it would be appropriate to do so on that device....
In summary: given the presence of "reflow" or the need to perform reflow because different display devices can be much larger or much smaller than a standard sheet of paper, the problems of the new improved "PDF" file format essentially become identical to the problems one is always already running into using HTML, MOBI, and EPUB file formats. The problems are not in the formats themselves. It is how authors of text in these formats that cause the problems.
YOU mention that some of the practices incorporating in authoring the PDFs do not work with the new reflow function. So it is a matter of generating the encoded text to work across all devices. So, as long as the authors insist on handcrafting things will break. IT kind of reminds me about the HTML wars. Well, I always produce HTML that look good in all browsers and platforms. It is only a matter of following the STANDARD proper and not all the fluff others consider the standard. regards Keith.
What is misquoted below is that we will not annoint any author of any markup language as "King" at the expense of all other efforts.
FWIW PG has in fact anointed txt70 and html "King and Queen" -- or is that "Queen and King" -- of the markup languages.
I certianly don't mind such standards, but I can't take credit for them. Michael On Sun, 27 Feb 2011, Jim Adcock wrote:
What is misquoted below is that we will not annoint any author of any markup language as "King" at the expense of all other efforts.
FWIW PG has in fact anointed txt70 and html "King and Queen" -- or is that "Queen and King" -- of the markup languages.
_______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d
I believe the developers or php or python, not sure which one! Should be crediting the use of! regards Keith. Am 28.02.2011 um 01:38 schrieb Jim Adcock:
I certianly don't mind such standards, but I can't take credit for them.
Sorry, but who else should we be blaming, er crediting, for txt70 ?
Hi Lee, Actually, I think HTML a very poor format. What I have in mind is something that looks more like LaTeX. regards Keith.
On 2/24/2011 5:00 PM, Keith J. Schultz wrote:
Actually, I think HTML a very poor format. What I have in mind is something that looks more like LaTeX.
As near as I can tell, LaTeX and HTML (and TEI), when appropriately refined and extended, are functionally equivalent. I tend to prefer XHTML primarily because it is more ubiquitous--there are more people who understand the syntax, and more tools available to both manipulate XHTML files and view them without conversion. Of secondary concern is that I, personally, have much more experience with XHTML than with LaTeX, so I feel more comfortable with it. That having been said, if you could generate a consensus that LaTeX is the best option I would support that decision, as the two formats are functionally equivalent, and having /some/ standard is preferable to having /no/ standard. However, you have completely side-stepped the first problem, which is Project Gutenberg's complete and utter unwillingness to adopt any standard or process reasonable calculated to improve its offerings. It's possible that we might be able to route around this damage if we could convince the white washers to accept submissions without an accompanying impoverished text version. At one point PG was also rejecting files that were simply more-or-less parallel versions of that which already existed in the PG repository (separate .epub for ADE, .epub for Stanza, .epub for Nook, for example). This barrier does seem to be relaxing, but I don't know what the current position is. So, maybe we could do the following: 1. Develop a consensus method for marking up e-books, and thoroughly document it. 2. Pick a file extension that will not conflict with any extension currently used in the PG repository. 3. Create an automated process that will create an impoverished text version from the "master" version. This impoverished text version will be used only to satisfy the white washers; it is not intended to ever actually be downloaded. 4. Slip the documented consensus method into the PG Wiki; we should probably put it up on a few web sites that PG does not control as well. 5. Lurk around on those lists where Project Gutenberg volunteers congregate; regularly post messages there to the effect of "Here's a markup method that will permit automated conversion of your labors of love to many different formats. We encourage you to try it. Post it to <some URL that accepts uploads> and we'll try to get Project Gutenberg to accept it." (Usually you can get around intransigent white washers by going to Michael Hart directly). 6. Monitor submissions of this type of file to be sure that the files available via PG really /do/ meet the requirements of the consensus markup method. I'm sure we could not rely on the white washers to enforce these requirements for us, and I suspect that the repository might occasionally be subjected to vandalism. Of course, we could do almost the same thing but upload the files to a repository that is out of Project Gutenberg's direct control, and that might make things easier. WikiSource perhaps?
Hi Lee, Personally, none of the Markups are particularly good for use a master format for ebook creatation. Also, One thing is that the users or who ever would NEVER enter anything into the code of master-format file. They use GUI-Tools with WYSWYG. This would enforce that the data in the format is consistent and correct. There would no hand-coding. regards Keith. Am 25.02.2011 um 18:43 schrieb Lee Passey:
On 2/24/2011 5:00 PM, Keith J. Schultz wrote:
Actually, I think HTML a very poor format. What I have in mind is something that looks more like LaTeX.
As near as I can tell, LaTeX and HTML (and TEI), when appropriately refined and extended, are functionally equivalent. I tend to prefer XHTML primarily because it is more ubiquitous--there are more people who understand the syntax, and more tools available to both manipulate XHTML files and view them without conversion. Of secondary concern is that I, personally, have much more experience with XHTML than with LaTeX, so I feel more comfortable with it.
On Thurs 24th February 2011 Lee Passey wrote:
On a related note, about 7 years ago the community at alt.binary.ebooks confronted the problem of HTML support in e-book hardware and software and came up with a recommendation as to how to mark up books using HTML to be most compatible with hand-held devices. If anyone's interested I could probably drag up that spec and post it here.
I'd be interested in the spec Lee mentions above. Bob Gibbins
participants (7)
-
a＠aboq.org -
Bowerbird＠aol.com -
Jim Adcock -
Keith J. Schultz -
Lee Passey -
Michael S. Hart -
Robert Gibbins