Automatic image width for folds (e.g. TikZ) works, but is overridden by 0.618par default

#1

When creating an embedded TikZ figure using Insert -> Fold -> Executable -> TikZ the image width of the output is always set to a fixed 0.618par by default independent of the actual size of the TikZ figure.

If you manually remove the 0.618par from the width of the output image, TeXmacs is actually able to automatically set the correct image width for the embedded TikZ figure (such that font sizes match the rest of the document for example).

Is it possible to set the default behaviour to use this automatic detection of the width instead of a fixed 0.618par? That is, to keep the width of the image object empty when generating the output?

Even when you update an existing script input the image width defaults back to the 0.618par when the output is regenerated and you have to manually erase it again.

Thanks!

Is it possible to set default size of linked images?
#2

Hi @hgustafsson and welcome to the forum!

This behaviour is currently hardcoded (image_flush in src/Data/Convert/Generic/input.cpp). The only way around it is to remove the 0.618par in that file and recompile.

#3

This is very annoying. I think that it is better to have a default value the first time this thing is created, but if the value is modified by the user, then updating the script won’t change this value.

#4

Currently one workaround is

% -width 0.118par
\draw (0,0) -- (2,2) -- (2,0) -- (0,2);

Screenshot_20220930_220403
Screenshot_20220930_220403.png958Ă—443 6.53 KB

3 Likes
#5

I did not find the way to use the same technique to get the automatic width, do you have an idea?

#6

Excellent find, @sharkc!

Images can be scaled to their original width by using 1w as width. However, this is currently not allowed by validate_w_unit in input.cpp. Changing these functions as follows allows it:

bool validate_h_unit (string unit) {
  return unit == "pt" || unit == "px" || unit == "pag" || unit == "h";
}

bool validate_w_unit (string unit) {
  return unit == "pt" || unit == "px" || unit == "par" || unit == "w";
}

@darcy could validation allow for more units (also cm, in, pc, fs, etc.)?

1 Like
#7

and seemingly hard-coded 0.618par does not seem to be a reasonable choice for many plugins.

#8

Well, could you discuss it in detail? Like, for which plugins, what default value is better?

#9

Of course. Please create a pull request to:

#10

TikZ and Xypic, at least.

I meant, the hard-coded default value which is applied for every update. It seems better to have an empty value.

#11

I started a new project on Github to develop on the plugins implemented in python.

You can create pull request to this repo now or later:

There are few docs currently, I will add docs for people who are interested in it.

1 Like
#12

BTW, I have a long hope for the possibility to incorporate the relevant code when converted to LaTeX. This is also something related to TikZ and Xypic plugins. Seemingly this is a natural expectation.

2 Likes
#13

How about starting from reviewing this pull request:

Is 0.618par for Graphviz a good choice?

#14

I think adding w and h as valid units as @jeroen suggested would go a long way as a first step especially if it would allow you to write

% -width 1w
\draw (0,0) -- (1,1);

that could automatically detect the width.

As a second step (and while waiting for the new plugins-in-python project by @darcy), I believe different Graph objects (e.g. TikZ, gnuplot) could then override the inherited default_width from plugins/tmpy/graph/graph.py:28 as 1w instead of the current 0px (if I understood the code correctly).

In particular for the TikZ objects this seems like a very reasonable default, and if automatic width detection works (such that for example font sizes match) for other plugins besides TikZ, then it seems like a natural default for these as well.

#15

“AUTOMATIC” size detection is volatile since there are many ways to change size of a image. Besides the w style relative length unit, I think another good method is to define the default width as a variable, say default-image-width that can be overrode by tm macro assign or some scheme function. It would not be a heavy work.

1 Like