E-books and XML.

john Culleton

26 Aug 2014 26 Aug '14

9:07 a.m.

Context is moving toward accepting XML input, although the filtering process is necessarily complex. But what is also needed is a version of Context that produces well formed XML as an output. That would be a step toward producing a dual purpose document with Context, for print and for e-book use. Context users have invested time, often years, in learning how to write Context code. Writing XML is a whole other skillset, comparable to writing xhtml. So is writing a Context to XML converter a possibility? A probability? The commercial program InDesign already has such a capability. -- John Culleton Wexford Press Free list of books for self-publishers: http://wexfordpress.net/shortlist.html PDF e-book: "Create Book Covers with Scribus" available at http://www.booklocker.com/books/4055.html

Show replies by date

Wolfgang Schuster

26 Aug 26 Aug

9:10 a.m.

Am 26.08.2014 um 17:07 schrieb john Culleton :

...

Context is moving toward accepting XML input, although the filtering process is necessarily complex. But what is also needed is a version of Context that produces well formed XML as an output. That would be a step toward producing a dual purpose document with Context, for print and for e-book use.

Context users have invested time, often years, in learning how to write Context code. Writing XML is a whole other skillset, comparable to writing xhtml.

So is writing a Context to XML converter a possibility? A probability? The commercial program InDesign already has such a capability.

http://wiki.contextgarden.net/Epub Wolfgang

Henning Hraban Ramm

11:08 a.m.

Am 2014-08-26 um 21:10 schrieb Wolfgang Schuster :

...

Am 26.08.2014 um 17:07 schrieb john Culleton :

...
Context is moving toward accepting XML input, although the filtering process is necessarily complex. But what is also needed is a version of Context that produces well formed XML as an output. That would be a step toward producing a dual purpose document with Context, for print and for e-book use.

Context users have invested time, often years, in learning how to write Context code. Writing XML is a whole other skillset, comparable to writing xhtml.

So is writing a Context to XML converter a possibility? A probability? The commercial program InDesign already has such a capability.

http://wiki.contextgarden.net/Epub

Creating ePub from ConTeXt is still tedious - you need to tag everything (even paragraphs) with \start/\stop, the resulting export.xml is still missing a root node if you use project structure (components), and you need to tinker a lot with the results, since even available information like title is not written to the relevant ePub files. I’m at the moment working at ePub versions of my somgbooklets (using LilyPond) and have a bunch of XSL transformations plus shell script (Lua would have more style, I know) to automate as much as possible. That stuff is in a state of „works for me“, will try to flesh out the wiki page as soon as I’m content. Greetlings, Hraban --- http://www.fiee.net/texnique/ http://wiki.contextgarden.net https://www.cacert.org (I'm an assurer)

Hans Hagen

11:29 a.m.

On 8/26/2014 7:08 PM, Henning Hraban Ramm wrote:

...

Creating ePub from ConTeXt is still tedious - you need to tag everything (even paragraphs) with \start/\stop, the resulting export.xml is still missing a root node if you use project structure (components), and you need to tinker a lot with the results, since even available information like title is not written to the relevant ePub files.

rootnode .. in what sense? Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

Henning Hraban Ramm

27 Aug 27 Aug

1:02 a.m.

Am 2014-08-26 um 23:29 schrieb Hans Hagen :

...

On 8/26/2014 7:08 PM, Henning Hraban Ramm wrote:

...
Creating ePub from ConTeXt is still tedious - you need to tag everything (even paragraphs) with \start/\stop, the resulting export.xml is still missing a root node if you use project structure (components), and you need to tinker a lot with the results, since even available information like title is not written to the relevant ePub files.

rootnode .. in what sense?

Sorry Hans, I complained about that several times already: If I have a project structure, i.e. a product with components, export.xml starts like “““ <?xml version="1.0" encoding="UTF-8" standalone="yes" ?>     <division detail="frontpart"> <metadata> “““ And since there are several <division>s or other top nodes, Saxon rejects the file because it’s missing a root node. <metadata> is always put into the first node of the file (that should be the root node). Only with a single TeX file, I get something like “““ <?xml version='1.0' encoding='UTF-8' standalone='yes' ?>     <document language="en" file="solo" date="Wed Mar 12 11:06:58 2014" context="2014.03.07 11:42" version="0.30" xmlns:m="http://www.w3.org/1998/Math/MathML"> <metadata> “““ I.e. the root node <document> is missing. If you were to enhance ePub facilities (how much must I pay you?), it would be nice to see the data that you put in „metavariables“ (title, author) also in the generated OPF, NCX and cover files, and the main language in OPF. My script also creates a cover image from the first page of the content PDF as well as converts and copies all the included images, but your usual reasoning that everyone has other needs is of course true. I resolved to generate content, cover, NCX and OPF from export.xml via XSLT, i.e. throw away most of what the epub script does. But the structure of registers (that I abuse for a sorted ToC) is hard to parse, because there’s no structure that links register text and page number, e.g.: <register detail="index"> <registersection> <registerentries> <registerentry>A Elbereth Gilthoniel</registerentry> <registerpages> <break/> <registerpage><link destination="internal(105)" location="aut:105">47</link></registerpage></registerpages> <registerentry>Abitur</registerentry> <registerpages> <break/> <registerpage><link destination="internal(87)" location="aut:87">38</link></registerpage></registerpages> <registerentry>Agradini</registerentry> <registerpages> <break/> <registerpage><link destination="internal(32)" location="aut:32">16</link></registerpage></registerpages> <registerentry>Amselchen</registerentry> <registerpages> <break/> <registerpage><link destination="internal(136)" location="aut:136">66</link></registerpage></registerpages> My XSL for NCX looks like: <?xml version="1.0" encoding="UTF-8" ?> http://www.w3.org/1999/XSL/Transform">  <ncx xmlns="http://www.daisy.org/z3986/2005/ncx/" version="2005-1"> <head> <meta name="dtb:uid" content="BookId" /> <meta name="dtb:depth" content="1" /> <meta name="dtb:totalPgeCount" > </meta> <meta name="dtb:maxPageNumber"> </meta> </head> <docTitle> <text></text> </docTitle> <docAuthor> <text></text> </docAuthor> <navMap> <navPoint id="aut_1" playOrder="1"> <navLabel> <text>Start</text> </navLabel> <content src="content.xhtml"/> </navPoint> <navPoint> <navLabel> <text>xsl:apply-templates/</text> </navLabel> <content> content.xhtml# </content> </navPoint> </navMap> </ncx> Greetlings, Hraban --- http://www.fiee.net/texnique/ http://wiki.contextgarden.net https://www.cacert.org (I'm an assurer)

