From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.tex.context/84099 Path: news.gmane.org!not-for-mail From: Thangalin Newsgroups: gmane.comp.tex.context Subject: Re: EPUB XHTML Format Date: Wed, 4 Sep 2013 10:55:28 -0700 Message-ID: References: <5226FB76.8030602@wxs.nl> Reply-To: mailing list for ConTeXt users NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2001226711==" X-Trace: ger.gmane.org 1378317331 19843 80.91.229.3 (4 Sep 2013 17:55:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 4 Sep 2013 17:55:31 +0000 (UTC) To: mailing list for ConTeXt users Original-X-From: ntg-context-bounces@ntg.nl Wed Sep 04 19:55:36 2013 Return-path: Envelope-to: gctc-ntg-context-518@m.gmane.org Original-Received: from balder.ntg.nl ([5.39.185.229]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VHHIm-000457-4B for gctc-ntg-context-518@m.gmane.org; Wed, 04 Sep 2013 19:55:36 +0200 Original-Received: from localhost (localhost [127.0.0.1]) by balder.ntg.nl (Postfix) with ESMTP id AD49C10215; Wed, 4 Sep 2013 19:54:03 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at balder.ntg.nl Original-Received: from balder.ntg.nl ([127.0.0.1]) by localhost (balder.ntg.nl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id K-m65WSYMBjD; Wed, 4 Sep 2013 19:54:01 +0200 (CEST) Original-Received: from balder.ntg.nl (localhost [IPv6:::1]) by balder.ntg.nl (Postfix) with ESMTP id 6C97F101F3; Wed, 4 Sep 2013 19:54:01 +0200 (CEST) Original-Received: from localhost (localhost [127.0.0.1]) by balder.ntg.nl (Postfix) with ESMTP id E49F8101F3 for ; Wed, 4 Sep 2013 19:53:59 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at balder.ntg.nl Original-Received: from balder.ntg.nl ([127.0.0.1]) by localhost (balder.ntg.nl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id XUaoFzERNiZa for ; Wed, 4 Sep 2013 19:53:58 +0200 (CEST) Original-Received: from filter4-ams.mf.surf.net (filter4-ams.mf.surf.net [192.87.102.72]) by balder.ntg.nl (Postfix) with ESMTP id 89AA1101E7 for ; Wed, 4 Sep 2013 19:53:58 +0200 (CEST) Original-Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by filter4-ams.mf.surf.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id r84HuSmN029277 for ; Wed, 4 Sep 2013 19:56:29 +0200 Original-Received: by mail-ie0-f170.google.com with SMTP id 16so1189320iea.1 for ; Wed, 04 Sep 2013 10:55:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=1VOhQqfb7yqYZ+8tIFrt+O5ILfs2MKuiwyk3w0aDsyc=; b=zyg2c0XsSI0od/URhi3kBlvpL1bTFNwbdQLu7Ek7kOwPfJNoa2E2Nq7XLgaj9pxIiI g81cm61V64T1srloAbty4FBSrhYVXzFnmpgWXpurtqJ5YEQZgVKlDNFtGjF/1VciXZbS QULhHaEHMHhSS9QOgz5bsFD97I/FXdcOeJ5rDJTNNcHDKgneJqGtDu6xTyFIaRyh/sTu PJa9ePxw6acMz8fZbxyYUXrkuA9xuE/t6KHA55+6ezMDWVS/ltl1YEbLygK1Np3zLrAb jcTAv3pL9FDiTw183Dx705Dm1x9LAockRoUjVYL3bSkFbxEtCveDY+6M+lQ+AsZIBXqa 6z3Q== X-Received: by 10.50.25.39 with SMTP id z7mr2671625igf.59.1378317328099; Wed, 04 Sep 2013 10:55:28 -0700 (PDT) Original-Received: by 10.42.6.203 with HTTP; Wed, 4 Sep 2013 10:55:28 -0700 (PDT) In-Reply-To: <5226FB76.8030602@wxs.nl> X-Bayes-Prob: 0.5851 (Score 0, tokens from: @@RPTN) X-CanIt-Geo: ip=2607:f8b0:4001:c03::22a; country=US X-CanItPRO-Stream: uu:ntg-context@ntg.nl (inherits from uu:default, base:default) X-Canit-Stats-ID: 01Kl5Ut3C - 35041e45a21e - 20130904 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) X-BeenThere: ntg-context@ntg.nl X-Mailman-Version: 2.1.14 Precedence: list List-Id: mailing list for ConTeXt users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ntg-context-bounces@ntg.nl Original-Sender: ntg-context-bounces@ntg.nl Xref: news.gmane.org gmane.comp.tex.context:84099 Archived-At: --===============2001226711== Content-Type: multipart/alternative; boundary=047d7bd76898baaf3404e59282a1 --047d7bd76898baaf3404e59282a1 Content-Type: text/plain; charset=ISO-8859-1 Hi. of course we could alternatively export all as
> but i don't like that too much; html itself is not rich enough for our > purpose > What about giving developers the ability to change the destination element? For example: \setuplist[chapter][ xml={\starttag[h1]#1\stoptag} ] Would produce, upon export:

Chapter

