31 Jan 2022 |
muzimuzhi | If the outer path has non-empty arrows, \pgfsetarrows{-} is also required.
It's a pity that there's no lists of options which are inherited, used, and reset inside a node/pic/matrix/graph.
| 00:29:09 |
muzimuzhi | * If the outer path has non-empty arrows, \pgfsetarrows{-} is also required.
It's a pity that there's no documented lists of options which are inherited, used, and reset inside a node/pic/matrix/graph.
| 00:29:18 |
Romano Giannetti |
If the outer path has non-empty arrows, \pgfsetarrows{-} is also required.
It's a pity that there's no documented lists of options which are inherited, used, and reset inside a node/pic/matrix/graph.
muzimuzhi thanks! So I should \pgfscope \pgfsetshortenstart{+0pt} \pgfsetshortenend{+0pt} \pgfsetarrows{-} ... \endpgfscope at the start of every shape backgroundpath which is supposed to be drawn independently from the outer path? Is the scoping sufficient to guarantee that the outer path is not disturbed?
| 06:31:43 |
samcarter | In reply to @muzzi:matrix.org hmenke: Since Conventional Commits has been applied for a while with a tacit agreement, maybe it's time to mention and require it in PR template. This could save us from reminding new contributors. Random thought: maybe it would be interesting to have a talk about best practises in git at a future user group meeting? | 10:27:07 |
hmenke | samcarter: That's a good idea. When and where will the next DANTE meeting take place? The website doesn't list anything yet. | 11:12:17 |
samcarter | In reply to @hmenke:matrix.org samcarter: That's a good idea. When and where will the next DANTE meeting take place? The website doesn't list anything yet. No idea! I did not yet hear about anything. | 12:44:28 |
muzimuzhi | In reply to @r_mano:matrix.org
If the outer path has non-empty arrows, \pgfsetarrows{-} is also required.
It's a pity that there's no documented lists of options which are inherited, used, and reset inside a node/pic/matrix/graph.
muzimuzhi thanks! So I should \pgfscope \pgfsetshortenstart{+0pt} \pgfsetshortenend{+0pt} \pgfsetarrows{-} ... \endpgfscope at the start of every shape backgroundpath which is supposed to be drawn independently from the outer path? Is the scoping sufficient to guarantee that the outer path is not disturbed?
There're more to be reset. What I can immediately think of is using \pgfsetcornersarced{\pgfpointorigin} to reset outer non-zero rounded corners .
Is the scoping sufficient to guarantee that the outer path is not disturbed?
Yes I think so.
| 13:32:11 |
muzimuzhi | In reply to @r_mano:matrix.org
If the outer path has non-empty arrows, \pgfsetarrows{-} is also required.
It's a pity that there's no documented lists of options which are inherited, used, and reset inside a node/pic/matrix/graph.
muzimuzhi thanks! So I should \pgfscope \pgfsetshortenstart{+0pt} \pgfsetshortenend{+0pt} \pgfsetarrows{-} ... \endpgfscope at the start of every shape backgroundpath which is supposed to be drawn independently from the outer path? Is the scoping sufficient to guarantee that the outer path is not disturbed?
* Depending on the design goal, there may be more to be reset. What I can immediately think of is using \pgfsetcornersarced{\pgfpointorigin} to reset outer non-zero rounded corners .
Is the scoping sufficient to guarantee that the outer path is not disturbed?
Yes I think so.
| 13:43:22 |
hmenke | In reply to @muzzi:matrix.org
If the outer path has non-empty arrows, \pgfsetarrows{-} is also required.
It's a pity that there's no documented lists of options which are inherited, used, and reset inside a node/pic/matrix/graph.
Well, generally everything should be assumed to be inherited, because even if we can reset certain things in the graphics state, these changes will not propagate back into pgfkeys. To be sure that everything is in sync, all the (un)desired options should be reset manually. | 14:11:10 |
muzimuzhi | Reminds me of tcolorbox ' styles reset and internal initialize@reset : reset will reset all tcolorbox aspects on every box layer, and initialize@reset executes options and adds them to reset . This makes tcolorbox es nestable. https://github.com/T-F-S/tcolorbox/blob/2573999ebc4453258d50124acaea05dc99a2850c/tex/latex/tcolorbox/tcolorbox.sty#L2324-L2325 | 17:13:15 |
1 Feb 2022 |
muzimuzhi | In reply to @hmenke:matrix.org Well, generally everything should be assumed to be inherited, because even if we can reset certain things in the graphics state, these changes will not propagate back into pgfkeys. To be sure that everything is in sync, all the (un)desired options should be reset manually. Romano Giannetti: Resetting things in node shapes' foreground/background path may be too late and less flexible. For example, it will also overwrite <options> in ... node[<shape>, <options>] . I find resetting things in \tikz@node@reset@hook which is used in \tikz@normal@fig (in a local group) helpful, but it's a breaking change as Henri said "generally everything should be assumed to be inherited". | 19:07:12 |
muzimuzhi |
| 19:07:16 |
muzimuzhi | * \documentclass{article}
\usepackage{tikz}
\makeatletter
\pgfutil@g@addto@macro\tikz@node@reset@hook
{\tikzset{shorten <=+0pt, shorten >=+0pt, arrows={-}, rounded corners=+0pt}}
\makeatother
\pgfdeclareshape{what}{
\anchor{center}{
\pgfpointorigin
}
\foregroundpath{
\pgfpathmoveto{\pgfpoint{-4pt}{0pt}}
\pgfpathlineto{\pgfpoint{4pt}{0pt}}
\pgfpathlineto{\pgfpoint{0pt}{4pt}}
\pgfpathlineto{\pgfpoint{-4pt}{0pt}}
\pgfusepath{draw,fill}
}
}
\begin{document}
\begin{tikzpicture}[back]
\draw[] (0,0) -- node[what] {} ++(0,-2);
\draw[fill=red, shorten <=.5cm] (1,0) -- node[what] {} ++(0,-2);
\draw[fill=red, shorten <=.5cm] (2,0) -- node[what, shorten <=5pt] {} ++(0,-2);
\draw[fill=blue,rounded corners=10pt] (3,0) -- node[what] {} ++(0,-2);
\draw[fill=blue,rounded corners=10pt] (4,0) -- node[what, rounded corners=2pt] {} ++(0,-2);
\draw[fill=green, <->] (5,0) -- node[what] {} ++(0,-2);
\draw[fill=green, <->] (6,0) -- node[what, shorten <=3pt, <-] {} ++(0,-2);
\end{tikzpicture}
\end{document}
| 19:08:04 |
muzimuzhi | Download image.png | 19:08:10 |
muzimuzhi | Perhaps circuitikz could achieve similar effects by locally changing style every node ? | 19:13:26 |
muzimuzhi | * Perhaps circuitikz could achieve similar effects by locally changing style every node ? Because in \tikz@normal@fig \tikzset{every node/.try} is used right after \tikz@node@reset@hook . | 19:14:18 |
Romano Giannetti | muzimuzhi: I see it is difficult... sometimes you want them to propagate, and sometimes no. So I think I will go for the minimal fix; really the user that noticed the problem was trying to do a very strange thing with the shape. | 19:15:40 |
Romano Giannetti | * muzimuzhi: I see it is difficult... sometimes you want them to propagate, and sometimes no. So I think I will go for the minimal fix; really the user that noticed the problem was trying to do a very strange thing with the shape. (See https://tex.stackexchange.com/questions/632051/tikz-shorten-with-circuitikz) | 19:16:21 |
muzimuzhi | In reply to @r_mano:matrix.org muzimuzhi: I see it is difficult... sometimes you want them to propagate, and sometimes no. So I think I will go for the minimal fix; really the user that noticed the problem was trying to do a very strange thing with the shape. (See https://tex.stackexchange.com/questions/632051/tikz-shorten-with-circuitikz)
sometimes you want them to propagate, and sometimes no
true. Having every relation between any of tikz options and node/pic/matrix/graph documented is such a hard task, and it's even impossible to resort the inconsistencies when tikz's main features has been populated for such a long time.
Oh I've opened that tex-sx question, but didn't read through.
| 19:22:51 |
4 Feb 2022 |
Romano Giannetti | Fast/dirty question: it is possible to access the name of a shape inside the back/fore/etc-ground part? I am thinking about a hook system for circuitikz... | 09:20:26 |
Romano Giannetti | I am thinking something similar to this, where #1 is the name of the shape --- but I'll prefer not to add it manually like it is now: | 10:00:35 |
Romano Giannetti |
| 10:01:00 |
Romano Giannetti | * \def\pgf@circ@shape@hooks#1{%
\ifcsname ctikz@hook@shapename@#1\endcsname
\csname ctikz@hook@shapename@#1\endcsname
\else
\ifcsname ctikzclass\endcsname
\ifcsname ctikz@hook@class@\ctikzclass\endcsname
\csname ctikz@hook@class@\ctikzclass\endcsname
% class defined, but no hook, run generic hook
\else
\csname ctikz@hook@generic@shape\endcsname
\fi
% we have no class, we did not run specific hook:run generic hook
\else
\csname ctikz@hook@generic@shape\endcsname
\fi
\fi
}
| 10:01:14 |
Romano Giannetti | where I try the specific hook (executing it if it exists), otherwise the class one (similar, if class exists), and finally a generic hook (which is void for now but I think using the arrow and arced corner rest suggested by muzimuzhi | 10:03:32 |
Romano Giannetti | * where I try the specific hook (executing it if it exists), otherwise the class one (similar, if class exists), and finally a generic hook (which is void for now but I think using the arrow and arced corner reset suggested by muzimuzhi | 11:25:42 |
muzimuzhi | In reply to @r_mano:matrix.org I am thinking something similar to this, where #1 is the name of the shape --- but I'll prefer not to add it manually like it is now: Maybe \pgf@sm@shape@name ? | 22:10:52 |
muzimuzhi | tikz nodes will all finally call [1] and the latter defines \def\pgf@sm@shape@name{#1} where #1 is the shape name [2]. [1] https://github.com/pgf-tikz/pgf/blob/1dbf7ae5ddd5479e8a046d76d49c7bfd001e5f0a/tex/generic/pgf/frontendlayer/tikz/tikz.code.tex#L4130 [2] https://github.com/pgf-tikz/pgf/blob/1dbf7ae5ddd5479e8a046d76d49c7bfd001e5f0a/tex/generic/pgf/modules/pgfmoduleshapes.code.tex#L50 | 22:15:21 |
muzimuzhi | * tikz nodes will all finally call [1]
\pgfmultipartnode{\tikz@shape}{\tikz@anchor}{\tikz@fig@name}{...}
and the latter defines \def\pgf@sm@shape@name{#1} where #1 is the shape name [2].
[1] https://github.com/pgf-tikz/pgf/blob/1dbf7ae5ddd5479e8a046d76d49c7bfd001e5f0a/tex/generic/pgf/frontendlayer/tikz/tikz.code.tex#L4130 [2] https://github.com/pgf-tikz/pgf/blob/1dbf7ae5ddd5479e8a046d76d49c7bfd001e5f0a/tex/generic/pgf/modules/pgfmoduleshapes.code.tex#L50
| 22:16:26 |
muzimuzhi | * tikz nodes will all finally call [1]
\pgfmultipartnode{\tikz@shape}{\tikz@anchor}{\tikz@fig@name}{...}
and in \pgfmultipartnode it defines \def\pgf@sm@shape@name{#1} where #1 is the shape name [2].
[1] https://github.com/pgf-tikz/pgf/blob/1dbf7ae5ddd5479e8a046d76d49c7bfd001e5f0a/tex/generic/pgf/frontendlayer/tikz/tikz.code.tex#L4130 [2] https://github.com/pgf-tikz/pgf/blob/1dbf7ae5ddd5479e8a046d76d49c7bfd001e5f0a/tex/generic/pgf/modules/pgfmoduleshapes.code.tex#L50
| 22:17:06 |
muzimuzhi | * \documentclass{article}
\usepackage{tikz}
\makeatletter
\pgfutil@g@addto@macro\tikz@node@reset@hook
{\tikzset{shorten <=+0pt, shorten >=+0pt, arrows={-}, rounded corners=+0pt}}
\makeatother
\pgfdeclareshape{what}{
\anchor{center}{
\pgfpointorigin
}
\foregroundpath{
\pgfpathmoveto{\pgfpoint{-4pt}{0pt}}
\pgfpathlineto{\pgfpoint{4pt}{0pt}}
\pgfpathlineto{\pgfpoint{0pt}{4pt}}
\pgfpathlineto{\pgfpoint{-4pt}{0pt}}
\pgfusepath{draw,fill}
}
}
\begin{document}
\begin{tikzpicture}
\draw[] (0,0) -- node[what] {} ++(0,-2);
\draw[fill=red, shorten <=.5cm] (1,0) -- node[what] {} ++(0,-2);
\draw[fill=red, shorten <=.5cm] (2,0) -- node[what, shorten <=5pt] {} ++(0,-2);
\draw[fill=blue,rounded corners=10pt] (3,0) -- node[what] {} ++(0,-2);
\draw[fill=blue,rounded corners=10pt] (4,0) -- node[what, rounded corners=2pt] {} ++(0,-2);
\draw[fill=green, <->] (5,0) -- node[what] {} ++(0,-2);
\draw[fill=green, <->] (6,0) -- node[what, shorten <=3pt, <-] {} ++(0,-2);
\end{tikzpicture}
\end{document}
| 22:34:07 |