Hans Hagen

3:05 a.m.

On 8/27/2014 9:02 AM, Henning Hraban Ramm wrote:

...

Am 2014-08-26 um 23:29 schrieb Hans Hagen :

...
On 8/26/2014 7:08 PM, Henning Hraban Ramm wrote:

...
Creating ePub from ConTeXt is still tedious - you need to tag everything (even paragraphs) with \start/\stop, the resulting export.xml is still missing a root node if you use project structure (components), and you need to tinker a lot with the results, since even available information like title is not written to the relevant ePub files.

rootnode .. in what sense?

Sorry Hans, I complained about that several times already:

If I have a project structure, i.e. a product with components, export.xml starts like

“““ <?xml version="1.0" encoding="UTF-8" standalone="yes" ?>

   

<division detail="frontpart"> <metadata> “““

And since there are several <division>s or other top nodes, Saxon rejects the file because it’s missing a root node. <metadata> is always put into the first node of the file (that should be the root node).

Only with a single TeX file, I get something like

“““ <?xml version='1.0' encoding='UTF-8' standalone='yes' ?>

   

<document language="en" file="solo" date="Wed Mar 12 11:06:58 2014" context="2014.03.07 11:42" version="0.30" xmlns:m="http://www.w3.org/1998/Math/MathML"> <metadata> “““

I.e. the root node <document> is missing.

hm, can you make a small example? Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

Henning Hraban Ramm

3:25 a.m.

Am 2014-08-27 um 15:05 schrieb Hans Hagen :

...

...
I.e. the root node <document> is missing.

hm, can you make a small example?

Here you are. Greetlings, Hraban --- http://www.fiee.net/texnique/ http://wiki.contextgarden.net https://www.cacert.org (I'm an assurer)

Hans Hagen

3:37 a.m.

On 8/27/2014 11:25 AM, Henning Hraban Ramm wrote:

...

Am 2014-08-27 um 15:05 schrieb Hans Hagen :

...
...
I.e. the root node <document> is missing.

hm, can you make a small example?

Here you are.

Ah, the document tags are hooked into starttext and at startproduct time export is not yet enabled, Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

Henning Hraban Ramm

3:46 a.m.

Am 2014-08-27 um 15:37 schrieb Hans Hagen :

...

On 8/27/2014 11:25 AM, Henning Hraban Ramm wrote:

...
Am 2014-08-27 um 15:05 schrieb Hans Hagen :

...
...
I.e. the root node <document> is missing.

hm, can you make a small example?

Here you are.

Ah, the document tags are hooked into starttext and at startproduct time export is not yet enabled,

Nice that you immediately found the error! I suppose it is fixed in next beta? Greetlings, Hraban --- http://www.fiee.net/texnique/ http://wiki.contextgarden.net https://www.cacert.org (I'm an assurer)

Hans Hagen

4:06 a.m.

On 8/27/2014 11:46 AM, Henning Hraban Ramm wrote:

...

Am 2014-08-27 um 15:37 schrieb Hans Hagen :

...
On 8/27/2014 11:25 AM, Henning Hraban Ramm wrote:

...
Am 2014-08-27 um 15:05 schrieb Hans Hagen :

...
...
I.e. the root node <document> is missing.

hm, can you make a small example?

Here you are.

Ah, the document tags are hooked into starttext and at startproduct time export is not yet enabled,

Nice that you immediately found the error! I suppose it is fixed in next beta?

Indeed. Uploading now. You were lucky that I was looking at the export already ... now \setupbackend [export=yes, xhtml=yes, css=export-example.css] also exports an html file with all tags being 'div' and the default css has been adapted to support both. The default css still need some work because not all browsers handle these div expressions equally well. The idea is to have a decent looking default as template (one can always overload). I have no ebook device (threw away the broken very old one) so no testing of that part done. Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

Henning Hraban Ramm

28 Aug 28 Aug

2:10 a.m.

