On Sat, 16 Nov 2013, Bill Meahan wrote:

I would /expect/ to get a valid EPUB file, or so I'm lead to believe.

At the moment, I'm simply trying it out using Hans' "export-example.tex" file that comes as part of the standard ConTeXt distribution, either Standalone or part of one of the other distributions. I haven't even opened the export-example.tex file in an editor (yet) in this round of trials and I've even run the script against it right in the ..../base/ directory where it is found in the distribution so I don't understand why it is not producing a valid EPUB. Once I've got that sorted out, I can try applying the lessons learned to my own documents.

ConTeXt provides two types of exports. The first is an XML export. Consider a sample file: ~~~ {test.tex} \setupbackend[export=yes] \starttext \startsection[title={This is a test}] \startparagraph Some random text \startitemize \item First \item Second \stopitemize \stopparagraph \stopsection \stoptext ~~~ Running `context test.tex` generates a `test.export` file that looks as follows: ~~~ {test.export} <?xml version='1.0' encoding='UTF-8' standalone='yes' ?> <!-- input filename : test --> <!-- processing date : Sat Nov 16 12:19:59 2013 --> <!-- context version : 2013.11.01 15:02 --> <!-- exporter version : 0.30 --> <document language="en" file="test" date="Sat Nov 16 12:19:59 2013" context="2013.11.01 15:02" version="0.30" xmlns:m="http://www.w3.org/1998/Math/MathML"> <section detail="section" location='aut:1'> <sectionnumber>1</sectionnumber> <sectiontitle>This is a test</sectiontitle> <sectioncontent> <paragraph>Some random text <itemgroup detail="itemize" symbol="1"><item><itemtag><!-- begin m:mrow -->•<!-- end m:mrow --></itemtag><itemcontent>First</itemcontent></item> <item><itemtag><!-- begin m:mrow -->•<!-- end m:mrow --></itemtag><itemcontent>Second</itemcontent></item></itemgroup></paragraph> </sectioncontent> </section> </document> ~~~ which is simply an XML representation of the document. In prinicple, if one adds an appropriate CSS file with that XML, any recent browser will be able to display it. So, if you change the first line of `test.tex` to ~~~ \setupbackend[export=yes, xhtml=yes, css=yes] ~~~ and run `context test.tex`, you will get four additional files: `test.xhtml`, `test-styles.css`, `test-images.css`, and `test.specification`. The `test.xhtml` file look as follows: ~~~{test.xhtml} <?xml version='1.0' encoding='UTF-8' standalone='yes' ?> <!-- input filename : test --> <!-- processing date : Sat Nov 16 12:22:58 2013 --> <!-- context version : 2013.11.01 15:02 --> <!-- exporter version : 0.30 --> <?xml-stylesheet type="text/css" href="test-styles.css"?> <?xml-stylesheet type="text/css" href="test-images.css"?> <?xml-stylesheet type="text/css" href="export-example.css"?> <document language="en" version="0.30" file="test" xmlns:xhtml="http://www.w3.org/1999/xhtml" xmlns:m="http://www.w3.org/1998/Math/MathML" date="Sat Nov 16 12:22:58 2013" context="2013.11.01 15:02"> <section location="aut:1" detail="section"> <sectionnumber>1</sectionnumber> <sectiontitle>This is a test</sectiontitle> <sectioncontent> <paragraph>Some random text <itemgroup symbol="1" detail="itemize"><item><itemtag><!-- begin m:mrow -->•<!-- end m:mrow --></itemtag><itemcontent>First</itemcontent></item> <item><itemtag><!-- begin m:mrow -->•<!-- end m:mrow --></itemtag><itemcontent>Second</itemcontent></item></itemgroup></paragraph> </sectioncontent> </section> </document> ~~~ Notice that apart from the three lines specifying the CSS files, the rest of the document is the same as in XML export. The two css files, `test-styles.css` and `test-images.css` include the relevant code for the style modifications and images in the document. The css file `export-example.css` comes with the ConTeXt distribution and has the default values for most ConTeXt elements. If you open the `test.xhtml` file in any browser, it will work correctly (because an XHTML markup is extensible and can use any XML tags as long as the behavior of the tag is specified in a CSS file). This is, however, not a XHTML file that includes the default XHTML markup (<h1>, <p>, <ul>, etc.) Now, lets come back to the last file generated by the export: `test.specification`. This is a lua file that contains: ~~~{test.specification} return { ["files"]={ "test-styles.css", "test-images.css", "export-example.css", "test.xhtml" }, ["identifier"]="e6a91a13-4e08-9494-3817-bfffe872be2c", ["images"]={}, ["language"]="en", ["name"]="test", ["root"]="test.xhtml", } ~~~~ When you run `mtxrun --script epub --make test`, it just takes the files specificied in the "files" field, and zips them in as a epub file. Now, in principle, any epub reader should support the any XHTML file; in practice, they only support the default XHTML tags. The XML+CSS file that ConTeXt generates are not handled correctly by most (all?) EPUB readers. So there are three options: 1. Wait until the EPUB readers catch up. It took almost 10-15 years for the browsers to catch up with the HTML standards, and I don't have much hope for EPUB readers here. Last I checked, none of them supported even MATHML-2. 2. Write a script (either using xmlproc, or using you favorite XML parser in your favorite language) that converts the XML generated by ConTeXt into a "standard" XHTML file. This is the easiest and the least time consuming alternative. 3. Modify the way in which ConTeXt generates the XML files. Ideally, I should be able to write something like ~~~ \setupparagraph[tag=p, class=default] ~~~ to tell context that \startparagraph ... \stopparagraph should translate to `<p class="default"> ... </p>". Last I checked the code that generates the XML file, there was no easy way to change the tags and classes. I hope that the above description clarifies the situation. Aditya

