Hi James, so what can we learn? "Apparently" a master format can work! Nobody doubt that he just how to do it! The tool chain for creating different output formats have to be geared to the output format. Something, I have advocated. Actually, nothing new. Unless we actually see how the do it, and can learn from the way they do it. So, really, nothing interesting! regards Keith. Am 26.10.2012 um 06:34 schrieb James Adcock <jimad@msn.com>:

From: gutvol-d-bounces@lists.pglaf.org [mailto:gutvol-d-bounces@lists.pglaf.org] On Behalf Of Bowerbird@aol.com Sent: Thursday, October 25, 2012 3:31 PM To: gutvol-d@lists.pglaf.org; bowerbird@aol.com Subject: [gutvol-d] Books in Browsers Conference at Internet Archive

alex said;

...

The event is being livestreamed at http://toc.oreilly.com You may find this interesting.

...

if anyone finds anything from this conference interesting -- anything at all, _anything_, even _mildly_ interesting -- do please let us know what it is, and why it's interesting...

OK, well, what I found interesting there (after spending three minutes on it) is that Oreilly has the technology to send attractive, correctly formatting e-books out to customer from apparently a single mother source in three different distribution formats: PDF, ePUB and MOBI. And all three formats worked, and there were not the typical PG “scrambled eggs” formatting problems, and all three had sensible choices of paragraph formatting – even though they differed in how they formatting paragraphs. All three formats were a pleasure to read as far as the formatting was concerned. [The actual content sucked, but that is another matter.]

I would like someone to try training someone to use a subset of HTML markup, and use it properly, and see how it works. Even with a subset, there are lots of ways of applying that subset improperly, and having the display view look just fine on a PC. I suspect users will be unable to avoid the temptation to tell themselves that "if it looks right, it's right,", especially in cases where the match between the markup and the structure of the text is unclear or complex. <div class="poetry"> confused with <pre> is an egregious but at least easy-to-detect example. Most would be just about impossible to validate rigorously. <p> tags inside <td> is a case where in rare circumstances it might be appropriate, but it's seen far more commonly than is justified. ---------------------------- I can't think of any XML or HTML editors that support semantic structures in any useful way. If the user can intermingle what they already think they know about HTML, they will. On Fri, Oct 26, 2012 at 9:18 AM, James Adcock <jimad@msn.com> wrote:

*>*so what can we learn?****

** **

Well, one would hope “we” all would learn that this is a big difference between talking about a system that works, rather than actually producing a system that actually works.****

** **

Also, note that the Oreilly system only “works” for those authors who choose to publish at Oreilly. Many more authors publish in ePUB and MOBI – I think one could make the case that more book authors are publishing in MOBI than in any other format worldwide. Note that the Oreilly authors are techies publishing techie manuals for real money – which means Oreilly can both expect more from their authors as compared to volunteers, and it also actually means that their targeted book space is much smaller than the range of books and requirements that PG tackles.****

** **

http://oreilly.com/oreilly/author/index.html****

** **

Note that Oreilly is using DocBook Lite as its primary source language. DocBook is a real standard, widely used and supported, and has actual support for many features that that others here have been talking about for many years, including direct generation from lightly marked up “ascii text files.”****

** **

The bad news is that by default these DocBook tools generate techie “K&R” style manuals, rather than following standard attractive book formatting rules – if this was not tackled thoughtfully “we” would end up with much great ugliness.****

** **

And again, what I have against these kinds of XML based solutions is (excepting asciidoc) that it is basically going to require volunteers to get a “real” XML editor such as Oxygen XML [which might be plausible given that PG use might qualify for the “academic” pricing aka non-profit pricing.] And then learn how to set up and use the editor, which has its own steep learning curve.****

** **

Not sure at all how plausible this would be, rather than simply having PG document a well-supported subset of HTML/EPUB/MOBI which PG commits to actually supporting in a meaningful way. IE if a volunteer commits to only using the supported subset of HTML, then PG commits to making tools which will actually work on that subset, to produce attractive, useful books that others can actually read.****

Then unsupported HTML passes through the sausage-maker – perhaps generating “unsupported” warning messages – and the volunteer using the unsupported bits of HTML? Well, they get what they get – and if what they get doesn’t work on one or another platform, then PG acts up to make it work.****

** **

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

On 10/26/12 5:59 PM, James Simmons wrote:

Bowerbird,

Not exactly a new topic, but it looks like they will be talking about Booktype:

http://www.sourcefabric.org/en/booktype

Does anyone how it compares to Booki (http://www.booki.cc/)? Regards, Walter