Am 2014-08-27 um 16:06 schrieb Hans Hagen :

...

\setupbackend [export=yes, xhtml=yes, css=export-example.css]

also exports an html file with all tags being 'div' and the default css has been adapted to support both. The default css still need some work because not all browsers handle these div expressions equally well. The idea is to have a decent looking default as template (one can always overload).

I have no ebook device (threw away the broken very old one) so no testing of that part done.

Unfortunately, in that new HTML file, you put all attributes into the class name, so it makes more sense to translate the XML as before. e.g. <div class="document xmlns:m-http://www.w3.org/1998/Math/MathML date-Thu Aug 28 14:00:55 2014 author-Henning Hraban Ramm, fiëé visuëlle version-0.31 title-Gestammelte Werke context-2014.08.27 11:51 file-prd_hraban language-de xmlns:xhtml-http://www.w3.org/1999/xhtml"> <div class="division detail-frontpart"> <div class="metadata"> <div class="metavariable name-author">Henning Hraban Ramm, fiëé visuëlle</div> Greetlings, Hraban --- http://www.fiee.net/texnique/ http://wiki.contextgarden.net https://www.cacert.org (I'm an assurer)

Hans Hagen

2:22 a.m.

On 8/28/2014 10:10 AM, Henning Hraban Ramm wrote:

...

Am 2014-08-27 um 16:06 schrieb Hans Hagen :

...
\setupbackend [export=yes, xhtml=yes, css=export-example.css]

also exports an html file with all tags being 'div' and the default css has been adapted to support both. The default css still need some work because not all browsers handle these div expressions equally well. The idea is to have a decent looking default as template (one can always overload).

I have no ebook device (threw away the broken very old one) so no testing of that part done.

Unfortunately, in that new HTML file, you put all attributes into the class name, so it makes more sense to translate the XML as before.

e.g.

<div class="document xmlns:m-http://www.w3.org/1998/Math/MathML date-Thu Aug 28 14:00:55 2014 author-Henning Hraban Ramm, fiëé visuëlle version-0.31 title-Gestammelte Werke context-2014.08.27 11:51 file-prd_hraban language-de xmlns:xhtml-http://www.w3.org/1999/xhtml">

that one is already fixed

...

<div class="division detail-frontpart"> <div class="metadata"> <div class="metavariable name-author">Henning Hraban Ramm, fiëé visuëlle</div>

those are is okay as a class can have multiple names and the attribute-name prefix can be used for further css detailing ... so we export both xthml old style (using tags, something that browsers understand) and xhtml new style (something that epub devices might be able to handle) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

Henning Hraban Ramm

4:54 a.m.

Am 2014-08-28 um 14:22 schrieb Hans Hagen :

...

...
<div class="document xmlns:m-http://www.w3.org/1998/Math/MathML date-Thu Aug 28 14:00:55 2014 author-Henning Hraban Ramm, fiëé visuëlle version-0.31 title-Gestammelte Werke context-2014.08.27 11:51 file-prd_hraban language-de xmlns:xhtml-http://www.w3.org/1999/xhtml">

that one is already fixed

good

...

...
<div class="division detail-frontpart"> <div class="metadata"> <div class="metavariable name-author">Henning Hraban Ramm, fiëé visuëlle</div>

those are is okay as a class can have multiple names and the attribute-name prefix can be used for further css detailing ... so we export both xthml old style (using tags, something that browsers understand) and xhtml new style (something that epub devices might be able to handle)

Ok, I don’t care, will continue to use the XML. Next issue: I just recognized there’s a problem with references, esp. register: ... <section detail="Titel" location="aut:2"> <sectiontitle>Erinnerung </sectiontitle> ... <registerentry>Erinnerung</registerentry> <registerpages> <break/> <registerpage><link destination="internal(3)" location="aut:3">4</link></registerpage></registerpages> ... <registerentry>Vor meinem inn’ren Auge schweben Namen</registerentry> <registerpages> <break/> <registerpage><link destination="internal(4)" location="aut:4">4</link></registerpage></registerpages> (These are title and start of lyrics of a song.) Beside the inconvenience that there is no node wrapping registerentry and registerpages, the locations don’t match. If there are several index entries pointing to the same point (page), as here, they’re continuously numbered, so that it’s no solution to just subtract 1, as I do at the moment to create my ToC. Maybe the internal location numbers mean something, but I need a working reference; export.xml doesn’t know anything about pages, therefore the destination makes no sense. Doesn’t ConTeXt have some unique internal reference name? Greetlings, Hraban --- http://www.fiee.net/texnique/ http://wiki.contextgarden.net https://www.cacert.org (I'm an assurer)

Hans Hagen

7:34 a.m.

On 8/28/2014 12:54 PM, Henning Hraban Ramm wrote:

...

Am 2014-08-28 um 14:22 schrieb Hans Hagen :

...
...
<div class="document xmlns:m-http://www.w3.org/1998/Math/MathML date-Thu Aug 28 14:00:55 2014 author-Henning Hraban Ramm, fiëé visuëlle version-0.31 title-Gestammelte Werke context-2014.08.27 11:51 file-prd_hraban language-de xmlns:xhtml-http://www.w3.org/1999/xhtml">

that one is already fixed

good