Hi All, I find that the ConTeXt approach to creating the EPub is flawed is a fundemental way! NOT TECHNICALLY. The EPub Standard is a big mess and if you really look at not a true standard in a true sense. Let me explain. 1) The file structure is well documented and properly defines the way a EPub file MUST contain and how file therein must be structure and listed. (notice that I use the word MUST) 2) Now, what a EPub-READER must implement to handle is very little. There are HARDLY ANY provisions that a certified EPuB-READER has to implement any particular engine or features therein to display/render the information contain in the EPub-file/wrapper. In other words it is simply a wrapper file format. and truly nothing more. There is NO REQUIREMENT in the standard that perfectly valid xhtml or HTML5 will be properly displayed in a certified EPub Reader! The standard has become more strict in recent years, yet still lacking. Am 16.11.2013 um 18:37 schrieb Aditya Mahajan : [snip, snip]

When you run `mtxrun --script epub --make test`, it just takes the files specificied in the "files" field, and zips them in as a epub file.

Now, in principle, any epub reader should support the any XHTML file; in practice, they only support the default XHTML tags. The XML+CSS file that ConTeXt generates are not handled correctly by most (all?) EPUB readers. Here is where my critic of ConTeXt approach grabs. What good is if one produces a perfectly correct EPub, yet hardly any EPub reader can handle. I remember correctly, an EPub Reader need not implement the handling of xhtml inorder to be certified or, if you wish, adhere to the standard. The basic reason why xhtml is handled is because most html renders handle xhtml. Yet, the standard only requires that very basic html features be implemented and the author is required to offer fallbacks incase features are not supported.

So there are three options:

1. Wait until the EPUB readers catch up. It took almost 10-15 years for the browsers to catch up with the HTML standards, and I don't have much hope for EPUB readers here. Last I checked, none of them supported even MATHML-2. Like I mentioned above a EPub reader is not REQUIRED to support it!

2. Write a script (either using xmlproc, or using you favorite XML parser in your favorite language) that converts the XML generated by ConTeXt into a "standard" XHTML file. This is the easiest and the least time consuming alternative. AGAIN, as mentioned above there is no guarantee that it will be displayed properly. Support/export of HTML5 would seem to me to be a better option, but then the HTML5 standard is not complete and not fully supported by most newer ereaders, also.

3. Modify the way in which ConTeXt generates the XML files. Ideally, I should be able to write something like Would be nice if there where commands in ConTeXt or a module for defining what should go into the CSS and a mode "epub" where the ConTeXt commands are converted to suitible HTML5 structures that are suitiable for most ereaders. Features: 1) margins in percentages 2) font sizes based on em 3) a new file for every chapter optional for sections user defined Just a few. Lots more can be found in any decent documentation on writing ebooks.

regards Keith.

Hi Hans, Am 18.11.2013 um 13:21 schrieb Hans Hagen :

On 11/18/2013 10:00 AM, Keith J. Schultz wrote:

...

2) Now, what a EPub-READER must implement to handle is very little. There are HARDLY ANY provisions that a certified EPuB-READER has to implement any particular engine or features therein to display/render the information contain in the EPub-file/wrapper.

