New l3draw functions to extract x/y/z-coordinate of a point about latex3

[car222222]

But this is l3draw, so surely it is in 3D?? :-)

[josephwright]

See comments in the sources: the are deliberately not includes pending solid use cases. I suspect that 'local' auxiliaries are likey the base plan.

[muzimuzhi]

latex3/l3experimental/l3draw/l3draw-points.dtx

Lines 67 to 78 in 2ea12ef

	% Equivalents of following \pkg{pgf} functions are deliberately omitted:
	% \begin{itemize}
	% \item \cs{pgfpointorigin}: Can be given explicitly as |0pt,0pt|.
	% \item \cs{pgfpointadd}, \cs{pgfpointdiff},
	% \cs{pgfpointscale}: Can be given explicitly.
	% \item \cs{pgfextractx}, \cs{pgfextracty}: Available by applying
	% \cs{use_i:nn}/\cs{use_ii:nn} or similar to the \texttt{e}-type
	% expansion of a point expression.
	% \item \cs{pgfgetlastxy}: Unused in the entire \pkg{pgf} core, may be
	% emulated by \texttt{e}-type expansion of a point expression, then using
	% the result.
	% \end{itemize}

[muzimuzhi]

%   \item \cs{pgfextractx}, \cs{pgfextracty}: Available by applying
%     \cs{use_i:nn}/\cs{use_ii:nn} or similar to the \texttt{e}-type
%     expansion of a point expression.

But public \draw_point_... functions expand points to points themselves, aka two-element comma-separated lists. Only the internal \__draw_point_process:nn expands a point to {<x-coord>}{<y-coord>}, which then can be passed to \use_i:nn/\use_ii:nn to extract x/y-coordinate.

That's why @jasperhabicht uses \clist_item:en in the demonstration in #1488 (comment).

[josephwright]

@muzimuzhi Yes, my code comment is inaccurate but the general idea stands. In pgf you need the 'extract' commands as the information is internal. In l3draw we can do everything using an fp expression by expansion, so can easily create an 'extract the value' command. But more widely, there are two things. First, as we can use tuples throughout, I'm not sure point extraction is very useful - we don't need to access just-x or just-y. Second, as this is really a general tuple feature, I suspect it should be handled within l3fp, something like \fp_eval:n { select(2, (<tuple>) } -> y-value.

[josephwright]

(Whole reason this code is in l3experimental is of course that this sort of stuff needs exploring.)

[josephwright]

BTW, points don't have a z-co-ordinate ;)

[jasperhabicht]

I think there can be situations where you need just the x or the y part of a point coordinate, for example if you want to calculate trigonometric stuff where you can't always use tuples (for example when using atand(), you need both values separately *). Or you might want to use the y part of one point coordinate and the x part of another to create a new point coordinate.

I agree that extracting a value from a tuple should rather be a feature of l3fp. However, currently there is no such a feature and it would most probably be based on a loop. So, in the end there are still arguments against and in favor of implementing this in l3draw directly.

---

*) See https://tex.stackexchange.com/a/711906/47927 for a use case. I think with only tuples, it would be difficult to calculate the angle, but I might be wrong.