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