right, and I'm not going to waste time on it till i have a decent ebook reader that behaves well The point you are missing is that the ereaders are behaving well. They are following the epub standard, and that to the letter of the standard. The problem is that the standard does not enforce any particular implementation. If you look at the slow progress of the standard that actually requires a full implementation of the HTML5 standard. That wait will very long.

Furthermore, ereaders are made by companies more interested in profits than spending a few Euros more to put decent HTML engines into their readers. Why they do not do that is beyond me!

...

...

3. Modify the way in which ConTeXt generates the XML files. Ideally, I should be able to write something like Would be nice if there where commands in ConTeXt or a module for defining what should go into the CSS and a mode "epub" where the ConTeXt commands are converted to suitible HTML5 structures that are suitiable for most ereaders. Features: 1) margins in percentages 2) font sizes based on em 3) a new file for every chapter optional for sections user defined Just a few. Lots more can be found in any decent documentation on writing ebooks.

context outputs xml and as a bonus provides a css too ... one can always convert that xml to his/her ebooks liking .. maybe at some point the mtx-epub script will do that

I always to like to look at programming as modular and would think that a epub/ebook module would be nice that maps there are commands for layingout ebooks. these commands can then be mapped back to standard context commands. For some interested in producing a epub then can use the conventions for producing ebooks and ConTeXt can provide the math conversions to regular page dimensions used in PDFs for proofing or creating a printed version. It would also make the creation of EPubs from ConTeXt a simple parsing exercise. regards Keith.

Am 18.11.2013 um 16:33 schrieb Hans Hagen :

On 11/18/2013 4:11 PM, Keith J. Schultz wrote:

...

Hi Hans,

Am 18.11.2013 um 13:21 schrieb Hans Hagen :

...

On 11/18/2013 10:00 AM, Keith J. Schultz wrote:

...

2) Now, what a EPub-READER must implement to handle is very little. There are HARDLY ANY provisions that a certified EPuB-READER has to implement any particular engine or features therein to display/render the information contain in the EPub-file/wrapper.

right, and I'm not going to waste time on it till i have a decent ebook reader that behaves well The point you are missing is that the ereaders are behaving well. They are following the epub standard, and that to the letter of the standard. The problem is that the standard does not enforce any particular implementation. If you look at the slow progress of the standard that actually requires a full implementation of the HTML5 standard. That wait will very long.

sure, and every time i see an epub novel i realize that for something like that one really can stick to rather dumb html ... the point is that one cannot expect context to output simple everywhere accepted html from complex rendered input ... I agree fully. But, Since there are those that wish to produce epubs aka ebooks, they should not be doing complex layout. One can always go from simple to complicated in needed, if there were commands dedicated to epub/ebooks/html. As I had pointed out in my last post below.

...

Furthermore, ereaders are made by companies more interested in profits than spending a few Euros more to put decent HTML engines into their readers. Why they do not do that is beyond me!

...

...

...

3. Modify the way in which ConTeXt generates the XML files. Ideally, I should be able to write something like Would be nice if there where commands in ConTeXt or a module for defining what should go into the CSS and a mode "epub" where the ConTeXt commands are converted to suitible HTML5 structures that are suitiable for most ereaders. Features: 1) margins in percentages 2) font sizes based on em 3) a new file for every chapter optional for sections user defined Just a few. Lots more can be found in any decent documentation on writing ebooks.

context outputs xml and as a bonus provides a css too ... one can always convert that xml to his/her ebooks liking .. maybe at some point the mtx-epub script will do that

I always to like to look at programming as modular and would think that a epub/ebook module would be nice that maps there are commands for layingout ebooks. these commands can then be mapped back to standard context commands.

in that case code in xml and either processit by context or transform it into something ebooks can render

...

For some interested in producing a epub then can use the conventions for producing ebooks and ConTeXt can provide the math conversions to regular page dimensions used in PDFs for proofing or creating a printed version. It would also make the creation of EPubs from ConTeXt a simple parsing exercise.

