improve bad habits deduplicate redundant defined values

juh

15 Sep 2021 15 Sep '21

8:40 a.m.

Dear all, these are quite general questions but here they come. I defined modular styles for an organisation so that we can use different layouts with the same look and feel but still have many options to change things in a special document. I have styles for colors, fonts which are used everywhere but also styles for heads that are only used in legal context and other heads-styles used in other contexts. This works brilliant. I can even overwrite styles for one document only. I'd like to name this a cascading approach. While doing this I learned a lot and changed the way the style files are organised from time to time. Currently I start with colors and fonts. Then comes the page dimension definitions, makeups, headers and footers, headlines, the toc styles, lists and tables. Does anyone has a similar approach with a strong opinion how to organise the cascade? While working on this I often found that I defined something twice, because I forgot to delete a setup-command in a newly structured file. Is there a way to test this? Can I grep for a warning in the log files to find these duplicates? Mit freundlichen Grüßen Jan Ulrich Hasecke -- Autoren-Homepage: ......... http://literatur.hasecke.com Satiren & Essays: ......... http://www.sudelbuch.de Privater Blog: ............ http://www.hasecke.eu Netzliteratur-Projekt: .... http://www.generationenprojekt.de

Attachments:

signature.asc (application/pgp-signature — 833 bytes)

Show replies by date

Hans Hagen

15 Sep 15 Sep

8:59 a.m.

On 9/15/2021 8:40 AM, juh via ntg-context wrote:

...

Dear all,

these are quite general questions but here they come.

I defined modular styles for an organisation so that we can use different layouts with the same look and feel but still have many options to change things in a special document. I have styles for colors, fonts which are used everywhere but also styles for heads that are only used in legal context and other heads-styles used in other contexts. This works brilliant. I can even overwrite styles for one document only. I'd like to name this a cascading approach.

While doing this I learned a lot and changed the way the style files are organised from time to time.

Currently I start with colors and fonts. Then comes the page dimension definitions, makeups, headers and footers, headlines, the toc styles, lists and tables.

the order sounds ok to me

...

Does anyone has a similar approach with a strong opinion how to organise the cascade?

if you use xml, that one comes last

...

While working on this I often found that I defined something twice, because I forgot to delete a setup-command in a newly structured file.

Is there a way to test this? Can I grep for a warning in the log files to find these duplicates? You can try this at the top:

%enabledirectives[overloadmode=warning] \enabledirectives[overloadmode=error] it's still sort of 'work in progress' (esp instances), so \defineitemgroup[xxx] \definehead[xxx] will trigger an error (more commands will get the option to control what gets defined automatically) you can work around warnings/errors with \pushoverloadmode new definition \popoverloadmode bt keep in mind that some older settings can be persistent Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------

denis.maier＠unibe.ch

16 Sep 16 Sep

10:09 a.m.

Hi Jan Ulrich, I have not much to contribute, but I'd be very happy to learn more about your setup. Best, Denis

...

-----Ursprüngliche Nachricht----- Von: ntg-context Im Auftrag von juh via ntg- context Gesendet: Mittwoch, 15. September 2021 08:40 An: mailing list for ConTeXt users Cc: juh Betreff: [NTG-context] improve bad habits deduplicate redundant defined values

Dear all,

these are quite general questions but here they come.

I defined modular styles for an organisation so that we can use different layouts with the same look and feel but still have many options to change things in a special document. I have styles for colors, fonts which are used everywhere but also styles for heads that are only used in legal context and other heads-styles used in other contexts. This works brilliant. I can even overwrite styles for one document only. I'd like to name this a cascading approach.

While doing this I learned a lot and changed the way the style files are organised from time to time.

Currently I start with colors and fonts. Then comes the page dimension definitions, makeups, headers and footers, headlines, the toc styles, lists and tables.

Does anyone has a similar approach with a strong opinion how to organise the cascade?

While working on this I often found that I defined something twice, because I forgot to delete a setup-command in a newly structured file.

Is there a way to test this? Can I grep for a warning in the log files to find these duplicates?

Mit freundlichen Grüßen Jan Ulrich Hasecke

-- Autoren-Homepage: ......... http://literatur.hasecke.com Satiren & Essays: ......... http://www.sudelbuch.de Privater Blog: ............ http://www.hasecke.eu Netzliteratur-Projekt: .... http://www.generationenprojekt.de

Jan Ulrich Hasecke

17 Sep 17 Sep

10:36 a.m.

Am Thu, Sep 16, 2021 at 08:09:50AM +0000 schrieb denis.maier@unibe.ch:

...

Hi Jan Ulrich,

I have not much to contribute, but I'd be very happy to learn more about your setup.