...
...
<div class="division detail-frontpart"> <div class="metadata"> <div class="metavariable name-author">Henning Hraban Ramm, fiëé visuëlle</div>

those are is okay as a class can have multiple names and the attribute-name prefix can be used for further css detailing ... so we export both xthml old style (using tags, something that browsers understand) and xhtml new style (something that epub devices might be able to handle)

Ok, I don’t care, will continue to use the XML.

Next issue:

I just recognized there’s a problem with references, esp. register:

.... <section detail="Titel" location="aut:2"> <sectiontitle>Erinnerung </sectiontitle> .... <registerentry>Erinnerung</registerentry> <registerpages> <break/> <registerpage><link destination="internal(3)" location="aut:3">4</link></registerpage></registerpages> .... <registerentry>Vor meinem inn’ren Auge schweben Namen</registerentry> <registerpages> <break/> <registerpage><link destination="internal(4)" location="aut:4">4</link></registerpage></registerpages>

(These are title and start of lyrics of a song.)

Beside the inconvenience that there is no node wrapping registerentry and registerpages, the locations don’t match. If there are several index entries pointing to the same point (page), as here, they’re continuously numbered, so that it’s no solution to just subtract 1, as I do at the moment to create my ToC.

Maybe the internal location numbers mean something, but I need a working reference; export.xml doesn’t know anything about pages, therefore the destination makes no sense. Doesn’t ConTeXt have some unique internal reference name?

the internals are the unique ones ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

Hans Hagen

7:35 a.m.

On 8/28/2014 12:54 PM, Henning Hraban Ramm wrote:

...

Am 2014-08-28 um 14:22 schrieb Hans Hagen :

...
...
<div class="document xmlns:m-http://www.w3.org/1998/Math/MathML date-Thu Aug 28 14:00:55 2014 author-Henning Hraban Ramm, fiëé visuëlle version-0.31 title-Gestammelte Werke context-2014.08.27 11:51 file-prd_hraban language-de xmlns:xhtml-http://www.w3.org/1999/xhtml">

that one is already fixed

good

...
...
<div class="division detail-frontpart"> <div class="metadata"> <div class="metavariable name-author">Henning Hraban Ramm, fiëé visuëlle</div>

those are is okay as a class can have multiple names and the attribute-name prefix can be used for further css detailing ... so we export both xthml old style (using tags, something that browsers understand) and xhtml new style (something that epub devices might be able to handle)

Ok, I don’t care, will continue to use the XML.

Next issue:

I just recognized there’s a problem with references, esp. register:

.... <section detail="Titel" location="aut:2"> <sectiontitle>Erinnerung </sectiontitle> .... <registerentry>Erinnerung</registerentry> <registerpages> <break/> <registerpage><link destination="internal(3)" location="aut:3">4</link></registerpage></registerpages> .... <registerentry>Vor meinem inn’ren Auge schweben Namen</registerentry> <registerpages> <break/> <registerpage><link destination="internal(4)" location="aut:4">4</link></registerpage></registerpages>

(These are title and start of lyrics of a song.)

Beside the inconvenience that there is no node wrapping registerentry and registerpages, the locations don’t match. If there are several index entries pointing to the same point (page), as here, they’re continuously numbered, so that it’s no solution to just subtract 1, as I do at the moment to create my ToC.

no test file ... no solution ...

...

Maybe the internal location numbers mean something, but I need a working reference; export.xml doesn’t know anything about pages, therefore the destination makes no sense. Doesn’t ConTeXt have some unique internal reference name?

Greetlings, Hraban --- http://www.fiee.net/texnique/ http://wiki.contextgarden.net https://www.cacert.org (I'm an assurer)

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

Hans Hagen

11:39 a.m.

On 8/28/2014 12:54 PM, Henning Hraban Ramm wrote:

...

Am 2014-08-28 um 14:22 schrieb Hans Hagen :

...
...
<div class="document xmlns:m-http://www.w3.org/1998/Math/MathML date-Thu Aug 28 14:00:55 2014 author-Henning Hraban Ramm, fiëé visuëlle version-0.31 title-Gestammelte Werke context-2014.08.27 11:51 file-prd_hraban language-de xmlns:xhtml-http://www.w3.org/1999/xhtml">

that one is already fixed

good

...
...
<div class="division detail-frontpart"> <div class="metadata"> <div class="metavariable name-author">Henning Hraban Ramm, fiëé visuëlle</div>

those are is okay as a class can have multiple names and the attribute-name prefix can be used for further css detailing ... so we export both xthml old style (using tags, something that browsers understand) and xhtml new style (something that epub devices might be able to handle)

Ok, I don’t care, will continue to use the XML.

Next issue:

I just recognized there’s a problem with references, esp. register:

.... <section detail="Titel" location="aut:2"> <sectiontitle>Erinnerung </sectiontitle> .... <registerentry>Erinnerung</registerentry> <registerpages> <break/> <registerpage><link destination="internal(3)" location="aut:3">4</link></registerpage></registerpages> .... <registerentry>Vor meinem inn’ren Auge schweben Namen</registerentry> <registerpages> <break/> <registerpage><link destination="internal(4)" location="aut:4">4</link></registerpage></registerpages>

(These are title and start of lyrics of a song.)

