Hi, This is based on a question on tex.sx: http://tex.stackexchange.com/q/316504/323 In file-job.lua, we have: local processors = utilities.storage.allocate { ... [v_product] = { [v_text] = { "many", processfilemany }, [v_project] = { "once", processfileonce }, [v_environment] = { "once", processfileonce }, [v_product] = { "many", processfilemany }, [v_component] = { "many", processfilemany }, }, [v_component] = { [v_text] = { "many", processfilemany }, [v_project] = { "once", processfileonce }, [v_environment] = { "once", processfileonce }, [v_product] = { "none", processfilenone }, [v_component] = { "many", processfilemany }, } } Then, why is the product file processed multiple times? Aditya
On 6/24/2016 9:19 PM, Aditya Mahajan wrote:
Hi,
This is based on a question on tex.sx: http://tex.stackexchange.com/q/316504/323
In file-job.lua, we have:
local processors = utilities.storage.allocate { ... [v_product] = { [v_text] = { "many", processfilemany }, [v_project] = { "once", processfileonce }, [v_environment] = { "once", processfileonce }, [v_product] = { "many", processfilemany }, [v_component] = { "many", processfilemany }, }, [v_component] = { [v_text] = { "many", processfilemany }, [v_project] = { "once", processfileonce }, [v_environment] = { "once", processfileonce }, [v_product] = { "none", processfilenone }, [v_component] = { "many", processfilemany }, } }
Then, why is the product file processed multiple times?
because one might want to combine products (controlled by modes giving different results) .. mostly downward compatible ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Aditya Mahajan mailto:adityam@umich.edu 24. Juni 2016 um 21:19 Hi,
This is based on a question on tex.sx: http://tex.stackexchange.com/q/316504/323
In file-job.lua, we have:
local processors = utilities.storage.allocate { ... [v_product] = { [v_text] = { "many", processfilemany }, [v_project] = { "once", processfileonce }, [v_environment] = { "once", processfileonce }, [v_product] = { "many", processfilemany }, [v_component] = { "many", processfilemany }, }, [v_component] = { [v_text] = { "many", processfilemany }, [v_project] = { "once", processfileonce }, [v_environment] = { "once", processfileonce }, [v_product] = { "none", processfilenone }, [v_component] = { "many", processfilemany }, } }
Then, why is the product file processed multiple times? The rules for a component files are applied *after* \startcomponent which isn’t the case for the example where in the first iteration the "text" rules are applied and in the following iteration the rules for a product file.
Moving \product … after \startcomponent prevents the loop but the environment won’t be loaded anymore because the product file isn’t loaded anymore. Wolfgang
On Sat, 25 Jun 2016, Wolfgang Schuster wrote:
Aditya Mahajan mailto:adityam@umich.edu 24. Juni 2016 um 21:19 Hi,
This is based on a question on tex.sx: http://tex.stackexchange.com/q/316504/323
In file-job.lua, we have:
local processors = utilities.storage.allocate { ... [v_product] = { [v_text] = { "many", processfilemany }, [v_project] = { "once", processfileonce }, [v_environment] = { "once", processfileonce }, [v_product] = { "many", processfilemany }, [v_component] = { "many", processfilemany }, }, [v_component] = { [v_text] = { "many", processfilemany }, [v_project] = { "once", processfileonce }, [v_environment] = { "once", processfileonce }, [v_product] = { "none", processfilenone }, [v_component] = { "many", processfilemany }, } }
Then, why is the product file processed multiple times? The rules for a component files are applied *after* \startcomponent which isn’t the case for the example where in the first iteration the "text" rules are applied and in the following iteration the rules for a product file.
Moving \product … after \startcomponent prevents the loop but the environment won’t be loaded anymore because the product file isn’t loaded anymore.
So, what's the recommended alternative? One could move the \environment to the components, but that can lead to a lot of repetitions (if there are many environments). Aditya
On 6/25/2016 10:42 AM, Aditya Mahajan wrote:
On Sat, 25 Jun 2016, Wolfgang Schuster wrote:
Aditya Mahajan mailto:adityam@umich.edu 24. Juni 2016 um 21:19 Hi,
This is based on a question on tex.sx: http://tex.stackexchange.com/q/316504/323
In file-job.lua, we have:
local processors = utilities.storage.allocate { ... [v_product] = { [v_text] = { "many", processfilemany }, [v_project] = { "once", processfileonce }, [v_environment] = { "once", processfileonce }, [v_product] = { "many", processfilemany }, [v_component] = { "many", processfilemany }, }, [v_component] = { [v_text] = { "many", processfilemany }, [v_project] = { "once", processfileonce }, [v_environment] = { "once", processfileonce }, [v_product] = { "none", processfilenone }, [v_component] = { "many", processfilemany }, } }
Then, why is the product file processed multiple times? The rules for a component files are applied *after* \startcomponent which isn’t the case for the example where in the first iteration the "text" rules are applied and in the following iteration the rules for a product file.
Moving \product … after \startcomponent prevents the loop but the environment won’t be loaded anymore because the product file isn’t loaded anymore.
So, what's the recommended alternative? One could move the \environment to the components, but that can lead to a lot of repetitions (if there are many environments).
i always use one main environment (that can include others) and putting an \environment on top of a component is then not much overhead (compared to getting the content done) Hans -- ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On Sat, 25 Jun 2016, Hans Hagen wrote:
So, what's the recommended alternative? One could move the \environment to the components, but that can lead to a lot of repetitions (if there are many environments).
i always use one main environment (that can include others) and putting an \environment on top of a component is then not much overhead (compared to getting the content done)
So, to a newcomer, one can suggest to simply use components and environments. What is the advatange of the extra structure provided by product/project? Aditya
Aditya Mahajan mailto:adityam@umich.edu 25. Juni 2016 um 18:37 On Sat, 25 Jun 2016, Hans Hagen wrote:
So, to a newcomer, one can suggest to simply use components and environments. What is the advatange of the extra structure provided by product/project? A product is the book itself while components are only chapters, sections etc. (components can be nested).
Wolfgang
On Sat, 25 Jun 2016, Wolfgang Schuster wrote:
Aditya Mahajan mailto:adityam@umich.edu 25. Juni 2016 um 18:37 On Sat, 25 Jun 2016, Hans Hagen wrote:
So, to a newcomer, one can suggest to simply use components and environments. What is the advatange of the extra structure provided by product/project? A product is the book itself while components are only chapters, sections etc. (components can be nested).
Does that mean products cannot be nested? Even if a component is part of a product, the component must explicitly include all the environments needed for compilation (rather than simply refering to a product, as in the original question). So, I don't structurally see an advantage of the product-component distinction. Since this is an old mechanism and widely used (though I have never used it), I am missing something. The wiki page is woefully out of date with the current behavior. Aditya
Hans Hagen mailto:pragma@wxs.nl 25. Juni 2016 um 11:56
i always use one main environment (that can include others) and putting an \environment on top of a component is then not much overhead (compared to getting the content done) The problem with puttins \environment before \startcomponents is that you can’t check for the *component mode which is enabled after the environment was loaded.
Wolfgang
On Sat, 25 Jun 2016, Wolfgang Schuster wrote:
Hans Hagen mailto:pragma@wxs.nl 25. Juni 2016 um 11:56
i always use one main environment (that can include others) and putting an \environment on top of a component is then not much overhead (compared to getting the content done) The problem with puttins \environment before \startcomponents is that you can’t check for the *component mode which is enabled after the environment was loaded.
So, one should use: \startcomponent * \environment env ... \stopcomponent for both components and products? Aditya
Hello,
my "how-I-do-it" used for typesetting a large book was:
---- styles.sty
% Styles, settings etc.; never compiled individually, thus ".sty"; the file also doesn't use '\startenvironment' ... '\stopenvironment' commands (I even don't know whether such commands exist; anyway, I didn't need them)
\mainlanguage[cz]
...
----
---- book.tex
% Main file to build the whole book
\environment styles.sty
\startproduct *
\startfrontmatter
...
\stopfrontmatter
\startbodymatter
\component comp01
...
\stopbodymatter
\stopproduct
---- comp01.tex
% One of components; can be compiled individually, but sections are not numbered from the point of view of the final document (= book.tex) ("globally") but "locally" from the point of view of just comp01.tex
\environment styles.sty
\startcomponent *
...
\stopcomponent
Resume:
- Environment file 'styles.sty' is included in the product file and ALSO in all component files.
- Environment file is included AHEAD OF any \start{product|component}.
- Product file can be successfully compiled.
- Single components can be compiled successfully, too; sections here are NOT NUMBERED as in the final document.
- There no need to use "project" ability.
That's how I used and I understood component/product/project/environment structure in my project (book).
But a better way may exist (or might be intended).
Best regards,
Lukas
On Sat, 25 Jun 2016 19:25:32 +0200, Aditya Mahajan
On Sat, 25 Jun 2016, Wolfgang Schuster wrote:
Hans Hagen mailto:pragma@wxs.nl 25. Juni 2016 um 11:56
i always use one main environment (that can include others) and putting an \environment on top of a component is then not much overhead (compared to getting the content done) The problem with puttins \environment before \startcomponents is that you can’t check for the *component mode which is enabled after the environment was loaded.
So, one should use:
\startcomponent * \environment env ... \stopcomponent
for both components and products?
Aditya
-- Ing. Lukáš Procházka | mailto:LPr@pontex.cz Pontex s. r. o. | mailto:pontex@pontex.cz | http://www.pontex.cz Bezová 1658 147 14 Praha 4 Tel: +420 241 096 751 Fax: +420 244 461 038
On Mon, 11 Jul 2016 13:01:58 +0200
Procházka Lukáš Ing.
- Single components can be compiled successfully, too; sections here are NOT NUMBERED as in the final document.
A nagging question that I have always had about structure is that it would be rather nice if compiling a component that is part of a product could use the .tuc information from an earlier compiling of the entire product (if present) for numbering. Of course, modifying a component (such as a chapter) might or would have an effect on all other components of the product, but such is life. In a large book product, working on a single chapter would be useful, and getting the numbering at least close to correct is desirable. Alan
On 6/25/2016 7:13 PM, Wolfgang Schuster wrote:
Hans Hagen mailto:pragma@wxs.nl 25. Juni 2016 um 11:56
i always use one main environment (that can include others) and putting an \environment on top of a component is then not much overhead (compared to getting the content done) The problem with puttins \environment before \startcomponents is that you can’t check for the *component mode which is enabled after the environment was loaded.
indeed, but i can't remember having done such tests Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
participants (5)
-
Aditya Mahajan -
Alan BRASLAU -
Hans Hagen -
Procházka Lukáš Ing. -
Wolfgang Schuster