You asked for it. ;-) I started more than two years ago, with some documents for my cooperative. I blogged about it: https://www.hasecke.eu/post/werbemittel-mit-context-gestalten/ Step by step I modularized my setup to reuse as many definitions as possible in other documents. I started with our corporate colors and fonts and then added page sizes, headlines etc. This is an ongoing process as I have no overall plan to structure my setup. It is work in progress. And the tendency is to split up environment files into smaller ones. When I see that I need another numbering system for legal texts like bylaws I create an environment for legal numbering and for normal numbering. I think that all this will end up in 20-30 environment files going from general things like colors, fonts, page sizes to more specific things like doubleside-headers-footers, singleside-headers-footers to product specific things like env-factsheet for things that are special to factsheets only. Here are some of my environment files: hs.env-2-seiter-din-lang-hoch.tex hs.env-2-seiter-din-lang-quer.tex hs.env-6-seiter-din-lang.tex hs.env-bleed.tex hs.env-chapter-section-subsection-toc.tex hs.env-chapter-section-toc.tex hs.env-chapter-toc.tex hs.env-colors.tex hs.env-coverpages.tex hs.env-din-a4.tex hs.env-din-brief-footer.tex hs.env-din-lang-hoch.tex hs.env-din-lang-quer.tex hs.env-doubleside-formal-header-footer.tex hs.env-doubleside-header-footer.bak hs.env-elemente.tex hs.env-factsheet.tex hs.env-flyer.tex hs.env-fonts.tex hs.env-handout.tex hs.env-headlines.tex hs.env-kapitelnummerierung-gemeinwohl.tex hs.env-kapitelnummerierung-satzung.tex hs.env-lists-legal.tex hs.env-lists.tex hs.env-makeups.tex hs.env-paragraphs.tex hs.env-singleside-formal-header-footer.tex hs.env-singleside-header-footer.tex hs.env-tabellen.tex It took a long time until I realized that these files are best stored in texmf-project. I use namespaces like hs. and juh. to separate the environment files of my cooperative and my own files. Our editors are using Markdown so we are currently creating a process to go from Markdown via Pandoc to ConTeXT. We heavily use custom pandoc templates, where the used environment files are listed. For each project we have such a directory structure: build.sh # the build script source/ # here are markdown files in their project directory # (source/foo/foo.md) control/ # here we story YAML-files for the pandoc options # and the ConTeXt templates. The pdf is built with: ./build foo A project can have multiple documents. A project eg. are business reports or factsheets. As we use Pandoc we could create HTML and EPUB files as well, but currently we use Hugo to create HTML files. As I am not a programmer the biggest task are lua scripts which alters the output of Pandoc when we need something special. Eg. we managed to insert \startstopparagraph[foo] command into the ConTeXt source by this simple markdown code: normal paragraph :::foo special foo paragraph yet special paragraph ::: normal paragraph Often I simply insert raw context code into the markdown source if I want something special, but all this finally should go into ::: directives. Mit freundlichen Grüßen Jan Ulrich Hasecke -- Autoren-Homepage: ......... http://literatur.hasecke.com Satiren & Essays: ......... http://www.sudelbuch.de Privater Blog: ............ http://www.hasecke.eu Netzliteratur-Projekt: .... http://www.generationenprojekt.de

denis.maier＠unibe.ch

18 Sep 18 Sep

2:57 p.m.

...

-----Ursprüngliche Nachricht----- Von: ntg-context Im Auftrag von Jan Ulrich Hasecke via ntg-context Gesendet: Freitag, 17. September 2021 10:37 An: ntg-context@ntg.nl Cc: Jan Ulrich Hasecke Betreff: Re: [NTG-context] improve bad habits deduplicate redundant defined values

Am Thu, Sep 16, 2021 at 08:09:50AM +0000 schrieb denis.maier@unibe.ch:

...
Hi Jan Ulrich,

I have not much to contribute, but I'd be very happy to learn more about your setup.

You asked for it. ;-)

Thanks for your detaillled description of you setup.

...

I started more than two years ago, with some documents for my cooperative. I blogged about it: https://www.hasecke.eu/post/werbemittel-mit-context- gestalten/

Yeah, I know that post and, by the way, I've used your approach yesterday for converting an Indesign-Template to ConTeXt. Thanks!

...

Step by step I modularized my setup to reuse as many definitions as possible in other documents. I started with our corporate colors and fonts and then added page sizes, headlines etc.

This is an ongoing process as I have no overall plan to structure my setup. It is work in progress. And the tendency is to split up environment files into smaller ones.

Looks like I need to refactor some things :-)

...

When I see that I need another numbering system for legal texts like bylaws I create an environment for legal numbering and for normal numbering.

Ok. So in general you deal with diverging demands by creating new environments that you can load selectively? I currently struggle with a similar question: In one project I typeset articles for a journal from XML sources with ConTeXt. Obviously, these articles should rely on the same environment files. But how would you deal with those cases where you'd need a slightly different table layout in one article?