Beside the inconvenience that there is no node wrapping registerentry and registerpages, the locations don’t match. If there are several index entries pointing to the same point (page), as here, they’re continuously numbered, so that it’s no solution to just subtract 1, as I do at the moment to create my ToC.

new beta \setupbackend [export=yes, xhtml=yes, css=export-example.css] \starttext \index{foo}foo \page \index{bar}bar \page \index{foo}foo \page \index{bar}bar \page \index{foo+test}foo \page \index{bar+test}bar \page \placeregister[index] \stoptext gives: <register detail="index"> <registersection> <registertag>b</registertag> <registerentries> <registerentry> <registercontent>bar</registercontent> <registerpages><registerpage>2</registerpage><registerseparator>,</registerseparator><registerpage>4</registerpage></registerpages> </registerentry> <registerentries> <registerentry> <registercontent>test</registercontent> <registerpages><registerpage>6</registerpage></registerpages> </registerentry> </registerentries> </registerentries> </registersection> <registersection> <registertag>f</registertag> <registerentries> <registerentry> <registercontent>foo</registercontent> <registerpages><registerpage>1</registerpage><registerseparator>,</registerseparator><registerpage>3</registerpage></registerpages> </registerentry> <registerentries> <registerentry> <registercontent>test</registercontent> <registerpages><registerpage>5</registerpage></registerpages> </registerentry> </registerentries> </registerentries> </registersection> </register>

...

Maybe the internal location numbers mean something, but I need a working reference; export.xml doesn’t know anything about pages, therefore the destination makes no sense. Doesn’t ConTeXt have some unique internal reference name?

Greetlings, Hraban --- http://www.fiee.net/texnique/ http://wiki.contextgarden.net https://www.cacert.org (I'm an assurer)

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

Henning Hraban Ramm

29 Aug 29 Aug

12:33 a.m.

Am 2014-08-28 um 23:39 schrieb Hans Hagen :

...

...
I just recognized there’s a problem with references, esp. register:

.... <section detail="Titel" location="aut:2"> <sectiontitle>Erinnerung </sectiontitle> .... <registerentry>Erinnerung</registerentry> <registerpages> <break/> <registerpage><link destination="internal(3)" location="aut:3">4</link></registerpage></registerpages> .... <registerentry>Vor meinem inn’ren Auge schweben Namen</registerentry> <registerpages> <break/> <registerpage><link destination="internal(4)" location="aut:4">4</link></registerpage></registerpages>

(These are title and start of lyrics of a song.)

Beside the inconvenience that there is no node wrapping registerentry and registerpages, the locations don’t match. If there are several index entries pointing to the same point (page), as here, they’re continuously numbered, so that it’s no solution to just subtract 1, as I do at the moment to create my ToC.

new beta

\setupbackend [export=yes, xhtml=yes, css=export-example.css]

\starttext

\index{foo}foo \page \index{bar}bar \page \index{foo}foo \page \index{bar}bar \page \index{foo+test}foo \page \index{bar+test}bar \page

\placeregister[index]

\stoptext

gives:

<register detail="index"> <registersection> <registertag>b</registertag> <registerentries> <registerentry> <registercontent>bar</registercontent> <registerpages><registerpage>2</registerpage><registerseparator>,</registerseparator><registerpage>4</registerpage></registerpages> </registerentry> <registerentries> <registerentry> <registercontent>test</registercontent> <registerpages><registerpage>6</registerpage></registerpages> </registerentry> </registerentries> </registerentries> </registersection> <registersection> <registertag>f</registertag> <registerentries> <registerentry> <registercontent>foo</registercontent> <registerpages><registerpage>1</registerpage><registerseparator>,</registerseparator><registerpage>3</registerpage></registerpages> </registerentry> <registerentries> <registerentry> <registercontent>test</registercontent> <registerpages><registerpage>5</registerpage></registerpages> </registerentry> </registerentries> </registerentries> </registersection> </register>

...
Maybe the internal location numbers mean something, but I need a working reference; export.xml doesn’t know anything about pages, therefore the destination makes no sense. Doesn’t ConTeXt have some unique internal reference name?

Thank you for caring, the tag hierarchy is good now, but why did you leave out the locations now? I need some connection between register entry and the origin to be able to create a link. I can’t use the page numbers, since they don’t exist in the XML (and of course they make no sense there). Greetlings, Hraban --- http://www.fiee.net/texnique/ http://wiki.contextgarden.net https://www.cacert.org (I'm an assurer)

Hans Hagen

4:17 a.m.

On 8/29/2014 8:33 AM, Henning Hraban Ramm wrote:

...

Am 2014-08-28 um 23:39 schrieb Hans Hagen :

...
...
I just recognized there’s a problem with references, esp. register:

.... <section detail="Titel" location="aut:2"> <sectiontitle>Erinnerung </sectiontitle> .... <registerentry>Erinnerung</registerentry> <registerpages> <break/> <registerpage><link destination="internal(3)" location="aut:3">4</link></registerpage></registerpages> .... <registerentry>Vor meinem inn’ren Auge schweben Namen</registerentry> <registerpages> <break/> <registerpage><link destination="internal(4)" location="aut:4">4</link></registerpage></registerpages>

(These are title and start of lyrics of a song.)

