Re: [NTG-context] filter module / externalizing TikZ graphics

Am 30.01.2021 um 00:13 schrieb Aditya Mahajan :

For \processFILTER, t-filter does not even read the file... so it has to do with how the filtercommand is defined.

...

Since this fails already, I don’t know if \processFILTERfile also uses bufferbefore/-after (it should).

It does not. As I said, for processing external files, t-filter does not even read the file and just takes care of caching the result. It is assumed that the filter command can process the external file.

A pity. I didn’t understand that from the documentation. That means I need to setup different filters for internal and external graphics with the same content.

I can see if it is possible to active before and after filters while processing external files.

That would solve this problem for me and would make the behavior of filter commands more consistent. OTOH I can understand you don’t want to bloat your module.

Another option is to write the external files as valid tex file (i.e., with a \startTEXpage .. \stopTEXpage wrapper), and when defining the filtercommand, use something like `context --environment=env filename`, where env is the environment file with all the settings for fonts etc.

I don’t see this as an option, as we try to avoid code duplication over hundreds of graphics snippets. The \start/stop environment, as well as external files, should just contain the TikZ commands. All common setup/teardown code belongs in extra files/buffers.

...

(2) working directory

Since ConTeXt can’t put generated (temporary) files into a directory and --result also only renames afterwards, the directory key doesn’t help, I had to add "mv" and "cd" to my filtercommand. I didn’t check yet if caching works.

Caching should work if \definefilter is configured correctly.

Thanks.

From the point of view of t-filter module, this is a bug in the external program and you should contact upstream for a fix :-)

Yes. There were already several requests about ConTeXt using work/temp directories and changing the behavior of "--result".

Most (all?) other programs are happy to write a file in any directory (modulo write permissions, etc.).

I do not want to increase the complexity of the module to handle such corner cases.

I can understand that. I should probably let filter call an external script, or fork t-filter for my needs.

...

If I use \starttikz[name=example], I get "JOBNAME-temp-tikzThick-example.tmp". I’d like to get something like "COMPONENTNAME-##-example.tmp" or a path like "COMPONENTNAME/example_##.tmp". Is there a configuration hook in the module to change name generation?

No. I don't quite understand the concern. How do you plan to use a `name=value` option?

The current auto-generated file names are uncomfortably long, and I’d like to know which contains what. I’m not yet sure what would make the most sense for this project (at least sorting by chapter/component would), but I have an use case with LilyPond where I could save several LilyPond compile runs if I could influence the naming: I got ~500 songs in their own component files, and I use them in different songbooklets with the same layout. E.g. there’s one containing all the songs and several with a subject (e.g. winter & christmas, children, medieval & fantasy, some author...). They all use [name=\currentcomponent]. If I could avoid the JOBNAME part of the file name, all booklets would use the same note PDFs. Now, the temp directory contains literally thousands of files. Since this is just for fun, the additional space and compile time is just a bit annoying and doesn’t affect others, but I like to streamline my workflows...

...

(4) subprocess parameters

I’d like to forward some parameters from \starttikz to the temp buffer, e.g. \starttikz[name=example][mystyle=thick] (using the same syntax as \startsection with a second pair of brackets for custom parameters). And then have \starttikzpicture[\filterusersetupvariable{mystyle}] in the buffer.

My workaround so far is a copy of the filter setup (tikz/tikzThick), since we have only a few different configurations.

The code that I had posted already handles this, provided that the options start on the line after \startfilter:

Ah, I didn’t look closely enough. Thank you, that’s an usable workaround. Best, Hraban