so far i had no projects where epub was needes so it has a low priority and i still read paper books (or when i would have ebooks i wouldn't need to render them) ... pdfs views quite well on e.g. nexus 7 devices and i assume the upcoming sony high res ebook will also do pdf well Well I did start the discussion. Just offer my 2 Euro cents worth. Especially, since it comes up every now and then. Furthermore, I there was a simple way to create epubs/books with ConTeXt more would use this feature.

I have used up enough of or time. regards Keith.

Hi Mica, Am 19.11.2013 um 22:39 schrieb Mica Semrick :

Keith,

Maybe you should explore an XML format that can be transformed directly to epub. You'd also be able to write a style sheet with ConTeXt that would out put a PDF as well. I think TEI-Lite is a good starting point. While XML is one approach and using XML-Styles and DocBook I could even do without ConTeXt completely. Yet, from a general user standpoint this way of marking up ebooks is tedious. XML has become the standard for storing all kinds of data. A a storage format it is great and allows for conversion to other formats for ages to come. YET, one has to know what XML is how to use it how to make tools to process it. That is something that I would not like to enforce on the average author.

Since you can make your own commands in ConTeXt, it will never be able to intelligently map all commands on to simple HTML. How true. That is the problem with any system that is and can handle more complex structures than a simpler system. That is why any module geared to creating ebooks has to only allow what is needed and can be done in any EREADER, (notice I wrote reader not / Book or EPub!)

My Idea is to use the Lua capabilities of ConTeXt to get the job done. I will try to exemplify. suggest MWE: \usemodule[ebook] \setupcss[…]{…}% see comment #1 \setupmapping[…]{…} % used for when author has his/her own ideas #2 %normal ConTeXt sets see comment #3 % possibly set a mode or set externally \starttext \startebook \chapter… %see comment #4 \startparagraph{leftmargin=20%, …] % see comment #5 % text \stopparagraph \starttable… \stoptable … \stopebook \stoptext OK, this pretty much looks like standard ConTeXt Comments: 1) Here is where the author can define the CSS he wants It will integrated into the CSS used for the ebook 2) The author can setup how the ebook commands are mapped to ConTeXt commands 3) Here are setups for the NORMAL ConTeXt commands for producing PDFs 4) if mode is PDF command is mapped to normal ConTeXt injected into stream if mode ebook, gather information for spine, etc, start a new file for the chapter start writing to this file as HTML 5) if in mode PDF map to ConTeXt command, whereby the leftmargin is used as the basis for the calculation .2\textwidth or if you wish This approach is ebook centric. Allows for rapid prototyping and proofing of the ebook using a PDF This approach alleviates the need to attempt to dumb down ConTeXt markup. Through the use mappings te author has the possibility of producing a higher quality PDF if wanted. The system could be designed to produce a file with the ConTeXt commands that can be edited for even higher quality PDFs of printed versions. There could be even XML or whatever mode in the ebook module. Another advantage would be is that we are a module that will produce HTML out of a ConTeXt styled syntax that can be directly converted to a PDF directly, without worrying about lose of formatting or using tools over which features are supported or not. This is a straight forward approach. True, enough, ConTeXt is not designed to be a HTML editor. It is a matter of design policy! The philosophy of going from TeX/ConTeXt centric to HTML is IMHO far inferior than going from HTML/ebook centric to ConTeXt. One can always make things more intricate/complicated and taking something complicated and morphing onto a less sophisticated system. What one has to keep in mind is that ConTeXt "renders" to PDF and that is what is not needed when producing a ebook. The rendering is done by the ereader. ConTeXt does have any information about screen size or orientation. ConTeXt is built upon a page morphology. ebooks are not! So any decent approach has to keep this in mind. regards Keith.

On Mon, Nov 18, 2013 at 10:12 AM, Keith J. Schultz wrote:

Am 18.11.2013 um 16:33 schrieb Hans Hagen :

...

On 11/18/2013 4:11 PM, Keith J. Schultz wrote:

...

Hi Hans,

Am 18.11.2013 um 13:21 schrieb Hans Hagen :

...

On 11/18/2013 10:00 AM, Keith J. Schultz wrote:

...

2) Now, what a EPub-READER must implement to handle is very little. There are HARDLY ANY provisions that a certified EPuB-READER has to implement any particular engine or features therein to display/render the information contain in the EPub-file/wrapper.

right, and I'm not going to waste time on it till i have a decent ebook reader that behaves well The point you are missing is that the ereaders are behaving well. They are following the epub standard, and that to the letter of the standard. The problem is that the standard does not enforce any particular implementation. If you look at the slow progress of the standard that actually requires a full implementation of the HTML5 standard. That wait will very long.

sure, and every time i see an epub novel i realize that for something like that one really can stick to rather dumb html ... the point is that one cannot expect context to output simple everywhere accepted html from complex rendered input ...

I agree fully. But, Since there are those that wish to produce epubs aka ebooks, they should not be doing complex layout. One can always go from simple to complicated in needed, if there were commands dedicated to epub/ebooks/html. As I had pointed out in my last post below.

...

...

Furthermore, ereaders are made by companies more interested in profits than spending a few Euros more to put decent HTML engines into their readers. Why they do not do that is beyond me!

