Re: [gutvol-d] blah blah blah blah blah
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@lists.pglaf.org Subject: Re: [gutvol-d] blah blah blah blah blah On 2012-09-25, Bowerbird@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@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d
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.
A big mistake is being made if contributions from individuals are viewed as "belonging" to the those contributors, if contribution from DP are viewed as "belonging" to DP, or if contributions to PG are viewed as "belonging" to PG. On the contrary, all these things "belong" to the public, and respect to the public, and to the artistry of the original author, requires that we "get it right" and if and when we don't "get it right" then we need to work diligently and expeditiously to "get it fixed." It seems that part of the problem HAS been that contributions from individuals have started to be viewed as "belonging" to the those contributors, and contributions from DP have started to viewed as "belonging" to DP, leading to reluctance to fix problem when they are found. Part of the problem is that the donkey-work of HTML typesetting has itself become viewed as a form of "artistry" and "authorship" at PG and DP -- which it certainly IS NOT. Rather, it is simply typesetting. Which is still no excuse for doing it so badly.
On Tue, Oct 02, 2012 at 11:34:31AM -0700, James Adcock wrote:
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.
A big mistake is being made if contributions from individuals are viewed as "belonging" to the those contributors, if contribution from DP are viewed as "belonging" to DP, or if contributions to PG are viewed as "belonging" to PG.
On the contrary, all these things "belong" to the public, and respect to the public, and to the artistry of the original author, requires that we "get it right" and if and when we don't "get it right" then we need to work diligently and expeditiously to "get it fixed."
It seems that part of the problem HAS been that contributions from individuals have started to be viewed as "belonging" to the those contributors, and contributions from DP have started to viewed as "belonging" to DP, leading to reluctance to fix problem when they are found.
We encounter this rarely with contributors (from DP or elsewhere). But the procedure is clear: IF there is an errata report, and the producer/ contributor is reachable, then the errata team will usually consult with that contributor. If the contributor agrees with the change, no problem. There's a lot of human judgement and communication involved, sometimes. But mostly, error reports are enthusiastically accepted. And, very often (nearly always), updates to fix one set of reported errata usually lead to further updates. It's a positive feedback loop. The contributor does not get consulted for clear/obvious changes, usually. However, again, there are a lot of interpersonal relationships and personal preferences, so sometimes they do.
Part of the problem is that the donkey-work of HTML typesetting has itself become viewed as a form of "artistry" and "authorship" at PG and DP -- which it certainly IS NOT. Rather, it is simply typesetting. Which is still no excuse for doing it so badly.
In fact, the biggest problem with HTML as a master format is that it is (mis-)used for layout, not just structure. This is actively discouraged. At http://upload.pglaf.org, we request that the uploaded master should convert well to other formats, using epubmaker. While this is intended to avoid layout choices that don't map well to other formats, it is not extensively verified, by human or machine. -- Greg
There's a lot of human judgement and communication involved, sometimes. But mostly, error reports are enthusiastically accepted. And, very often (nearly always), updates to fix one set of reported errata usually lead to further updates. It's a positive feedback loop.
This is complete nonsense. I have been pointing out for years -- "error reporting" -- that almost all PG submissions have HTML formatting issues which make them unpleasant to look at and unpleasant to read on most ereader devices -- once run through the epubmaker "sausage maker" -- and nothing has been done to fix the problem. PG and DP have this NEGATIVE feedback loop where they fall in love with their own religion, drink their own Kool-Aid, and are then are incapable of seeing straight nor moving forward.
In fact, the biggest problem with HTML as a master format is that it is (mis-)used for layout, not just structure. This is actively discouraged. At http://upload.pglaf.org, we request that the uploaded master should convert well to other formats, using epubmaker. While this is intended to avoid layout choices that don't map well to other formats, it is not extensively verified, by human or machine.
And you are continuing to ignore that epubmaker is a big part of the problem. When a submission is made that say wraps a simple paragraph structure with a <p> then that paragraph structure *IS* properly marked for structure. Now mind you the style settings in that HTML file may not represent the most knowledgeable choices for compatibility for all ereader devices, but the algorithms used to map HTML to EPUB or to MOBI is something that PG has reserved exclusively for itself, not for the transcriber nor for DP. Thus failure of simple paragraph layout once run through epubmaker, for example, is a failure of PG, *NOT* of DP nor of the transcriber. Most of these problems can be simply and mechanically fixed by hand, which means that most of this could also be fixed by epubmaker. But this hasn't happened, because PG remains incapable of recognizing when it has a problem, let alone acting to fix that problem. Please note that other publishers, including for example Amazon, are taking these same PG HTML files, running them through their own "sausage maker" chain, and producing better results than PG is getting from epubmaker. There are a lot of ways the formatting issue *could* be fixed, but the reality is the problem is *not* being fixed. And that is a failure on the part of PG, primarily. Certainly there is a contingent at DP who also contribute to the problem by insisting on writing HTML which is only compatible with large screen desktop computers -- and even then only on a couple of the more popular browsers. But even that problem could be solved simply by having the WW'ers "sanity check" the HTML submission on a variety of very different size and shape displays, and rejecting the submission if it doesn't properly scale. But PG isn't even doing that.
In fact, the biggest problem with HTML as a master format is that it is (mis-)used for layout, not just structure. This is actively discouraged. At http://upload.pglaf.org, we request that the uploaded master should convert well to other formats, using epubmaker. While this is intended to avoid layout choices that don't map well to other formats, it is not extensively verified, by human or machine.
Although HTML was originally intended to be a "semantic" mark-up language, it is often grossly abused, has grown on steroids during the browser wars, and should be considered a first attempt only. As a semantic mark-up language it has many deficiencies, which are only to a very minimal extend addressed in HTML5. Trying to automatically extract any reasonable structural knowledge out of HTML, without very strictly enforced HTML coding standards is close to impossible. But that is exactly what you are trying to do here. In my post-processing chain, I work with TEI, and can just as easily generate the (monolithic) HTML and the ePub version from the same source, using the much better encoded knowledge of the high-level structure of a text that TEI offers me. Unfortunately, my better ePub's are not accepted, and instead, users get the inferior versions epubmaker spits out. This is frustration, and I am actually toying with the idea of getting my better ePubs on my own site instead. There are long discussions on the PGDP boards about post processing for ePub, but basically, I refuse to dumb-down my HTML for the sake of limited ePub readers, while it is very easy to have the best of all worlds: High quality HTML for the desktop readers, dumped-down ePub for the low-level ebook readers, and neat ePub (or ePub3) for the advanced readers. I already produce HTML that is semantic as far as reasonable within that format, and I am perfectly willing and capable of producing "enriched" HTML, which can include micro-format hints for PG tools, if only I was told how to. If my not-dumbed-down for the lowest denominator readers HTMLs would become no-longer accepted, I will no longer submit anything to PG, but set-up my own ebook site with like minded people. You can only ask that much from volunteers who work hard to produce nice things. I've submitted over 500 books so far. Jeroen.
Hi Jeroen, Isn't your 'extorsion attempt' a bit off the mark? Why not go on submitting to PG in the usual way, and put your nice epubs on some other site? We cannot expect PG to offer too many varieties of their texts; there will always be new toys for which people want to have special formats. I have submitted over 700 books to PG, and my solution has always been the following: 1. Submit well-proofed and standardised 8-bit texts with mark-up for italics, poetry, letters etc. 2. Generated html (re Marcello) is quite sufficient in 98 % of the cases. Not too pretty, but functional. 3. In special cases I must prepare the html version myself. Page numbers are included only when there is some academic reason for them, dropcaps etc. never. I've never had any clashes with whitewashers, they've always been very diplomatic and co-operative even with my mistakes. Most people on this list, to be sure, consider my work to be complete trash and worthless, but I know better. In the Nordic countries, 'text is king', other formats are nice additions. The old 7-bit ASCII was an abomination, but I'm still grateful to Greg for talking Michael around and accepting 8-bit text. Now utf-8 is even better. PG is a repository of digitised books with emphasis on pure text. Why? Michael thought far ahead; look how other formats are changing the whole time, and that's why you continue to have your religious wars without end or solution (I'm not going to be involved!). So, let's work more and talk less. Tapio 2012/10/3 Jeroen Hellingman <jeroen@bohol.ph>:
If my not-dumbed-down for the lowest denominator readers HTMLs would become no-longer accepted, I will no longer submit anything to PG, but set-up my own ebook site with like minded people. You can only ask that much from volunteers who work hard to produce nice things. I've submitted over 500 books so far.
Jeroen.
PG is a repository of digitised books with emphasis on pure text. Why? Michael thought far ahead; look how other formats are changing the whole time, and that's why you continue to have your religious wars without end or solution (I'm not going to be involved!).
First of all, what PG requires sadly is NOT a "text" file. For example I can create a "text" file from an html file in two seconds doing "cut and paste." The result is a text file. Is it something that PG will accept as their "PG-text" file? Sadly, no. Michael thought the details of text format choices didn't matter, and then proceeded to make a "fatal error" in what detailed text format he chose to standardize on. Namely he insisted on detailed and gratuitous extraneous newline inclusion rules. Also his rules for even how "PG-text" files work have changed over the years! Even his "bottom-line" standard isn't standard! Secondly, the theory is, or was, that one could move forward from a PG text file to more modern formats in a relatively small, finite amount of work -- such that the text files represent a "baseline" format. Well, is this true? Not really. The tale of 76.txt shows that this is not true. While working forward from an existing PG txt file to a "modern" version of an ebook file format is certainly LESS work than starting from scratch, it is still a tremendous amount of work, and requires continued access and comparison to the original page images. If one insisted on a true baseline format, what would it be? Answer: high resolution digitized page images. How useful would that be? Well, I've read old books in digitized page image form, and it wasn't a whole lot of fun. Almost better to read the raw OCR'ed versions.
Tapio, I haven't done as many books as you, but I've done a few and donated page images to DP for several more. I have done exactly as you suggest. After seeing the inadequate EPUB and MOBI formatted files PG distributes I made my own versions and put them on archive.org and amazon.com. A LOT of people have downloaded my books from PG; hardly any from archive.org and amazon. So a lot of people are getting poorly formatted books when they don't have to. The Kindle isn't just the latest toy. Neither is the Nook. Lots of people have these. I have both. You can make a nicely formatted EPUB for the Nook, run it through kindlegen, and have a nicely formatted MOBI. Any new toy that comes out will probably support EPUB. It is just silly to pretend that these two formats aren't the most important e-book formats there are. It seems to me that you could have a process that doesn't put too much of a burden on the whitewashers by encouraging the use of the RST master format and polishing up the EPUB generator that works off this format. In addition to improving the generated EPUB you could do the following: 1). Change the standard on what to do with illustrations so that illustrations in "landscape format" be allowed to remain in that formatted. Rotating them to be the right way up makes sense for HTML but not for e-book readers. 2). Add some kind of directive to the RST format to specify content that only belongs in a specific output format. For instance, you could specify that a section of ASCII art family tree tables should only go in the text format. A rotated picture might only go in HTML, and unrotated only in EPUB and Kindle formats. You might have differently formatted poetry in the web and EPUB versions. James Simmons On Thu, Oct 4, 2012 at 1:38 AM, Tapio Riikonen <tapri32@gmail.com> wrote:
Hi Jeroen,
Isn't your 'extorsion attempt' a bit off the mark? Why not go on submitting to PG in the usual way, and put your nice epubs on some other site? We cannot expect PG to offer too many varieties of their texts; there will always be new toys for which people want to have special formats.
I have submitted over 700 books to PG, and my solution has always been the following:
1. Submit well-proofed and standardised 8-bit texts with mark-up for italics, poetry, letters etc.
2. Generated html (re Marcello) is quite sufficient in 98 % of the cases. Not too pretty, but functional.
3. In special cases I must prepare the html version myself. Page numbers are included only when there is some academic reason for them, dropcaps etc. never.
I've never had any clashes with whitewashers, they've always been very diplomatic and co-operative even with my mistakes.
Most people on this list, to be sure, consider my work to be complete trash and worthless, but I know better. In the Nordic countries, 'text is king', other formats are nice additions.
The old 7-bit ASCII was an abomination, but I'm still grateful to Greg for talking Michael around and accepting 8-bit text. Now utf-8 is even better.
PG is a repository of digitised books with emphasis on pure text. Why? Michael thought far ahead; look how other formats are changing the whole time, and that's why you continue to have your religious wars without end or solution (I'm not going to be involved!).
So, let's work more and talk less.
Tapio
2012/10/3 Jeroen Hellingman <jeroen@bohol.ph>:
If my not-dumbed-down for the lowest denominator readers HTMLs would become no-longer accepted, I will no longer submit anything to PG, but set-up my own ebook site with like minded people. You can only ask that much from volunteers who work hard to produce nice things. I've submitted over 500 books so far.
Jeroen.
_______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d
Hi Tapio, It wasn't an extortion attempt. It was only to say that I would not post HTML anymore if I where forced to dumb it down to such a degree that it doesn't meet my personal standards (and they are not that high). I've already accepted that the process PG produces ePub is not yet optimal, and will start to use my own website to distribute my ePubs (and TEI masters) once I get a few things sorted out (such as getting rid of my PP backlog (which is now some 70 books, down from over 200 two years ago.) For the types of books I handle, plain text is often not sufficient. I have a lot of tables, lists, poetry, and so on, that will require a higher level of mark-up to be manageable. Preparing those books in a plain text only version is often the biggest burden. The generated HTML is certainly no option for me. Jeroen. On 2012-10-04 08:38, Tapio Riikonen wrote:
Hi Jeroen,
Isn't your 'extorsion attempt' a bit off the mark? Why not go on submitting to PG in the usual way, and put your nice epubs on some other site? We cannot expect PG to offer too many varieties of their texts; there will always be new toys for which people want to have special formats.
I have submitted over 700 books to PG, and my solution has always been the following:
1. Submit well-proofed and standardised 8-bit texts with mark-up for italics, poetry, letters etc.
2. Generated html (re Marcello) is quite sufficient in 98 % of the cases. Not too pretty, but functional.
3. In special cases I must prepare the html version myself. Page numbers are included only when there is some academic reason for them, dropcaps etc. never.
I've never had any clashes with whitewashers, they've always been very diplomatic and co-operative even with my mistakes.
Most people on this list, to be sure, consider my work to be complete trash and worthless, but I know better. In the Nordic countries, 'text is king', other formats are nice additions.
The old 7-bit ASCII was an abomination, but I'm still grateful to Greg for talking Michael around and accepting 8-bit text. Now utf-8 is even better.
PG is a repository of digitised books with emphasis on pure text. Why? Michael thought far ahead; look how other formats are changing the whole time, and that's why you continue to have your religious wars without end or solution (I'm not going to be involved!).
So, let's work more and talk less.
Tapio
2012/10/3 Jeroen Hellingman <jeroen@bohol.ph>:
If my not-dumbed-down for the lowest denominator readers HTMLs would become no-longer accepted, I will no longer submit anything to PG, but set-up my own ebook site with like minded people. You can only ask that much from volunteers who work hard to produce nice things. I've submitted over 500 books so far.
Jeroen.
_______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d
In my post-processing chain, I work with TEI, and can just as easily generate the (monolithic) HTML and the ePub version from the same source, using the much better encoded knowledge of the high-level structure of a text that TEI offers me. Unfortunately, my better ePub's are not accepted, and instead, users get the inferior versions epubmaker spits out. This is frustration, and I am actually toying with the idea of getting my better ePubs on my own site instead.
We agree that PG ought to accepting ePUB as a submission format. We also agree that it is desirable to be able to produce separate ePUB for the newer ereader devices (ePUB and Mobi8) and for dumbed-down versions for historic devices (Mobi7 or earlier). It is also quite possible to merge these two ePUBs into one using the already-defined @media queries, if that is desired -- PG has no need to invent their own incompatible @media queries. We also agree that is would be desirable to set up a separate ePUB distribution site, if PG is not interested in doing this. This also begs the question that if PG is willing to accept TEI, why are they not willing to use your superior sausage-making chain?
On 10/03/2012 10:19 PM, Jeroen Hellingman wrote:
There are long discussions on the PGDP boards about post processing for ePub, but basically, I refuse to dumb-down my HTML for the sake of limited ePub readers,...
This is the very attitude that damages PG: People, that think that 'their' HTML is superior to everybody else's and don't understand that the value of a big collection (vs. a single text) lies in its homogeneity and device independence. This attitude is much worse than the bogus copyrights that some publishers prefix to PD texts, in so far as you can easily remove those copyrights, but you cannot easily remove that complex vanity HTML that DP producers love oh so well.
If my not-dumbed-down for the lowest denominator readers HTMLs would become no-longer accepted, I will no longer submit anything to PG, but set-up my own ebook site with like minded people. You can only ask that much from volunteers who work hard to produce nice things. I've submitted over 500 books so far.
With your TEI workflow you could easily submit simple and interoperable HTML to PG, and complex vanity HTML to your own site. -- Marcello Perathoner webmaster@gutenberg.org
On 2012-10-04 21:12, Marcello Perathoner wrote:
On 10/03/2012 10:19 PM, Jeroen Hellingman wrote:
There are long discussions on the PGDP boards about post processing for ePub, but basically, I refuse to dumb-down my HTML for the sake of limited ePub readers,...
This is the very attitude that damages PG:
People, that think that 'their' HTML is superior to everybody else's and don't understand that the value of a big collection (vs. a single text) lies in its homogeneity and device independence.
I understand very well that a big collection of text in a single, well thought out master format adds considerably to its usefulness, however, I think HTML is a particular bad choice for such a master format, as it is (if not by design, by historical accident) far more a presentation format than a semantic format. The big funded university text projects mostly go for TEI for the very same reasons I've been using it for over 15 years now.
This attitude is much worse than the bogus copyrights that some publishers prefix to PD texts, in so far as you can easily remove those copyrights, but you cannot easily remove that complex vanity HTML that DP producers love oh so well.
That is nonsense: a fake copyright claim is extremely hard to remove, as you need to find an obviously public domain source, and do a detailed compare of the file with the falsely copyrighted one; while half an hour of Perl hacking is normally enough to tame even the most wildly decorated HTML mess (Word generated HTML anyone?)
With your TEI workflow you could easily submit simple and interoperable HTML to PG, and complex vanity HTML to your own site.
That is correct, and in-fact, when generating ePub, I already dump-down the HTML that goes inside them. However, it makes no sense to dump-down a version where everybody has the capability to enjoy the added value you can add with HTML. Jeroen.
That is correct, and in-fact, when generating ePub, I already dump-down the HTML that goes inside them. However, it makes no sense to dump-down a version where everybody has the capability to enjoy the added value you can add with HTML.
OK, how about the ability to provide two versions of HTML to PG: One the "vanity" HTML, and another the "dumbed-down" EPUB/MOBI version? And if a contributor doesn't want to provide the "dumbed-down" version, then let those of us who want to actually be able to read PG books on ebook readers create the "dumbed-down" aka "fixed" version so that PG customers, including ourselves, can read a PG version on our ebook readers which are not "scrambled eggs." And let's be clear, most of the time that which is being done in the "vanity" HTML can be done in a way which is almost identical and yet produce results that actually work on EPUB and MOBI devices -- it's just that the "vanity" HTML has been written using code which is nonconforming and ill-defined in the first place. Again, I don't understand the "vanity" in providing PG with HTML which is simply "broken." Just because HTML happens to display the way that you want it to look on your desktop computer with your display and your browser doesn't mean that code is right.
On Thu, Oct 4, 2012 at 11:36 AM, James Adcock <jimad@msn.com> wrote:
First of all, what PG requires sadly is NOT a "text" file. For example I can create a "text" file from an html file in two seconds doing "cut and paste." The result is a text file. Is it something that PG will accept as their "PG-text" file? Sadly, no. Michael thought the details of text format choices didn't matter, and then proceeded to make a "fatal error" in what detailed text format he chose to standardize on. Namely he insisted on detailed and gratuitous extraneous newline inclusion rules.
It is a text file; still the standard on most systems that prefer text files. The details of text format did matter, and he picked the ones that worked for the computers he was working on. Fancy wordwrap did not exist on the text reading tools that came with the computers PG started targetting. MS-DOS Edit came out in 1991; before that, the text tools you could depend on any PC owner having were edlin and more. Like many other features, it was the right decision at the time. On Thu, Oct 4, 2012 at 12:12 PM, Marcello Perathoner <marcello@perathoner.de> wrote:
On 10/03/2012 10:19 PM, Jeroen Hellingman wrote:
There are long discussions on the PGDP boards about post processing for ePub, but basically, I refuse to dumb-down my HTML for the sake of limited ePub readers,...
This is the very attitude that damages PG:
And not the attitude that you should abuse other volunteers and ignore their real concerns?
People, that think that 'their' HTML is superior to everybody else's and don't understand that the value of a big collection (vs. a single text) lies in its homogeneity and device independence.
People who want page numbers in scholarly editions are hardly unrealistic. As far as I know, PG has never tried to set up rules for homogenous HTML, especially HTML that does what people need it to. -- Kie ekzistas vivo, ekzistas espero.
Jeroen, I can understand your point with regard to more complex or academic books. Then it would be back to square one, i.e. we need a master format that is simple enough for producers to learn and easy enough for whitewashers to handle plus new and reliable tools for these purposes. I am no programmer, but as far as I can understand, this is simple in principle but almost impossible in practice. Personally, I'd have nothing against learning new tricks provided I could be sure of the new system's longevity :-) Tapio Jeroen wrote:
For the types of books I handle, plain text is often not sufficient. I have a lot of tables, lists, poetry, and so on, that will require a higher level of mark-up to be manageable. Preparing those books in a plain text only version is often the biggest burden.
The generated HTML is certainly no option for me.
Quoting Tapio Riikonen <tapri32@gmail.com>:
Jeroen,
I can understand your point with regard to more complex or academic books.
Then it would be back to square one, i.e. we need a master format that is simple enough for producers to learn and easy enough for whitewashers to handle plus new and reliable tools for these purposes. I am no programmer, but as far as I can understand, this is simple in principle but almost impossible in practice.
Books are complex beasts, and not always easy to typeset or encode. Sometimes you will need the full complexity as a monster like TEI. However, I still believe in that old scientific adagio: make it as simple as possible, but not simpler. Jeroen.
Books are complex beasts, and not always easy to typeset or encode.
We have a lot of books which are pretty simple, and could fit into a common methodology which should be able to run successfully "everywhere." We have a few books which are very complicated, and are not going to fit into a common methodology, at least not one which we can teach or motivate the average volunteer to use. There is a strong countercurrent however, who want to take simple things and make them complicated, and well as another thread who want to take complicated things and oversimplify them.
Like many other features, it was the right decision at the time.
And MOBI7 and earlier contains features designed to make it compatible with early versions of IE. Fortunately the world has moved on, even MOBI (thank god) has moved on. What remains stuck in place like a slowly melting glacier is PG. The notion that you can do a book once and that book remains frozen in time for the rest of eternity is simply wrong. We need a way to fix, maintain, and move books forward which is not dependent on the WW'ers to do the heavy lifting. The idea that PG and the PG community is not allowed to touch a book after it has been submitted because doing so might offend the vanity of the submitter (including DP) is simply a wrong-headed idea. These books do not belong to DP, they do not belong to the submitter, they do not belong to PG, and they do not belong to the original author. These books belong to the public, and PG [when its got its head screwed on] is simply acting as a facilitator to get books to the public which the public already owns. Having books with screwed up formatting which cannot be enjoyably read on ebook devices is simply lose/lose. We need a way to fix broken books. Right now we do not have a way to fix broken books. That is stupid, and it is pathetic.
People who want page numbers in scholarly editions are hardly unrealistic.
Page numbers could be set up to "work" where "work" probably means that they have to magically disappear in MOBI versions at least. I doubt EPUB readers want them either. The technology to hide page numbers is built into the ebook readers, it's just that PG isn't implementing it right, nor are the DP formatters implementing it right. But the problem isn't page numbers in scholarly editions. It's that page numbers are being implemented incorrectly in every "See Dick Run" book and then ebook reader customers see this hash of random numbers showing up in the middle of paragraphs. And/or the already limited display space of an ebook reader is needlessly being thrown away for a "feature" which doesn't even work.
On 10/4/2012 1:12 PM, Marcello Perathoner wrote: [snip]
With your TEI workflow you could easily submit simple and interoperable HTML to PG, and complex vanity HTML to your own site.
This is an excellent suggestion. Indeed, you could use archive.org as "your own site" and wouldn't even need to bother creating one. To solve the search and download issue, create an entry for your file(s) at OpenLibrary.org including a link to your submissions. The biggest drawback to the cataloging service at OpenLibrary is that it only shows the crappy Internet Archive scans when listing free e-books. It should be simple to create a search function that shows free e-books from other sources as well, but IA seems woefully understaffed at the moment. I do think, however, that it would be much easier to work with the Open Library catalog service than to work with anyone at PG. The only change I would make to Mr. Perathoner's suggestion is not to bother submitting anything to PG. Just create your standardized, full-featured files, put them on archive.org and send a little note to the whitewashers telling them where they can find them if they want them. From what you have said, I suspect that your files will be fairly easy to degrade.
Quoting Lee Passey <lee@novomail.net>:
On 10/4/2012 1:12 PM, Marcello Perathoner wrote:
[snip]
With your TEI workflow you could easily submit simple and interoperable HTML to PG, and complex vanity HTML to your own site.
This is surely something I am considering. I already run a placeholder site on gutenberg.ph (with permission from Michael Hart) for several years. Jeroen.
I've never seen the term "vanity html" before. The only effect I see for using it is to add to the hostility level and decrease the likelihood you will get cooperation. Same for "dumb-downed" but not as aggressively. I think better terms might be "complex" vs. "simple" and "portable" vs. "non-portable." Don On Thu, Oct 4, 2012 at 12:12 PM, Marcello Perathoner <marcello@perathoner.de
wrote:
On 10/03/2012 10:19 PM, Jeroen Hellingman wrote:
There are long discussions on the PGDP boards about post processing for
ePub, but basically, I refuse to dumb-down my HTML for the sake of limited ePub readers,...
This is the very attitude that damages PG:
People, that think that 'their' HTML is superior to everybody else's and don't understand that the value of a big collection (vs. a single text) lies in its homogeneity and device independence.
This attitude is much worse than the bogus copyrights that some publishers prefix to PD texts, in so far as you can easily remove those copyrights, but you cannot easily remove that complex vanity HTML that DP producers love oh so well.
If my not-dumbed-down for the lowest denominator readers HTMLs would
become no-longer accepted, I will no longer submit anything to PG, but set-up my own ebook site with like minded people. You can only ask that much from volunteers who work hard to produce nice things. I've submitted over 500 books so far.
With your TEI workflow you could easily submit simple and interoperable HTML to PG, and complex vanity HTML to your own site.
-- Marcello Perathoner webmaster@gutenberg.org ______________________________**_________________ 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>
On 10/05/2012 06:06 PM, don kretz wrote:
I've never seen the term "vanity html" before. The only effect I see for using it is to add to the hostility level and decrease the likelihood you will get cooperation.
Vanity HTML is the same as vanity press, except it's about wanting your poor HTML published instead of your poor writing. -- Marcello Perathoner webmaster@gutenberg.org
Ways PG html files commonly fail (listed about in order of what I typically see) 1) People who apply formatting to <p> who think they know what they are doing but do not. 2) Dropcaps by people who think they know what a dropcap is and know how to do it in html but know neither. 3) People who think they can position floats when they cannot. 4) People who apparently deliberately write html designed to fail on one or another common platform. 5) html absolute positioning assuming a particular display size. 6) margin sizing which assumes a particular display size and shape. 7) Text over images. 8) Text inside "images" which ought to be just text. 9) People who think they know how to turn page numbers on or off on one or another target device when they do not. 10) People who think they understand @media when they do not. 11) People who don't know or who don't care about common book formatting conventions. Etc. It may be "vanity" which causes these problems to exist, but "vanity" needn't cause these problems to exist. These "vanity" problems can usually be easily fixed in the html source code, often without negatively affecting at all how the html displays on a desktop computer.
Where/how do we learn how to properly prepare HTML files for PG? I think that most of us (DP) are doing the best we know how and want to do better. Fred From: gutvol-d-bounces@lists.pglaf.org [mailto:gutvol-d-bounces@lists.pglaf.org] On Behalf Of James Adcock Sent: Friday, October 05, 2012 12:31 To: 'Project Gutenberg Volunteer Discussion' Subject: Re: [gutvol-d] blah blah blah blah blah Ways PG html files commonly fail (listed about in order of what I typically see) 1) People who apply formatting to <p> who think they know what they are doing but do not. 2) Dropcaps by people who think they know what a dropcap is and know how to do it in html but know neither. 3) People who think they can position floats when they cannot. 4) People who apparently deliberately write html designed to fail on one or another common platform. 5) html absolute positioning assuming a particular display size. 6) margin sizing which assumes a particular display size and shape. 7) Text over images. 8) Text inside "images" which ought to be just text. 9) People who think they know how to turn page numbers on or off on one or another target device when they do not. 10) People who think they understand @media when they do not. 11) People who don't know or who don't care about common book formatting conventions. Etc. It may be "vanity" which causes these problems to exist, but "vanity" needn't cause these problems to exist. These "vanity" problems can usually be easily fixed in the html source code, often without negatively affecting at all how the html displays on a desktop computer.
On Fri, Oct 05, 2012 at 12:56:34PM -0700, Fred Salzer wrote:
Where/how do we learn how to properly prepare HTML files for PG? I think that most of us (DP) are doing the best we know how and want to do better.
Fred
Thanks for asking :) One specific guideline, which I don't think is fully adopted or enforced (yet. It will be), is to preview a project using epubmaker (http://epubmaker.pglaf.org) before submitting it. That will help to identify things that don't properly convert to derivative formats. The list that Adcock presented below is useful, though would need to be rewritten in a more positive and supportive manner. The bottom line for most points is to encourage use of HTML to mark up structure, not layout. It seems there are technical solutions that DO allow some safe use of HTML (or CSS) for layout, though I worry that what works today might not work as well tomorrow. For example, I was pleased to see that there is a set of CSS that better supports portability for use of images or large letters at the start of chapters (Louise posted this). Calling some of the beautifully & lovingly crafted eBooks "vanity" is unnecessarily derogatory. I find it easy to recognize the caring and passion that went into making them. Your question supports my belief that most people who help produce eBooks will be perfectly willing to follow guidance to insure their works are maximally readable, on a variety of devices, now and into the future. -- Greg
From: gutvol-d-bounces@lists.pglaf.org [mailto:gutvol-d-bounces@lists.pglaf.org] On Behalf Of James Adcock Sent: Friday, October 05, 2012 12:31 To: 'Project Gutenberg Volunteer Discussion' Subject: Re: [gutvol-d] blah blah blah blah blah
Ways PG html files commonly fail (listed about in order of what I typically see)
1) People who apply formatting to <p> who think they know what they are doing but do not.
2) Dropcaps by people who think they know what a dropcap is and know how to do it in html but know neither.
3) People who think they can position floats when they cannot.
4) People who apparently deliberately write html designed to fail on one or another common platform.
5) html absolute positioning assuming a particular display size.
6) margin sizing which assumes a particular display size and shape.
7) Text over images.
8) Text inside "images" which ought to be just text.
9) People who think they know how to turn page numbers on or off on one or another target device when they do not.
10) People who think they understand @media when they do not.
11) People who don't know or who don't care about common book formatting conventions.
Etc.
It may be "vanity" which causes these problems to exist, but "vanity" needn't cause these problems to exist. These "vanity" problems can usually be easily fixed in the html source code, often without negatively affecting at all how the html displays on a desktop computer.
Dr. Gregory B. Newby Chief Executive and Director Project Gutenberg Literary Archive Foundation www.gutenberg.org A 501(c)(3) not-for-profit organization with EIN 64-6221541 gbnewby@pglaf.org
For eb.tbicl.org, the pattern I use for illustrations is minimal. I will give examples from http://eb.tbicl.org/architecture-greek . [illo src="/vol02/4/images/img380a.jpg"] Fig. 17.—Lycian Tomb of Telmessus. [/illo] All that is absolutely required is the filename and the caption - and not even the caption if there is none in the source. The default format is 75% width, centered, but this is configurable. If you want other widths or positions, you can add classes css-style: [illo class="w35 lfloat" src="/vol02/4/images/img379a.jpg"] Fig. 15.—Plan of the Temple of Poseidon at Paestum. [/illo] Notice that some illustrations have credit lines: [illo src="/vol02/4/images/img379b.jpg"] [credit]From a photo by Brogi.[/credit] Fig. 16.—Temple of Poseidon at Paestum. [/illo] Others have an extended key to items in the illustration. [illo class="w35 rfloat" src="/vol02/4/images/img378.jpg"] [credit]From Curtius and Adler’s <i>Olympia</i>, by permission of Behrend & Co.[/credit] Fig. 14.—Plan of the Heraeum. [key] A, Peristyle; B, Pronaos; C, Naos; D, Opisthodomus; E, Base of statue of Hermes. [/key] [/illo] I have enough different tags now that the only html I include is in-line tags for e.g. italics, which work fine in every context I've wanted to display so far. Here is the markup for the page numbers in the right column: [pgnum]380[/pgnum] Note that, for presentation in the browser context, this produces a link to the TIA image for the page. The resulting html is: <a href=" http://www.archive.org/stream/encyclopaediabri02chisrich/#page/379/mode/1up" class="pagenum" target="_blank">379</a> but that's all produced automatically. Footnotes are equally trivial. There's only one in this article, but it's a little tricky because it includes a link to another article for which I use the [qv] tag. Notice that the footnote is available as a popup as well as in a list at the end of the article. The earliest Greek temple of which remains have been discovered[ref]Except, possibly, the earliest of those at [qv]Sparta[/qv] (<i>q.v.</i>).—Ed.[/ref] is that of the Heraeum at Converting from DP output (which is optimized for a full-screen browser, and no separate pages for articles - you get a whole volume) is mostly a matter of removing markup, most of which is automated. I generally post the articles an hour or two after the PG etext is available. I have a control bar with buttons for most tags: http://eb.readingroo.ms/editor-box-with-control-bar/ The most tedious challenge is articles with maths in them because i convert them (the maths, not the whole articles) to latex. My main poiot is that all that's really needed in PG text is accurate content and only enough markup to designate and locate the structural elements, and formatting should be standardized and automated. Don
Calling some of the beautifully & lovingly crafted eBooks "vanity" is unnecessarily derogatory.
Calling people who want to fix real bugs in PG books which prevent real PG customers from reading those books "snowflakes" is unnecessarily derogatory. Again "beautifully & lovingly crafted" *on what machine* ??? If they were "beautifully & lovingly crafted" to run "beautifully" on all machines then we would not be having these discussions. But what we have is people picking and choosing *for* PG which customers will be supported, and which will not. Elizabeth Castro makes extraordinarily "beautifully & lovingly crafted" books -- which only run on Apple IPad, even though they are "EPUB". Is that really where PG wants to go? Pick and choose which manufacturer brands of computers PG supports? Doesn't that move PG from supporting *public domain* books to being the captive house organ of one or another manufacturer?
On Fri, Oct 5, 2012 at 12:30 PM, James Adcock <jimad@msn.com> wrote:
Ways PG html files commonly fail (listed about in order of what I typically see)
1) People who apply formatting to <p> who think they know what they are doing but do not.
2) Dropcaps by people who think they know what a dropcap is and know how to do it in html but know neither. ... It may be "vanity" which causes these problems to exist,
Does it help for me to call you a jackass? If not, you could try not calling it vanity when you admit that they're trying to emulate the original and failing due to lack of knowledge. It's not helping anyone understand what's wrong with these files, nor does it encourage anyone to work with you. -- Kie ekzistas vivo, ekzistas espero.
Does it help for me to call you a jackass? If not, you could try not calling it vanity when you admit that they're trying to emulate the original and failing due to lack of knowledge. It's not helping anyone understand what's wrong with these files, nor does it encourage anyone to work with you.
These issues and their solutions and workarounds have been discussed on this forum and the DP formatting forums multiple times over multiple years without forward progress. What would it take to actually make forward progress? It's a serious question. One could put together a design book of suggested solutions, but guess what DP has already done that and most of their suggestions don't work, if they had tried them. There are also simple techniques that work wonderfully, but people refuse use them, here's a couple examples: 1) Don't use bottom margins on paragraphs. Only use top margins. 2) Don't indent paragraphs AND put a line space between paragraphs. Choose to wear either belt or suspenders. Don't wear both. 3) Don't try to emulate drop caps. HTML doesn't support drop caps, which means your attempt to emulated them will fail. Raised initial letters, however, can be easily accomplished--if you insist [I personally think they look goofy with modern fonts on modern computers.] 4) It is OK to default some or all of the CSS. Most devices will make reasonable display choices by default. When a formatter chooses to default a style, that IS a design choice -- PG epubmaker should not override that default. Doing so may break a deliberate design choice. Conversely attempting to specify all styles aka "CSS Reset" will not work on many devices. 5) Don't optimize for one platform at the expense of breaking things on another platform. PG has the online epubmaker. There is ADE, and desktop NOOK, and Kindle Previewer, etc. It is not hard to check your code and see if it will work or not. Guess what, if you do check it out, you will see that it fails, and then maybe you will choose to fix it. Why not then fix it? Again, I claim it IS "vanity" when people try to "over-engineer" a simple problem. Any one has worked in engineering for any length of time sees over and over again this tendency to engineer "baroque" designs with doohickeys and filigrees everywhere until top-heavy, the whole thing tips over and sinks ala the Vasa. How about working instead in the opposite direction? Make a design which is as simple and clean as possible, while capturing the essence of that which the original author was attempting to communicate. I would also point out that the goal SHOULD NOT be to try to exactly emulated the original. If you want to do that, use page image digitizations aka photocopies, or use a PDF or TeX format. We are trying to capture the essence that which the original *author* was attempting to communicate. We are *not* attempting to capture all of the design choices of the original *typesetter* -- which were often not that great design choices in the first place. My suggestion, again, is very simple: When people submit HTML code which fails on one or the other of the major platforms, then other volunteers should be allowed to fix that broken code. It is NOT "vanity" nor is it "snowflakes" to want PG to publish code that works on most major platforms. Rather that is PG's charter! "Write Once Read Everywhere." But we are not allowed to do this. Why? A: PG is afraid to hurt the personal "vanity" of the original HTML submitter. How sad.
On Sun, Oct 7, 2012 at 10:21 AM, James Adcock <jimad@msn.com> wrote:
Again, I claim it IS "vanity" when people try to "over-engineer" a simple problem.
And I claim it's vanity to think your personal opinion needs expressing even when it gives needless offense to people you need to work with.
Guess what, if you do check it out, you will see that it fails, and then maybe you will choose to fix it.
How? I'm producing HTML from a script that's taking an hour to convert for Kindle in Calibre and produces a suboptimal table of contents, and I couldn't find a single page out there that would tell me how to write better HTML for these purposes. Writing portable code is always a pain in the ass that involves knowing subtle bugs and issues on a variety of systems, and you're implying that something that professional programmers frequently punt on (I believe my favorite website has hit the "forget about IE 5" point) is something that people with no programming experience aren't doing because they're too lazy to.
Rather that is PG's charter! "Write Once Read Everywhere." But we are not allowed to do this. Why?
Because it's impossible. There is probably not a single person in the world that knows the issues of every web-browser in use as well as the issues of all the ebook readers, particularly once you add our local ebook generators in the equation. The Whitewashers want to avoid everyone and their brother offering tweaks for the HTML so that we work around a bug for IE 4 on Solaris and break the Sony Reader (admittedly a more minor platform) or vice versa, through an endless cycle of changes. -- Kie ekzistas vivo, ekzistas espero.
How? I'm producing HTML from a script that's taking an hour to convert for Kindle in Calibre and produces a suboptimal table of contents, and I couldn't find a single page out there that would tell me how to write better HTML for these purposes.
I think this forum and others have warned against using Calibre for serious purposes. Not sure what you are trying to do.
people with no programming experience aren't doing because they're too lazy to.
They are certainly not lazy because they are expending tremendous time and effort to complexify their offerings. Again, this is baroque-ification.
Rather that is PG's charter! "Write Once Read Everywhere." But we are not allowed to do this. Why?
Because it's impossible.
Nonsense. One can find the occasional submission that seems to understand the issues and "gets it right." You can also find people who know so little about HTML that they get it right. Here's the CSS from a recent book that "works" : <style type="text/css"> p { text-indent:1.5em; margin-top:0; margin-bottom:0; } p.first { text-indent:0; margin-top:0; margin-bottom:0; } div.bq { margin-top:1em; margin-bottom:1em; } div.bq p { margin-left:10%; margin-right:10%; } body { margin: 10% 10%; text-align: justify; } h1 { text-align:center; font-weight:normal; margin-top:2em; margin-bottom: 1em; font-size:1.2em; } hr.pb { border:none; border-bottom:1px solid silver; margin-top:50px; margin-bottom:50px; } hr.tb { border:none; margin-top: 1.5em; } div.figure { display:block; margin:0 auto; text-align:center; } p.caption { margin: 1em auto; text-indent: 0; width:70%; } </style> -- where epubmaker apparently "autorepairs" the margin settings. But the point is, one can look at the CSS and the markup, and say "well this person doesn't seem to be bending over backwards to do something goofy" and then one looks at the book, and guess what: It works.
James Adcock wrote:
Ways PG html files commonly fail (listed about in order of what I typically see)
1) People 2) Dropcaps 3) People 4) People 5) html 6) margin 7) Text 8) Text 9) People 10) People 11) People
If you could explain the problem in terms of the markup you're seeing, and the ways in which you think it could be improved, maybe one of us could actually submit some patches to epubmaker. As it stands, you just said that 6 out of 11 problems are down to people, and epubmaker can't fix them.
As it stands, you just said that 6 out of 11 problems are down to people, and epubmaker can't fix them.
I don't remember suggesting that epubmaker should be the place to fix these problems. Rather, what I suggested was that the problem *should* be fixed, that the problem has been going on for years, that the problem isn't getting fixed, and PG doesn't have an approach to fixing the problem. I would hope by now we can all agree that epubmaker is being sent on a fool's errand. What I have been suggesting is simple: When someone submits HTML which is broken on one or the other major platforms, then a PG volunteer who is interested in fixing the problem should be allowed to do so, while maintaining as much of the existing formatting as possible. IE formatting errors, just like scanno errors, should be something that is fixable. In practice fixing formatting errors is probably going to require submitting a new entire file because both the CSS and the markup will be involved. WW'ers can review the changes for sanity by doing a diff, like always. Let me restate the opposite position: Why should someone who insists on submitting broken HTML have the right to monopolize a good *public domain* book forever, such that PG can never distribute that book in a way that can pleasantly be read on all the major platforms ??? Another way of saying it is this: PG should set an expectation that submitted HTML should run in an attractive and pleasant manner on all the major platforms, or PG reserves the right to fix the problem. That isn't a "snowflake" problem, rather it is an *anti* snowflake statement: What you write once should be readable everywhere, and it should not show up in a "scambled eggs" "snowflake" variety messed up in a different manner on each and every one of the different platforms. If "vanity" keeps PG from being able to fix broken HTML, then we have real problems. In summary: Give us a real way to fix broken formatting.
A big mistake is being made if contributions from individuals are viewed as "belonging" to the those contributors, if contribution from DP are viewed as "belonging" to DP, or if contributions to PG are viewed as "belonging" to PG.
On the contrary, all these things "belong" to the public, and respect to the public, and to the artistry of the original author, requires that we "get it right" and if and when we don't "get it right" then we need to work diligently and expeditiously to "get it fixed."
This sounds like you're arguing against pride in your work. I don't see a problem with feeling a little ownership in a project you may have contributed weeks or months of your time to.
It seems that part of the problem HAS been that contributions from individuals have started to be viewed as "belonging" to the those contributors, and contributions from DP have started to viewed as "belonging" to DP, leading to reluctance to fix problem when they are found.
On the contrary, if there's a problem, I'd be more likely to want it fixed if I'm associated with it. But more to the point, where to you see anything resembling a "won't fix" attitude?
Part of the problem is that the donkey-work of HTML typesetting has itself become viewed as a form of "artistry" and "authorship" at PG and DP -- which it certainly IS NOT. Rather, it is simply typesetting. Which is still no excuse for doing it so badly.
You have a much different view of the activity than I do. And I also think good typesetting involves quite a bit of artistry. But again, how could one use pride in their work to excuse doing it badly?
_______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d
This sounds like you're arguing against pride in your work. I don't see a problem with feeling a little ownership in a project you may have contributed weeks or months of your time to.
I don' t see where "pride" is served by creating submissions to PG that don't work on a large variety of the ebook readers which real customers own and would like to use. If that be "pride" then at least give the rest of us a reasonable workaround where you can still be "proud" that your submission only works on a *nix 13.2" diagonal desktop screen, and the rest of us are still allowed to create a version of the same *risen to the public domain* book which is in fact suitable to be read on most customers' ebook reader devices.
On the contrary, if there's a problem, I'd be more likely to want it fixed if I'm associated with it. But more to the point, where to you see anything resembling a "won't fix" attitude?
I've been talking about this for years. Most PG submissions simply do not work when one attempts to read them on real world real customer ebook reader devices, and most of these problems CAN quickly and easily be fixed with a few minutes work. If a problem can be quickly and easily fixed but in fact never is "fixed" then what could possibly be more indicative of a "won't fix" attitude?
You have a much different view of the activity than I do. And I also think good typesetting involves quite a bit of artistry. But again, how could one use pride in their work to excuse doing it badly?
Read the DP threads on this matter where a bunch of DP formatter types say "If you make me write HTML that runs on ebook readers well then I quit!" That IS pride being used as an" excuse to do it badly." The "artist" is the person who wrote the book. The typesetter is just a technician, albeit ideally a skilled one, whose job it is to allow the real "artist's" work to actually be successfully and pleasantly read where and when real customers want to read it. But how can typesetting which causes a book to displayed in a "scrambled eggs" manner which ignores all the rules of typesetting for the last 560 years be considered "artistry?" Much of the HTML submitted to PG is complete hackery motivated by personal vanity, by people who claim they know HTML, but who do not. And again, this wouldn't be a problem, if PG would simply fix the problems where there are problems. But PG won't do this because PG has passed "ownership" to the self-proclaimed HTML "ar-teest" -- who is in fact just a dime store hacker. And this decision to pass "ownership" back to the HTML hacker "ar-teest" effectively turns "risen to the public domain" works back into private ownership -- just the exact opposite to the goals PG pretends to uphold!
participants (12)
-
David Starner -
don kretz -
Fred Salzer -
Greg Newby -
James Adcock -
James Simmons -
Jeroen Hellingman -
jeroen＠bohol.ph
-
Lee Passey -
Marcello Perathoner -
Paul Flo Williams -
Tapio Riikonen