Or (using "export" instead of "xml"; I don't care what it is named): \setuplist[chapter][ export={\starttag[div]\startattribute[class]{chapter}#1\stopattribute\stoptag}} ] Similarly, this would produce:
Chapter
This would offer the flexibility of custom XML documents without affecting the default behaviour. * Generates XHTML headers (including ) > > not needed as we're 'standalone' > Having the ability to produce the and elements could be as simple as: \setupexport[ standalone=no, ] > * Produces images as img tags, rather than float tags. >> > the css can deal with them (info is written to files for that) > Yes, but they aren't standard. There is an ecosystem of tools (e.g., Calibre, normalizing CSS templates, etc.), not to mention a widespread knowledge-base, that groks the minimal XHTML specification. Plus, using XML tags that are not in the minimal XHTML spec. means more testing on more devices to make sure that their XHTML parsers render correctly. > xhtml has no typical tags .. it's xml + css (or xslt) ... unfortunately > browsers have That is, a Strictly Conforming XHTML Document, as per: http://www.w3.org/TR/2000/REC-xhtml1-20000126/#docconf the export of context is in fact just xml, and by tagging it as xhtml we > can apply css to it; but if someone has a workflow for producing epub an > option if to postprocess that xml file into whatever epub one wants > I could transform the ConTeXt-generated XML into strictly conforming XHTML, but it was a step I was hoping to avoid. Right now my process is: 1. Convert XML data to a ConTeXt .tex file. 2. Convert ConTeXt to either PDF or EPUB. 3. Stylize EPUB using CSS. I want to use ConTeXt here (instead of going directly from XML data to EPUB) because ConTeXt provides functionality such as multiple indexes, table-of-contents, and bundling the .epub. Having an extra step to generate strictly conforming XHTML is architecturally painful as it means transforming the document three times (XML -> ConTeXt, ConTeXt -> XML, then XML -> XHTML). > Everytime we look into epub there's another issue ... it's not a standard > but reversed engineered application mess (happen soften with xml: turn some > application data structures into xml and call it a standard) > Some book vendors only accept validating EPUBs. ConTeXt is documented as being able to generate EPUBs. The documentation should state the EPUBs do not validate and do not generate strictly conforming XHTML. I have spent the last three weeks converting documents from LaTeX to ConTeXt because the documentation stated that ConTeXt can produce EPUBs. While true, the documentation did not mention its shortcomings. Had I known in advance, I probably would have gone straight to EPUB using Java or, with a little revulsion, PHP classes. ;-) That said, I probably should have tested this feature sooner. :-) as i have no real use/demand for epub it's not something i look into on a > daily basis > How can I help resolve these issues? Merely "testing" (which I am happy to do) isn't going to produce a strictly conforming XHTML document. Kindest regards. --047d7bd76898baaf3404e59282a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi.

of course we could alternatively export all as <div class=3D"tag-su= btag-..."> but i don't like that too much; html itself is not r= ich enough for our purpose

What about g= iving developers the ability to change the destination element? For example= :

\setuplist[chapter][
=A0 xml=3D{\starttag[h1]#1\stoptag}
]

Would produce, upon export:

<h1>Chapte= r</h1>

Or (using "export" inst= ead of "xml"; I don't care what it is named):

\setuplist[chapter][
=A0 export=3D{\starttag[div]\startattribute[class]= {chapter}#1\stopattribute\stoptag}}
]
=A0
Similarly, this would produce= :

<div class=3D"chapter">Chapter</div>
=

This would offer the flexibility of custom XML documents = without affecting the default behaviour.

=A0 * Generates XHTML headers (including <!DOCTYPE and <html...>)<= /blockquote>not needed as we're 'standalone'

Having the ability to produce the <!DOCTYPE...> and= <htmnl> elements could be as simple as:

\setupexport[
=A0 standalone=3Dno,
]
=A0
=A0 * Produces images as img tags, rather than float tags.=
the css can deal with them (info is written to files for that)

Yes, but they aren't standard. There is an ecos= ystem of tools (e.g., Calibre, normalizing CSS templates, etc.), not to men= tion a widespread knowledge-base, that groks the minimal XHTML specificatio= n. Plus, using XML tags that are not in the minimal XHTML spec. means more = testing on more devices to make sure that their XHTML parsers render correc= tly.
=A0
xhtml has no typical tags .. it's xml + = css (or xslt) ... unfortunately browsers have

That is, a Strictly Conforming XHTML Document, as per:<= /div>


the export of context is in fact just= xml, and by tagging it as xhtml we can apply css to it; but if someone has= a workflow for producing epub an option if to postprocess that xml file in= to whatever epub one wants=A0

I could transform the ConTeXt-generated XM= L into strictly conforming XHTML, but it was a step I was hoping to avoid. = Right now my process is:
  1. Convert XML data to a ConTe= Xt .tex file.
  2. Convert ConTeXt to either PDF or EPUB.
  3. Stylize EPUB using CSS.<= /li>
I want to use ConTeXt here (instead of going directly from X= ML data to EPUB) because ConTeXt provides functionality such as multiple in= dexes, table-of-contents, and bundling the .epub. Having an extra step to g= enerate strictly conforming XHTML is architecturally painful as it means tr= ansforming the document three times (XML -> ConTeXt, ConTeXt -> XML, = then XML -> XHTML).
=A0
Everytime we look into epub there's anot= her issue ... it's not a standard but reversed engineered application m= ess (happen soften with xml: turn some application data structures into xml= and call it a standard)

Some book vendors only accept validating E= PUBs. ConTeXt is documented as being able to generate EPUBs. The documentat= ion should state the EPUBs do not validate and do not generate strictly con= forming XHTML.

I have spent the last three weeks converting documents = from LaTeX to ConTeXt because the documentation stated that ConTeXt can pro= duce EPUBs. While true, the documentation did not mention its shortcomings.= Had I known in advance, I probably would have gone straight to EPUB using = Java or, with a little revulsion, PHP classes. ;-) That said, I probably sh= ould have tested this feature sooner. :-)

as i have no real use/demand for epub it= 9;s not something i look into on a daily basis

How can I help resolve these issues?
=

Merely "testing" (which I am happy to do) isn= 't going to produce a strictly conforming XHTML document.

Kindest regards.

--047d7bd76898baaf3404e59282a1-- --===============2001226711== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________ --===============2001226711==--