ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: Hans Hagen <j.hagen@xs4all.nl>
To: Denis Maier <maier.de@gmail.com>
Cc: mailing list for ConTeXt users <ntg-context@ntg.nl>
Subject: Re: XML roundtripping
Date: Wed, 15 May 2019 18:32:37 +0200	[thread overview]
Message-ID: <cb39a237-4d9d-7fdb-e896-1c805b0a5cea@xs4all.nl> (raw)
In-Reply-To: <CAMXdeGEfwCm-0AjxfiEvYX7BKeCojunaH3PX7QRkaHcLfowW+g@mail.gmail.com>

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 <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> | 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
-----------------------------------------------------------------
___________________________________________________________________________________
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://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : http://contextgarden.net
___________________________________________________________________________________

  parent reply	other threads:[~2019-05-15 16:32 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-14  7:38 Denis Maier
2019-05-15  7:19 ` Hans Hagen
2019-05-15 10:57   ` Denis Maier
2019-05-15 12:46     ` Hans Hagen
2019-05-15 14:35       ` Denis Maier
2019-05-15 15:45         ` Mica Semrick
2019-05-15 16:32         ` Hans Hagen [this message]
2019-05-15 20:31           ` Denis Maier
2019-05-16  7:40             ` Hans Hagen
     [not found]               ` <CAMXdeGGHdr0aevuJR6bb0YuKDomn_RtF1GRjJtfxiarNsf7cdQ@mail.gmail.com>
2019-05-16 11:28                 ` Denis Maier
2019-05-15 18:24         ` nyssus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cb39a237-4d9d-7fdb-e896-1c805b0a5cea@xs4all.nl \
    --to=j.hagen@xs4all.nl \
    --cc=maier.de@gmail.com \
    --cc=ntg-context@ntg.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).