ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: Matthias Weber <matweber@indiana.edu>
Subject: Re: ConTeXt project structure?
Date: Tue, 29 Jul 2003 20:56:19 -0500	[thread overview]
Message-ID: <030855F4-C231-11D7-B01E-000A959AFACC@indiana.edu> (raw)
In-Reply-To: <200AE3E8-C1D3-11D7-BEE8-000A95901A7E@rna.nl>

I am so far almost completely happy with the following:


The top directory contains the layout file (s) and the main 'project 
file', and the litter TeX is producing.
The project file invokes the products (say a textbook for the screen, a 
printed textbook,  a solution manual, etc) which I put in
separate subdirectories to keep them out of the way. I also set 
specific options for the products (invoke color for the screen stuff 
etc)
in these product files only. The TeX sources for the actual texts are 
then separated into parts and chapters and sections within 
subdirectories of the
main directory. This allows me to work on a small portion of the 
project by working always in small directories, and keeping the
figures together. I can also modify a product relatively easily by 
changing its 'styles' without affecting other products.
So a product is for me an entity with coherent style and content. 
Products can share TeX sources and differ by style, or they can share
styles by use different sources.

My only complaint so far: As far as I understand it, context requires 
full path names relative to the main directory.
But probably I haven't figured it out yet...


Matthias

On Tuesday, July 29, 2003, at 09:44 AM, Gerben Wierda wrote:

> On Tuesday, Jul 22, 2003, at 14:05 Europe/Amsterdam, Willi Egger wrote:
>
>> Hi Gerben,
>>
>> The basic idea is not that complicated:
>>
>> The project(file) is the cuboard
>> The product(file)s are drawers of the cupboard
>> The component(file)s are boxes in one of the drawers whithin the 
>> cupboard.
>>
>> Teh environment is used to handle the whole project.
>>
>>> Is there a good example somewhere?
>>>
>> Whether is is a good example you will have to decide...
>
>> <project.tex>
>
> This helped, but I am not there yet. I would like to think of this in 
> a more concept-oriented idea
>
> A project contains all products created from the same sources
>
> A product us something that could ship separately. Hence a chapter is 
> generally not a product but a presentation versus a booklet is.
>
> A component is something with which you build products. You do not 
> ship these separately, but you may work on them separately. The 
> chapters of a book are natural components for me. I will never ship 
> chapter1.pdf but I might want to work on my book one chapter at a > time.
>
> In your example, a chapter is a product. You produce different what I 
> would call `products' by using different modes.
>
> That is confusing for me. Never mind the cupboard and drawers, I am 
> writing a book, in final, concept, screen formats as well as a 
> presentation. So, I would say, presentation and book are two different 
> products and final, concept and screen are different modes for product 
> book.
>
> And as an extra, I would like to use a good directory structure. But 
> the way ConTeXt searches, my product files need to be deeper nested 
> than my chapter sources. This is OK to me, but then the whole project 
> file loses its role because there has to be a copy of this in each 
> subdirectory.
>
> I am writing this, so ConTeXt experts can see the kind of confusion a 
> newbie like me can end up in.
>
> One more thing. ConTeXt relies heavily on texexec. Giving different 
> flags to texexec might be easy from the command line, but many 
> frontends have fixed typesetting commands you can choose from (e.g. 
> pdflatex and texexec --pdf). Having a different texexec call depending 
> on what you want may not be compatible with using a gui frontend, 
> unless the frontend enables setting a call per file (which makes it a 
> complicated frontend). I know I can set texexec stuff in teh first 
> line of a file, but I r ather not do that because other programs try 
> to do the same thing (we need a TeX-file preamble syntax, a bit like 
> PostScript has).
>
> G
>
> _______________________________________________
> ntg-context mailing list
> ntg-context@ntg.nl
> http://www.ntg.nl/mailman/listinfo/ntg-context
>
>

  reply	other threads:[~2003-07-30  1:56 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-22  9:14 Gerben Wierda
2003-07-22 12:05 ` Willi Egger
2003-07-22 13:35   ` Henning Hraban Ramm
2003-07-29 14:44   ` Gerben Wierda
2003-07-30  1:56     ` Matthias Weber [this message]
2003-09-03 15:55       ` Patrick Gundlach
2003-09-04 19:31         ` Hans Hagen
2003-09-04 21:19           ` Patrick Gundlach

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=030855F4-C231-11D7-B01E-000A959AFACC@indiana.edu \
    --to=matweber@indiana.edu \
    --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).