Beside the inconvenience that there is no node wrapping registerentry and registerpages, the locations don’t match. If there are several index entries pointing to the same point (page), as here, they’re continuously numbered, so that it’s no solution to just subtract 1, as I do at the moment to create my ToC.

new beta

\setupbackend [export=yes, xhtml=yes, css=export-example.css]

\starttext

\index{foo}foo \page \index{bar}bar \page \index{foo}foo \page \index{bar}bar \page \index{foo+test}foo \page \index{bar+test}bar \page

\placeregister[index]

\stoptext

gives:

<register detail="index"> <registersection> <registertag>b</registertag> <registerentries> <registerentry> <registercontent>bar</registercontent> <registerpages><registerpage>2</registerpage><registerseparator>,</registerseparator><registerpage>4</registerpage></registerpages> </registerentry> <registerentries> <registerentry> <registercontent>test</registercontent> <registerpages><registerpage>6</registerpage></registerpages> </registerentry> </registerentries> </registerentries> </registersection> <registersection> <registertag>f</registertag> <registerentries> <registerentry> <registercontent>foo</registercontent> <registerpages><registerpage>1</registerpage><registerseparator>,</registerseparator><registerpage>3</registerpage></registerpages> </registerentry> <registerentries> <registerentry> <registercontent>test</registercontent> <registerpages><registerpage>5</registerpage></registerpages> </registerentry> </registerentries> </registerentries> </registersection> </register>

...
Maybe the internal location numbers mean something, but I need a working reference; export.xml doesn’t know anything about pages, therefore the destination makes no sense. Doesn’t ConTeXt have some unique internal reference name?

Thank you for caring, the tag hierarchy is good now, but why did you leave out the locations now? I need some connection between register entry and the origin to be able to create a link. I can’t use the page numbers, since they don’t exist in the XML (and of course they make no sense there).

There is probably some more cleanup to do with respect to referencing (like with lists) but it takes time (till now I never really needed the export which started as a quick and dirty experiment and normally I need usage in projects to spend real time on such things.) Anyway. I've added some more register stuff, but not yet in the default css where the register is simply ignored (no time for that now). Maybe we should make a todo list for the export. It's not that complex but just takes time. New beta ... Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

Henning Hraban Ramm

5:46 a.m.

Am 2014-08-29 um 16:17 schrieb Hans Hagen :

...

...
Thank you for caring, the tag hierarchy is good now, but why did you leave out the locations now? I need some connection between register entry and the origin to be able to create a link. I can’t use the page numbers, since they don’t exist in the XML (and of course they make no sense there).

There is probably some more cleanup to do with respect to referencing (like with lists) but it takes time (till now I never really needed the export which started as a quick and dirty experiment and normally I need usage in projects to spend real time on such things.)

Anyway. I've added some more register stuff, but not yet in the default css where the register is simply ignored (no time for that now).

Thank you, I’ll see what I can make out of it. (I’ll try to trace every reference back to the chapter level, where I split output HTML files.)

...

Maybe we should make a todo list for the export. It's not that complex but just takes time.

Is there already a solution for \em (or \emph) and other switches? They don’t show up in export.xml. Greetlings, Hraban --- http://www.fiee.net/texnique/ http://wiki.contextgarden.net https://www.cacert.org (I'm an assurer)

Hans Hagen

6:46 a.m.

On 8/29/2014 1:46 PM, Henning Hraban Ramm wrote:

...

Am 2014-08-29 um 16:17 schrieb Hans Hagen :

...
...
Thank you for caring, the tag hierarchy is good now, but why did you leave out the locations now? I need some connection between register entry and the origin to be able to create a link. I can’t use the page numbers, since they don’t exist in the XML (and of course they make no sense there).

There is probably some more cleanup to do with respect to referencing (like with lists) but it takes time (till now I never really needed the export which started as a quick and dirty experiment and normally I need usage in projects to spend real time on such things.)

Anyway. I've added some more register stuff, but not yet in the default css where the register is simply ignored (no time for that now).

Thank you, I’ll see what I can make out of it. (I’ll try to trace every reference back to the chapter level, where I split output HTML files.)

...
Maybe we should make a todo list for the export. It's not that complex but just takes time.

Is there already a solution for \em (or \emph) and other switches? They don’t show up in export.xml.

use 'highlights' ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

Henning Hraban Ramm

30 Aug 30 Aug

1:56 a.m.

Am 2014-08-29 um 18:46 schrieb Hans Hagen :

...

...
Is there already a solution for \em (or \emph) and other switches? They don’t show up in export.xml.

use 'highlights'

Ah, of course, thanks. Forgot to copy my \definehighlight from the previous ebook project. Greetlings, Hraban --- http://www.fiee.net/texnique/ http://wiki.contextgarden.net https://www.cacert.org (I'm an assurer)

Henning Hraban Ramm

27 Aug 27 Aug

3:03 a.m.

Am 2014-08-26 um 23:08 schrieb Henning Hraban Ramm :

...

I’m at the moment working at ePub versions of my somgbooklets (using LilyPond) and have a bunch of XSL transformations plus shell script (Lua would have more style, I know) to automate as much as possible. That stuff is in a state of „works for me“, will try to flesh out the wiki page as soon as I’m content.

I made it an own page: http://wiki.contextgarden.net/Epub_Sample Greetlings, Hraban --- http://www.fiee.net/texnique/ http://wiki.contextgarden.net https://www.cacert.org (I'm an assurer)

