Am 04.10.2018 um 09:27 schrieb Taco Hoekwater :

...

According to my understanding I should be able to context c_01 to get one chapter context prd_A to get one product context project_ecm to get the whole book.

Any whole book should be a product, and the Parts should just be components. The project level is only there to connect meta-info across a book series. You are not supposed to run ‘context’ on the project file.

I see. I’ll probably keep it as three books. It’s easy to change later as long as the components have different names. Right now that’s just a limitation of the word processor.

That said, it is definitely not your installation or understanding of the wiki page that creates the circular inclusion. The same happens here. I discovered it works OK if I move the \product to within the \startcomponent, and I assume that is how it supposed to work:

\startcomponent \product prd_1 … \stopcomponent

Works here as well, thank you. What about the project? Right now it is outside the \start{product|component} and it works. Now it is inside the \start{product|component} and it works as well. Next question: Should the environment be inside \startproject \stopproject? It seems to make no difference. Thus having the whole file inside \start{project|product|component} \stop… would be a good idea and consistent.

At a guess, I think the wiki page is wrong. But before editing that, I would like to have confirmation of the above assumption.

Thanks for the quick response, now I can tell pandoc to convert the book to context:-) Greetings Axel

Am 04.10.2018 um 20:59 schrieb Henning Hraban Ramm :

Am 2018-10-04 um 10:08 schrieb Axel Kielhorn :

...

Thus having the whole file inside \start{project|product|component} \stop… would be a good idea and consistent.

That’s what I do. Since I wrote that wiki page (some years ago) I’ll change it.

I appreciate that. How about offering a skeleton project for download? Here is my corrected ECM with the following README: This is a skeleton project. You can copy it and change the files to contain your content. The top level project collects metatdata to make all products have the same layout. It is not meant to be processed by context. The products are used to generate the whole book, but you can process each component seperately to reduce the processing time. Greetings Axel

I took a look at your example files and there a few things which can be improved. Product file: 1. You don’t need the actual name of the current file and use * instead 2. You can use brackets as delimiters for the file name instead of a space after the name 3. In products you can put all content in a document environment which has hooks to insert text etc. at the begin and end of the document (which can be used to insert a titlepage or endpage). You can even use \startdocument (or \setupdocument) to set the document name in the pdf viewer (yes it can also be done with \setupinteraction but \startdocument is nicer). A minimal file would be     \startproduct [*]     \project [project_skel]     \startdocument     \component [c_01]     \component [c_02]     \stopdocument     \stopproduct or     \startproduct [*]     \project [project_skel]     \startdocument     \startbodymatter     \component [c_01]     \component [c_02]     \stopbodymatter     \stopdocument     \stopproduct Environment file: 1. Don’t load the project from your environment file 2. Don’t use \usepath to set the folders for the product files, use it instead to set the folders for your component files which are loaded from the products 3. You can remove the braces around the subfolder which aren’t necessary. Wolfgang Axel Kielhorn schrieb am 05.10.18 um 08:31:

...

Am 04.10.2018 um 20:59 schrieb Henning Hraban Ramm :

Am 2018-10-04 um 10:08 schrieb Axel Kielhorn :

...

Thus having the whole file inside \start{project|product|component} \stop… would be a good idea and consistent. That’s what I do. Since I wrote that wiki page (some years ago) I’ll change it. I appreciate that.

How about offering a skeleton project for download?

Here is my corrected ECM with the following README:

This is a skeleton project. You can copy it and change the files to contain your content.

The top level project collects metatdata to make all products have the same layout. It is not meant to be processed by context.

The products are used to generate the whole book, but you can process each component seperately to reduce the processing time.

Greetings Axel

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

Axel Kielhorn schrieb am 05.10.18 um 18:44:

...

Am 05.10.2018 um 17:33 schrieb Wolfgang Schuster :

I took a look at your example files and there a few things which can be improved.

Product file:

1. You don’t need the actual name of the current file and use * instead

2. You can use brackets as delimiters for the file name instead of a space after the name Does this mean I can use a space in the filename?

It’s possible but the safer method is to use a underscore or hyphen in file names.

...

3. In products you can put all content in a document environment which has hooks to insert text etc. at the begin and end of the document (which can be used to insert a titlepage or endpage). You can even use \startdocument (or \setupdocument) to set the document name in the pdf viewer (yes it can also be done with \setupinteraction but \startdocument is nicer).

A minimal file would be

\startproduct [*]

\project [project_skel]

\startdocument

\component [c_01] \component [c_02]

\stopdocument

\stopproduct

or [..]

...

Environment file:

1. Don’t load the project from your environment file

2. Don’t use \usepath to set the folders for the product files, use it instead to set the folders for your component files which are loaded from the products Does this mean that I should use a product level environment file for the \usepath? (Accessing things like ../img_global?)

With \usepath (and \usesubpath) you can set folders which are searched when you use the \component command to load chapters etc. in your product (or component) files. To load images from other folder you use \setupexternalfigure[directory=...] where you can also use "../images" to load them from a global folder for all documents in your project. Wolfgang