Beautify direction calculation

[apriljunge]

Most of the symbols of trackschematic have the possibility to specify a direction. For turnouts it's done (simplified) like this:

\pgfmathsetmacro{\branchfactor}{-1}
\pgfmathsetmacro{\facefactor}{-1}

\path[fill=black] (0,0) -- ++($\facefactor*(0.4,0)$) -- ++($\branchfactor*(0,0.4)$) -- cycle;% turnout marker
\fill[\foreground] ($\facefactor*(0.075,0) + \branchfactor*(0,-0.1 )$) circle (0.05);% points indicator left
\fill[\foreground] ($\facefactor*(0.225,0) + \branchfactor*(0,-0.1 )$) circle (0.05);% points indicator left
\fill[\foreground] ($\facefactor*(0.015,0) + \branchfactor*(0, 0.15)$) circle (0.05);% points indicator right
\fill[\foreground] ($\facefactor*(0.115,0) + \branchfactor*(0, 0.25)$) circle (0.05);% points indicator right

My suggestion is to use scaling to have cleaner code. The implementation of above would look like this and have the exactly same output:

\pgfmathsetmacro{\branchfactor}{-1}
\pgfmathsetmacro{\facefactor}{-1}

\begin{scope}[xscale=\facefactor, yscale=\branchfactor]
    \path[fill=black] (0,0) -- ++(0.4,0) -- ++(0,0.4) -- cycle;% turnout marker
    \fill[\foreground] (0.075,-0.1) circle (0.05);% points indicator left
    \fill[\foreground] (0.225,-0.1 ) circle (0.05);% points indicator left
    \fill[\foreground] (0.015, 0.15) circle (0.05);% points indicator right
    \fill[\foreground] (0.115, 0.25) circle (0.05);% points indicator right
\end{scope}

What do you think?

[apriljunge]

I think this would work for most of the symbols, not only for turnouts. My question is whether you think that a major refactoring makes sense.

[kaat0]

Interessting proposal! I think a refactoring always makes sense if it helps the readability and do not significantly increase resource comsumption. I am not so sure about the pgf/tikz mechanism of scaling. To go further with this idea, we need to consider use cases in which a user takes a track schemtic and scales it further. For instance: showing a track schematic in A4-page or a beamer slide where it does not fit without scaling.

Therefore, I suggest to create test cases for scaling!

[apriljunge]

xscale and yscale are part of TikZ coordinate transformations (Chapter 25.3 in TikZ Docs). The transformations are only applied to the coordinate system. And:

However, all transformations are local to the current TEX-group.

I created a short test (see below) for quick general validation and it works like expected.

\begin{scope}[scale=2]
 \begin{scope}[xscale=\facefactor, yscale=\branchfactor]
 ...
 \end{scope}
\end{scope}

I think it really does make sense to add a test scenario like this. Maybe you can help me setting one up? Do you think it should be added to the tests in the test folder? Or should it be just one general test?

[kaat0]

The tests in the test folder should already cover the basics. Therefore, I would add new one for the special scaling case where a larger canavs is scalled. We could start with the examples in the example folder. For instance embed the examples in different environments:

• beamer
• A0,A1,A2,A3,A4,A5,A6 paper
• US Letter
• color
• etc.

[kaat0]

I started with A0 and A5 paper size and two different environments:

• adjustbox
• native tikz scaling

see: https://github.com/railtoolkit/tikz-trackschematic/commit/714536ab9f2999e3e0f4809592d817d0fb242543 The adjustbox scaling works as expected but the native tikz scaling does not.

[apriljunge]

Tikz (native) transform only transforms the coordinate system. Other sizes like line widths are not scaled. This explains the different results.

[apriljunge]

The new test cases seems to break the test pipeline triggered by GitHub actions

[apriljunge]

This is getting too complex with tikz scaling not working as expected (see #13)