...

...

...

3. Modify the way in which ConTeXt generates the XML files. Ideally, I should be able to write something like Would be nice if there where commands in ConTeXt or a module for defining what should go into the CSS and a mode "epub" where the ConTeXt commands are converted to suitible HTML5 structures that are suitiable for most ereaders. Features: 1) margins in percentages 2) font sizes based on em 3) a new file for every chapter optional for sections user defined Just a few. Lots more can be found in any decent documentation on writing ebooks.

context outputs xml and as a bonus provides a css too ... one can always convert that xml to his/her ebooks liking .. maybe at some point the mtx-epub script will do that

I always to like to look at programming as modular and would think that a epub/ebook module would be nice that maps there are commands for layingout ebooks. these commands can then be mapped back to standard context commands.

in that case code in xml and either processit by context or transform it into something ebooks can render

...

For some interested in producing a epub then can use the conventions for producing ebooks and ConTeXt can provide the math conversions to regular page dimensions used in PDFs for proofing or creating a printed version. It would also make the creation of EPubs from ConTeXt a simple parsing exercise.

so far i had no projects where epub was needes so it has a low priority and i still read paper books (or when i would have ebooks i wouldn't need to render them) ... pdfs views quite well on e.g. nexus 7 devices and i assume the upcoming sony high res ebook will also do pdf well

Well I did start the discussion. Just offer my 2 Euro cents worth. Especially, since it comes up every now and then. Furthermore, I there was a simple way to create epubs/books with ConTeXt more would use this feature.

I have used up enough of or time.

regards Keith.

___________________________________________________________________________________ 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 ___________________________________________________________________________________

___________________________________________________________________________________ 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 ___________________________________________________________________________________

On 11/20/2013 8:59 AM, Aditya Mahajan wrote:

As far as ConTeXt is concerned, you can process the above XML quite easily. Come to think of it, it may be a useful to provide a module that maps HTML5 to PDF.

Aditya

I would vote for that approach. It is pretty much analogous to what I have decided to do. I'm doing my actual writing in HTML. creating CSS for ebooks and ConTeXt environment files for PDF. I'll probably hack the html2latex Perl script to do the mapping. Pandoc will /not/ meet my needs because Markdown does not distinguish between emphasized text and italic text and Pandoc compels all other input markup to behave like Markdown. Textile would be perfect but only outputs HTML well. The RedCloth implementation does output LaTeX but ignores CSS-style classes applied to paragraphs et. al. My needs are much simpler than the majority of people on this list. I have no need for math, no need for indexes, no need for bibliographies, footnotes or citations. BUT I want really top-notch visual output whether in PDF or printed on dead trees. The latter is usually the result of giving the printer process PDF files anyway so for the visuals I want, PDF is the common denominator and TeX (whether LaTeX or ConTeXt) is the most reasonable path, InDesign is not for poverty-stricken wretches like me. Unfortunately (for many reasons) the market for the stuff I write is hell-bent to replace printed books and even replace high-quality electronic presentation with formats in which the reader chooses almost everything, regardless of whether it compliments the text or not. EPUB (especially EPUB3) does appear to /want/ to provide author/designer-determined presentation but it can still be ignored or overridden by the reader. I don't want to even imagine the visual discordance of reading something like /Jane Eyre/ with double-spaced Comic Sans but if the e-reader allows it.... I'll crawl back under my rock, now. -- Bill Meahan, Westland, Michigan

Hi, You do not understand my point. I one uses XML why use ConTeXt. Yet, I one wants to use ConTeXt and do ebooks and they have experience why force them to XML. As I stated the idea use ConTeXt to do the markup with commands that will ensure proper input of HTML5 for making ebooks that will render well on MOST ereaders and at the same time be typeset by ConTeXt to good quality PDF! ereaders need the html code to adhere to special guidelines in order to create a high quality display for the ebook. That is why special commands are needed to restirct the features available! regards Keith. Am 20.11.2013 um 14:59 schrieb Aditya Mahajan : [snip, snip]

To me, the biggest advantage of a TeX based system is the ease of extensibility. If you want to restrict to a specific subset, then might as well use XML:

<document> <book> <chapter> <paragraph leftmargin=20%> text </paragraph> </book> </document>

or using one of the existing XML schemas rather than inventing your own (perhaps even HTML5).

As far as ConTeXt is concerned, you can process the above XML quite easily. Come to think of it, it may be a useful to provide a module that maps HTML5 to PDF.

Aditya___________________________________________________________________________________ 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 ___________________________________________________________________________________