Hans Hagen

26 Aug 26 Aug

12:04 p.m.

On 8/26/2014 5:07 PM, john Culleton wrote:

...

Context is moving toward accepting XML input, although the filtering process is necessarily complex. But what is also needed is a version of Context that produces well formed XML as an output. That would be a step toward producing a dual purpose document with Context, for print and for e-book use.

What do you mean with 'accepting' xml input? It accepts xml input already for many years. And in mkiv filtering is part of the game too.

...

Context users have invested time, often years, in learning how to write Context code. Writing XML is a whole other skillset, comparable to writing xhtml.

It's not so different if you're accustomed to structure.

...

So is writing a Context to XML converter a possibility? A probability? The commercial program InDesign already has such a capability.

There are export possibilities (and there will be a bit more). This is a topic at the upcoming ctx meeting (where we set priorities). Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

Thomas A. Schmitz

12:12 p.m.

On 26 Aug 2014, at 20:04, Hans Hagen wrote:

...

...
Context users have invested time, often years, in learning how to write Context code. Writing XML is a whole other skillset, comparable to writing xhtml.

It's not so different if you're accustomed to structure.

To chime in: xml input facilitates the separation of content and display. There are many tools which will validate xml as you type. Your context skills will not be lost - if you have invested years in learning to code, you will still be able to do this in your environment files. John's argument does not make sense to me. If someone new to context asked me, I think I would advise her or him to use xml input which is more versatile and easier to proofread for a beginner. And if one day in 20 years she decides she wants to use another tool for her files, it’s much easier to convert xml. Thomas

Procházka Lukáš Ing. - Pontex s. r. o.

27 Aug 27 Aug

8:03 a.m.

New subject: XML as source (was: E-books and XML)

Hello Thomas, I'm just curious: - Which editor(s) (including commercial one(s)) do you usually use to create XML source for Ctx? (Under Windows?) - XML input vs. .tex (.cld) source: IMHO, when one needs to program parts of Ctx source, it's better to use TeX source/language combined with Lua or CLD. Or - is it possible to program anyhow in XML source (Lua)? I have no practical experience with (manual) creation of XML input files for Ctx (yes, of course, there are some .xml sources generated by other programs). So, I can imagine one prepares source for Ctx as XML when he creates something "belletristic"-like; when one needs to process many products of other programs, plus to add comments, reports or so, something programmable is necessary; so, IMHO, XML might be useful for the latter case providing a) programming capabilities and b) good XML editor. Best regards, Lukas On Tue, 26 Aug 2014 20:12:25 +0200, Thomas A. Schmitz wrote:

...

On 26 Aug 2014, at 20:04, Hans Hagen wrote:

To chime in: xml input facilitates the separation of content and display. There are many tools which will validate xml as you type. Your context skills will not be lost - if you have invested years in learning to code, you will still be able to do this in your environment files. John's argument does not make sense to me. If someone new to context asked me, I think I would advise her or him to use xml input which is more versatile and easier to proofread for a beginner. And if one day in 20 years she decides she wants to use another tool for her files, it’s much easier to convert xml.

-- Ing. Lukáš Procházka | mailto:LPr@pontex.cz Pontex s. r. o. | mailto:pontex@pontex.cz | http://www.pontex.cz Bezová 1658 147 14 Praha 4 Tel: +420 241 096 751 Fax: +420 244 461 038

Jan Tosovsky

12:40 p.m.

New subject: XML as source (was: E-books and XML)

On 2014-08-27 Procházka Lukáš Ing. - Pontex s. r. o. wrote:

...

Which editor(s) (including commercial one(s)) do you usually use to create XML source for Ctx? (Under Windows?)

This is IMO the best you can currently get: http://www.oxygenxml.com/xml_author.html

...

- XML input vs. .tex (.cld) source:

IMHO, when one needs to program parts of Ctx source, it's better to use TeX source/language combined with Lua or CLD.

Or - is it possible to program anyhow in XML source (Lua)?

Most natural way for XML processing is XSLT transformation (kind of functional programming language). It is advisable to choose one of standardized vocabulary (DocBook, DITA, TEI) what give you a set of out-of-the-box XSLT stylesheets for common output formats. And in some tools, e.g. Oxygen, you can get additional level of comfort (various schema related functionality boosting your productivity) over using your own XML structure. In case of DocBook you can get even Context output using this XSLT set: http://dblatex.sourceforge.net/ (there is a dbcontext part in the download section) Actually, this is my way of using ConTeXt, but with various MKIV compatibility tweaks. From the same DocBook XML source I am producing epub and also WebHelp (set of HTML pages). http://docbook.sourceforge.net/release/xsl/current/webhelp/docs/ch01.html HTH, Jan

Mica Semrick

28 Aug 28 Aug

11:02 a.m.

New subject: XML as source (was: E-books and XML)

The best commercial XML editor is oxygenxml IMHO. If you need free, look at xmlmind. -m On August 27, 2014 7:03:06 AM PDT, "Procházka Lukáš Ing. - Pontex s. r. o." wrote:

...

Hello Thomas,

I'm just curious:

- Which editor(s) (including commercial one(s)) do you usually use to create XML source for Ctx? (Under Windows?)

- XML input vs. .tex (.cld) source:

