ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: "Jan U. Hasecke" <juh+ntg-context@mailbox.org>
To: mailing list for ConTeXt users <ntg-context@ntg.nl>
Subject: Rolling out a pandoc-context publication workflow in an organization
Date: Thu, 1 Jul 2021 08:02:48 +0200	[thread overview]
Message-ID: <08c5fc66-4b32-97fe-3ded-6ffe71b666c1@mailbox.org> (raw)


Dear all,

in the last weeks I asked more questions than I normally do. The reason 
is that my organization is discussing to roll out a 
markdown-pandoc-context publication workflow.

Some time ago we started to use context to produce flyers and some other 
documents. In fact I was the only one to use it. The results are so good 
that we discussed how to use it more often.

Currently we use LaTeX to produce our legal documents, terms of services 
etc. With ConTeXt we are able to meet our corporate design guidelines 
and to produce good looking and individually designed documents.

But our authors and editors were not willing to use ConTeXt directly so 
that we decided to look into Pandoc and use Markdown as authors input 
markup. Markdown is much better supported by text editors than ConTeXt.

The main problem for me is to come up with a good organization of the 
ConTeXt workflow so that it is easy usable and meets our requirements 
for quality management.

These are quite strict. We are a Debian based cooperative and the 
majority of our editors also use this distribution on their private 
computers. Some use a MacBook, only one uses of Windows.

For this reason we would like to stay with the Debian ConTeXt, which I 
never used as it is quite old. The same is true for Pandoc which made 
some improvements in the last years and also is very old in the current 
Debian distribution. As we did not decide this issue I can't say how 
much I have to refactor our styles to meet the older versions of ConTeXt.

Apart from this I have to organize our style files and ressources, anyway.

In another thread Hans said how to use these folders. Thanks a lot.

texmf-local   : maybe configurations
texmf-project : stuff you're working on (styles)
texmf-fonts   : fonts you downloaded or bought

All our styles and our shared image folder are versioned by git so I 
think that I either put links into texmf-project pointing to our style 
repository and to our image repository to have easy access to these 
ressources no matter how we call context or to put them into 
texmf-project directly. (We did not decide yet whether we call context 
from pandoc using a tmp directory for building or directly from our 
build script.

If we use the current lmtx distribution, all editors would have to 
install ConTeXt with the install.sh script on their private computers, 
then we would either call a post installation script to clone the 
repositories in texmf-project or to clone them in another folder and set 
links to texmf-project. Linking seems better as I am not sure what 
"context generate" would do with the .git folder inside the repositories.

All document projects are in their own repository. Currently we use a 
build script to call pandoc with an individual set of arguments 
including a custom context template which is stored in the document 
repository, also. Inside of this template we include all the 
environments we need for this particular document. We have a lot of 
small environments to reuse them in different document types.

This is our plan so far.

But to role out this successfully I would like to ease the way to a 
working pandoc-context installation for our editors. Do you have an idea 
how to do this?

I come up with the idea of an "organizational context distribution" that 
has all requirements preinstalled. That could look like this:

We have a repository:

hs.lmtx

which contains the install script and all our ressources (images and 
styles).

Our editors would clone the repository and just call the installation 
script to download the lmtx distribution. Afterwards they are ready to 
start as we would point to the right context executable in our build 
scripts.

Problem: What will happen if our editors do a git pull in hs.lmtx and a 
"context generate"? There are also concerns if something breaks after 
updating context with the install.sh. Is there a way to reset the 
installation to a given point release? How do you solve this in a 
production environment? On my private computer I sometimes install a new 
version of lmtx in a "staging" folder try it out and redo updating in my 
"production" folder.

I think I will try this out but I am happy if you have any comments on 
this.

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

             reply	other threads:[~2021-07-01  6:02 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-01  6:02 Jan U. Hasecke [this message]
2021-07-01  6:44 ` Taco Hoekwater
2021-07-01 11:31   ` Jan U. Hasecke
2021-07-01 12:00     ` Taco Hoekwater
2021-07-01 11:47   ` Aditya Mahajan
2021-07-01 23:07 ` Bruce Horrocks
2021-07-02  7:38   ` Jan U. Hasecke
2021-07-02  8:42     ` Hans Hagen
2021-07-02  9:56       ` Jan U. Hasecke
2021-07-02 11:17         ` Hans Hagen
2021-07-02 15:35         ` Aditya Mahajan
2021-07-02  7:49 ` denis.maier

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=08c5fc66-4b32-97fe-3ded-6ffe71b666c1@mailbox.org \
    --to=juh+ntg-context@mailbox.org \
    --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).