...

I think that all this will end up in 20-30 environment files going from general things like colors, fonts, page sizes to more specific things like doubleside- headers-footers, singleside-headers-footers to product specific things like env- factsheet for things that are special to factsheets only.

Here are some of my environment files:

hs.env-2-seiter-din-lang-hoch.tex [...] It took a long time until I realized that these files are best stored in texmf- project. I use namespaces like hs. and juh. to separate the environment files of my cooperative and my own files.

Interesting. I think I'll need to adopt something similar...

...

Our editors are using Markdown so we are currently creating a process to go from Markdown via Pandoc to ConTeXT. We heavily use custom pandoc templates, where the used environment files are listed. [...]

As I am not a programmer the biggest task are lua scripts which alters the output of Pandoc when we need something special.

Eg. we managed to insert \startstopparagraph[foo] command into the ConTeXt source by this simple markdown code:

Why do you use \startstopparagraph[foo] instead of \startstopfoo for theses cases?

...

normal paragraph

:::foo special foo paragraph yet special paragraph :::

normal paragraph

Often I simply insert raw context code into the markdown source if I want something special, but all this finally should go into ::: directives.

Mit freundlichen Grüßen Jan Ulrich Hasecke

-- Autoren-Homepage: ......... http://literatur.hasecke.com Satiren & Essays: ......... http://www.sudelbuch.de Privater Blog: ............ http://www.hasecke.eu Netzliteratur-Projekt: .... http://www.generationenprojekt.de

Thanks again, Denis

Jan Ulrich Hasecke

3:52 p.m.

Am Sat, Sep 18, 2021 at 12:57:36PM +0000 schrieb denis.maier@unibe.ch:

...

Ok. So in general you deal with diverging demands by creating new environments that you can load selectively? I currently struggle with a similar question: In one project I typeset articles for a journal from XML sources with ConTeXt. Obviously, these articles should rely on the same environment files. But how would you deal with those cases where you'd need a slightly different table layout in one article?

We had this slightly change with headline numbering. Default in our reports is arabic numbers but in one report we need a mix of capital letters and numbers (A, A.1, A.2, B, B.1 etc.) I simply made two small style files for numbering.

...

...
It took a long time until I realized that these files are best stored in texmf- project. I use namespaces like hs. and juh. to separate the environment files of my cooperative and my own files.

Interesting. I think I'll need to adopt something similar...

My main concern now is to deploy ConTeXt to multiple users. If some would go with Texlive distributions from debian stable and some with lmtx distribution there would be a mess sooner or later. So I decided that we all go with the lmtx distribution and clone our git repos for images and styles into texmf-project. I also have something in texmf-local, namely icc files and the module statistical-charts. I don't know how to decide what goes to project and what to local.

...

...
Eg. we managed to insert \startstopparagraph[foo] command into the ConTeXt source by this simple markdown code:

Why do you use \startstopparagraph[foo] instead of \startstopfoo for theses cases?

Good question. \startstopparagraph was more explicit I think. But now that you ask I think, that with startstopfoo we might succeed with one lua filter for a lot more context constructs such as makeups etc. juh -- Autoren-Homepage: ......... http://literatur.hasecke.com Satiren & Essays: ......... http://www.sudelbuch.de Privater Blog: ............ http://www.hasecke.eu Netzliteratur-Projekt: .... http://www.generationenprojekt.de

Hans Hagen

4:16 p.m.

On 9/18/2021 2:57 PM, Denis Maier via ntg-context wrote:

...

Ok. So in general you deal with diverging demands by creating new environments that you can load selectively? I currently struggle with a similar question: In one project I typeset articles for a journal from XML sources with ConTeXt. Obviously, these articles should rely on the same environment files. But how would you deal with those cases where you'd need a slightly different table layout in one article?

one can always use 'modes' (andf run with --mode) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------

Henning Hraban Ramm

7:48 p.m.

...

Am 18.09.2021 um 14:57 schrieb Denis Maier via ntg-context : I currently struggle with a similar question: In one project I typeset articles for a journal from XML sources with ConTeXt. Obviously, these articles should rely on the same environment files. But how would you deal with those cases where you'd need a slightly different table layout in one article?

You could just use a few setup commands in that article, but an additional environment file is the cleaner solution. In our humanities book series* I need an additional environment for every book, since the single volumes aren’t as similar as I expected... Hraban *) https://www.dreiviertelhaus.de/reihen/eka/

1061

Age (days ago)

1064

Last active (days ago)

List overview

Download

7 comments

5 participants

participants (5)

denis.maier＠unibe.ch
Hans Hagen
Henning Hraban Ramm
Jan Ulrich Hasecke
juh

improve bad habits deduplicate redundant defined values

tags

participants (5)