IMHO, when one needs to program parts of Ctx source, it's better to use TeX source/language combined with Lua or CLD.

Or - is it possible to program anyhow in XML source (Lua)?

I have no practical experience with (manual) creation of XML input files for Ctx (yes, of course, there are some .xml sources generated by other programs).

So, I can imagine one prepares source for Ctx as XML when he creates something "belletristic"-like; when one needs to process many products of other programs, plus to add comments, reports or so, something programmable is necessary; so, IMHO, XML might be useful for the latter case providing a) programming capabilities and b) good XML editor.

Best regards,

Lukas

On Tue, 26 Aug 2014 20:12:25 +0200, Thomas A. Schmitz wrote:

...
On 26 Aug 2014, at 20:04, Hans Hagen wrote:

To chime in: xml input facilitates the separation of content and

display. There are many tools which will validate xml as you type. Your context skills will not be lost - if you have invested years in learning to code, you will still be able to do this in your environment files. John's argument does not make sense to me. If someone new to context asked me, I think I would advise her or him to use xml input which is more versatile and easier to proofread for a beginner. And if one day in 20 years she decides she wants to use another tool for her files, it’s much easier to convert xml.

-- Ing. Lukáš Procházka | mailto:LPr@pontex.cz Pontex s. r. o. | mailto:pontex@pontex.cz | http://www.pontex.cz Bezová 1658 147 14 Praha 4

Tel: +420 241 096 751 Fax: +420 244 461 038

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

john Culleton

27 Aug 27 Aug

8:38 a.m.

On Tue, 26 Aug 2014 20:12:25 +0200 "Thomas A. Schmitz" wrote:

...

On 26 Aug 2014, at 20:04, Hans Hagen wrote:

...
...
Context users have invested time, often years, in learning how to write Context code. Writing XML is a whole other skillset, comparable to writing xhtml.

It's not so different if you're accustomed to structure.

To chime in: xml input facilitates the separation of content and display. There are many tools which will validate xml as you type. Your context skills will not be lost - if you have invested years in learning to code, you will still be able to do this in your environment files. John's argument does not make sense to me. If someone new to context asked me, I think I would advise her or him to use xml input which is more versatile and easier to proofread for a beginner. And if one day in 20 years she decides she wants to use another tool for her files, it’s much easier to convert xml.

Thomas

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

_______________________________________________________ Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting http://www.doteasy.com

Some questions: What tool do you recommend for entering text etc. in XML format? I have the Bluefish Editor but usually code html in a plain editor (Gvim). I downloaded the manual "Dealing with XML in MKIV" but it presupposes that the user builds his own conversion system. And it is "still somewhat exerimental." Is there a conversion system already in place somewhere? For the beginner (me) is the MKII method easier to implement? -- John Culleton Wexford Press Free list of books for self-publishers: http://wexfordpress.net/shortlist.html PDF e-book: "Create Book Covers with Scribus" available at http://www.booklocker.com/books/4055.html

Schmitz Thomas A.

10:15 a.m.

On 27 Aug 2014, at 16:38, john Culleton wrote:

...

Some questions: What tool do you recommend for entering text etc. in XML format? I have the Bluefish Editor but usually code html in a plain editor (Gvim).

“Recommend” is too strong, because everything depends on the type of document you’re working on. I mainly use emacs + nxml mode. It validates on the fly, if your document is well defined, you can make it validate against a relax-ng scheme. To me, this is sufficient. I know that many serious users of nxml swear by oxygen. And I wouldn’t be surprised if Hans used his beloved Scite. (As for Lukas’s question: sorry, I don’t do Windows, I have no clue)

...

I downloaded the manual "Dealing with XML in MKIV" but it presupposes that the user builds his own conversion system. And it is "still somewhat exerimental." Is there a conversion system already in place somewhere?

I have been using it for a number of years now and have found it as stable as the rest of ConTeXt. Every once in a while, a bug will come up, and it will be fixed by Hans. Have you seen the wiki page about TEI xml and about processing xml with Lua? That should be a good start.

...

For the beginner (me) is the MKII method easier to implement?

No, I would say both are about equal in complexity, but the mkiv method is so much more powerful and consistent, I really wouldn’t bother with mkii anymore. One reason for me to use xml: I generate presentations, manuscripts, handouts from the same source (all with context). When I’m not typesetting the book myself, editors usually want some sort of word or libreoffice document. When my input is xml, it is relatively trivial to transform it to valid html and load that into libreoffice. Again: much depends on the type of document you’re working on. If every document you write is its own piece of art with numerous font effects and special typesetting needs on every page, I would stay with context syntax. But if your documents have a pretty predictable structure and you don’t expect to be forced to tweak individual page breaks, I would have a very long look at xml. I have grown to like it. If you have ever looked at a tex source document and tried to figure out where the missing brace in your }}}}}}}}}} orgy came from, you will love the tags and their nice nesting. Thomas

3608

Age (days ago)

3612

Last active (days ago)

List overview

Download

28 comments

9 participants

participants (9)

Hans Hagen
Henning Hraban Ramm
Jan Tosovsky
john Culleton
Mica Semrick
Procházka Lukáš Ing. - Pontex s. r. o.
Schmitz Thomas A.
Thomas A. Schmitz
Wolfgang Schuster