> Am 30.01.2021 um 00:13 schrieb Aditya Mahajan <adit...@umich.edu>:
>
> 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
___________________________________________________________________________________
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
___________________________________________________________________________________
