summaryrefslogtreecommitdiff
path: root/macros/latex/contrib/tkz/tkz-elements/doc/latex/TKZdoc-elements-organization.tex
blob: f69e0a591d77b4f86544c3d32959f1eba3c5d54d (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
\section{Work organization} % (fold)
\label{sec:work_organization}

Here's a sample organization. 

The line |% !TEX TS-program = lualatex| ensures that you don't forget to compile with Lua\LATEX{}. The "standalone" class is useful, as all you need to do here is create a figure.

The "mini" option in \pkg{tkz-euclide} allows you to load and use only plot-related macros.

The package \pkg{ifthen} is useful if you need to use some Boolean.

The macro \tkzcname{LuaCodeDebugOn} allows you to try and find errors in Lua code.   

It is of course possible to leave the Lua code in the \tkzNameEnv{tkzelements} environment, but externalizing this code has its advantages. 

The first advantage, if you use a good editor, is to have a good presentation of the code. Styles are different between "Lua" and \LATEX{}. This makes the code clearer. This is how I proceeded, then reintegrated the code into the main code.

Another advantage is that you don't have to comment the code incorrectly. For Lua code, you comment lines with |--| (double minus sign), whereas for \LATEX{}, you comment with |%|.

Third advantage: the code can be reused.



\begin{verbatim}
% !TEX TS-program = lualatex
% Created by Alain Matthes on 2024-01-09.

\documentclass[margin = 12pt]{standalone} 
\usepackage[mini]{tkz-euclide}
\usepackage{tkz-elements,ifthen}

\begin{document} 
\LuaCodeDebugOn    
\begin{tkzelements}
 scale = 1.25
 dofile ("sangaku.lua")
\end{tkzelements}

\begin{tikzpicture}
   \tkzGetNodes
   \tkzDrawCircle(I,F)
   \tkzFillPolygon[color = purple](A,C,D)%
   \tkzFillPolygon[color = blue!50!black](A,B,C)%
   \tkzFillCircle[color = orange](I,F)%
\end{tikzpicture}
\end{document}
\end{verbatim}

And here is the code for the "Lua" part: the file |ex_sangaku.lua|

\begin{verbatim}
z.A         = point : new ( 0,0 ) 
z.B         = point : new ( 8,0 )
L.AB        = line : new ( z.A , z.B )
S           = L.AB : square ()
_,_,z.C,z.D = get_points (S)
z.F         = S.ac : projection (z.B)
L.BF        = line : new (z.B,z.F)
T.ABC       = triangle : new ( z.A , z.B , z.C )
L.bi        = T.ABC : bisector (2)
z.c         = L.bi.pb
L.Cc        = line : new (z.C,z.c)
z.I         = intersection (L.Cc,L.BF)
\end{verbatim}

\begin{tkzelements}
 scale = 1.25
 dofile ("sangaku.lua")
\end{tkzelements}

\begin{tikzpicture}
   \tkzGetNodes
   \tkzDrawCircle(I,F)
   \tkzFillPolygon[color = purple](A,C,D)%
   \tkzFillPolygon[color = blue!50!black](A,B,C)%
   \tkzFillCircle[color = orange](I,F)%
\end{tikzpicture}

\subsection{Scale problem} % (fold)
\label{sub:scale_problem}

If necessary, it's better to do the scaling in the "Lua" section. The reason is that it will be more accurate. There is, however, a problem to be aware of. I've made it a point of honor to avoid using numerical values in my codes whenever possible. In principle, these values only appear in the definition of fixed points. If the "scale" option is used, scaling is applied when points are created. Let's imagine you want to organize your code as follows:

|scale = 1.5|\\
|xB = 8|\\
|z.B         = point : new ( xB,0 )|

Scaling would then be ineffective, as the numerical values are not modified, only the point coordinates. To take scaling into account, use the function \Igfct{math}{value (v) }.

|scale = 1.5|\\
|xB = value (8)|\\
|z.B         = point : new ( xB,0 )|

\subsection{Code presentation} % (fold)
\label{sub:code_presentation}

The key point is that, unlike \LATEX{} or \TEX{}, you can insert spaces absolutely anywhere. 
% subsection code_presentation (end)
% subsection scale_problem (end)
% section work_organization (end)