Hmm, getting the page number back from the tuc file sound feasible. I'll have to look into this. But how would I write the information back to the XML? Is this explained somewhere? Am Mi., 15. Mai 2019 um 09:19 Uhr schrieb Hans Hagen :

...

Hi everyone

I am setting up a workflow for a journal where we will be using JATS XML as an input format. PDFs should be typeset via ConTeXt. Is roundtripping possible with ConTeXt? I will perhaps need to write page numbers back to a XML file (either to the input file or to a new file.). it all depends on where the number comes from; saving a number is a file

On 5/14/2019 9:38 AM, Denis Maier wrote: that later gets loaded by something else is no big deal

also, there is always the tuc file one can analyze

Hans

----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------

Our workflow is not settled yet; we're still discussing options. All depends upon what is possible ... That being said, for the purpose of displaying the articles online we'll need every article in a separate XML file. The question is if and how we will produce a PDF version containing a whole volume (we'll probably need one PDF for the whole volume and also PDFs for each article). One option would be: - merge the articles into a single XML, - typeset from there - split the PDF (Hence my question here, https://mailman.ntg.nl/pipermail/ntg-context/2019/095011.html). Another option could be: - Typeset each article individually. - Get the last page number => in the next article, set the first page number to this + 1 (So, we do not necessarily need to write the page numbers back to the XML, but we'll somehow need to pass the page number to the next article in the chain.) Am Mi., 15. Mai 2019 um 14:46 Uhr schrieb Hans Hagen :

On 5/15/2019 12:57 PM, Denis Maier wrote:

...

Hmm, getting the page number back from the tuc file sound feasible. I'll have to look into this.

But how would I write the information back to the XML? Is this explained somewhere? all depends on the workflow ... why does it need to be written back?

----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------

On 5/15/2019 4:35 PM, Denis Maier wrote:

Our workflow is not settled yet; we're still discussing options. All depends upon what is possible ...

That being said, for the purpose of displaying the articles online we'll need every article in a separate XML file. The question is if and how we will produce a PDF version containing a whole volume (we'll probably need one PDF for the whole volume and also PDFs for each article).

One option would be: - merge the articles into a single XML, - typeset from there - split the PDF (Hence my question here, https://mailman.ntg.nl/pipermail/ntg-context/2019/095011.html).

you can create a master xml file with includes and process the lots in one go ... this is quite convenient when you assemble for instance books from chapters that are split into sections ... you can make a xml file per chapter that includes the sections and then a book file that loads them all ... files can have a processing instruction telling what styel to load and you can run individual files or assemblies ... all the stuff needed to do that is there (and probably also documented someplace) anyway, you can always save '\lastpage' during a run ... or you can have some shared lua file with chapters/pagenumbers that gets updated by the current run all this is workflow dependent but all can be done without too much hassle (fwiw: we have some cases where for one projects hundreds of xml files get merged runtime and then processed ... the overhead is neglectable to the run)

Another option could be: - Typeset each article individually. - Get the last page number => in the next article, set the first page number to this + 1 (So, we do not necessarily need to write the page numbers back to the XML, but we'll somehow need to pass the page number to the next article in the chain.)

Am Mi., 15. Mai 2019 um 14:46 Uhr schrieb Hans Hagen mailto:j.hagen@xs4all.nl>:

On 5/15/2019 12:57 PM, Denis Maier wrote: > Hmm, getting the page number back from the tuc file sound feasible. I'll > have to look into this. > > But how would I write the information back to the XML? Is this explained > somewhere? all depends on the workflow ... why does it need to be written back?

-----------------------------------------------------------------                                            Hans Hagen | PRAGMA ADE                Ridderstraat 27 | 8061 GH Hasselt | The Netherlands         tel: 038 477 53 69 | www.pragma-ade.nl http://www.pragma-ade.nl | www.pragma-pod.nl http://www.pragma-pod.nl -----------------------------------------------------------------

-- ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------

On 5/15/2019 10:31 PM, Denis Maier wrote:

Hans Hagen mailto:j.hagen@xs4all.nl> schrieb am Mi., 15. Mai 2019, 18:32:

On 5/15/2019 4:35 PM, Denis Maier wrote: > Our workflow is not settled yet; we're still discussing options. All > depends upon what is possible ... > > That being said, for the purpose of displaying the articles online we'll > need every article in a separate XML file. The question is if and how we > will produce a PDF version containing a whole volume (we'll probably > need one PDF for the whole volume and also PDFs for each article). > > One option would be: > - merge the articles into a single XML, > - typeset from there > - split the PDF > (Hence my question here, > https://mailman.ntg.nl/pipermail/ntg-context/2019/095011.html).

you can create a master xml file with includes and process the lots in one go ... this is quite convenient when you assemble for instance books from chapters that are split into sections ... you can make a xml file per chapter that includes the sections and then a book file that loads them all ... files can have a processing instruction telling what styel to load and you can run individual files or assemblies ... all the stuff needed to do that is there (and probably also documented someplace)

Ok. Sounds good. How can I call the style in the xml files? I know that I can process a file with \xmlprocessfile or call it from the command line with --env=, and in a normal tex-file I could obviously use \environment for this,  but how does this work with xml?

<?context-directive job ctxfile somefile.ctx?> with "somefile.ctx" being: <?xml version='1.0' standalone='yes'?> ctx:job ctx:messageMy very special style ctx:process ctx:flags <!-- ctx:flag>purge</ctx:flag --> ctx:resources ctx:environmentwhatever.tex

anyway, you can always save '\lastpage' during a run ... or you can have some shared lua file with chapters/pagenumbers that gets updated by the current run

all this is workflow dependent but all can be done without too much hassle

(fwiw: we have some cases where for one projects hundreds of xml files get merged runtime and then processed ... the overhead is neglectable to the run)

> Another option could be: > - Typeset each article individually. > - Get the last page number => in the next article, set the first page > number to this + 1 > (So, we do not necessarily need to write the page numbers back to the > XML, but we'll somehow need to pass the page number to the next article > in the chain.) > > > Am Mi., 15. Mai 2019 um 14:46 Uhr schrieb Hans Hagen mailto:j.hagen@xs4all.nl > mailto:j.hagen@xs4all.nl>>: > >     On 5/15/2019 12:57 PM, Denis Maier wrote: >      > Hmm, getting the page number back from the tuc file sound >     feasible. I'll >      > have to look into this. >      > >      > But how would I write the information back to the XML? Is this >     explained >      > somewhere? >     all depends on the workflow ... why does it need to be written back? > > >     ----------------------------------------------------------------- >                                                 Hans Hagen | PRAGMA ADE >                     Ridderstraat 27 | 8061 GH Hasselt | The Netherlands >              tel: 038 477 53 69 | www.pragma-ade.nl http://www.pragma-ade.nl >     http://www.pragma-ade.nl | www.pragma-pod.nl http://www.pragma-pod.nl >     http://www.pragma-pod.nl >     ----------------------------------------------------------------- >

--

-----------------------------------------------------------------                                            Hans Hagen | PRAGMA ADE                Ridderstraat 27 | 8061 GH Hasselt | The Netherlands         tel: 038 477 53 69 | www.pragma-ade.nl http://www.pragma-ade.nl | www.pragma-pod.nl http://www.pragma-pod.nl -----------------------------------------------------------------

-- ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------