Can polar coordinate cause misalignment in TikZ?
6
I'm trying to align two paths using polar coordinates:
documentclass[tikz]{standalone}
begin{document}
begin{tikzpicture}
path [fill=blue] (0,0) -- +(-135:5mm) -- ([turn]90:25mm) -- ([turn]90:5mm) -- cycle;
path [fill=red] (0,0) -- +(-135:5mm) -- ([turn]90: 5mm) -- ([turn]90:5mm) -- cycle;
end{tikzpicture}
end{document}
However, they are slightly misaligned:
(The picture below is cropped and zoomed in)
Am I missing, i.e. miscalculating something here?
tikz-pgf
asked 12 hours ago
barbazbarbaz
67711018
|
show 1 more comment
6
I'm trying to align two paths using polar coordinates:
documentclass[tikz]{standalone}
begin{document}
begin{tikzpicture}
path [fill=blue] (0,0) -- +(-135:5mm) -- ([turn]90:25mm) -- ([turn]90:5mm) -- cycle;
path [fill=red] (0,0) -- +(-135:5mm) -- ([turn]90: 5mm) -- ([turn]90:5mm) -- cycle;
end{tikzpicture}
end{document}
However, they are slightly misaligned:
(The picture below is cropped and zoomed in)
Am I missing, i.e. miscalculating something here?
tikz-pgf
asked 12 hours ago
barbazbarbaz
67711018
1
What a funny coincidence to hear from you first. Just an hour ago I came across your name when learning about tikzlings :). The output is cropped and zoomed to the critical location, it's incomplete. I'm using pdflatex from MacTeX 2018.
– barbaz
12 hours ago
7
I can not answer, but it does not happen, if you avoid[turn]e.g.path [fill=blue] (0,0) -- ++(-135:5mm) -- ++(-45:25mm) -- ++(45:5mm) -- cycle;
– hpekristiansen
12 hours ago
5
It doesn't seem that polar coordinates are the reason sincedocumentclass[tikz]{standalone} begin{document} begin{tikzpicture} path [fill=blue] (0,0) -- ++(-135:5mm) -- ++ (-45:25mm) -- ++ (45:5mm) -- cycle; path [fill=red] (0,0) -- ++(-135:5mm) -- ++ (-45: 5mm) -- ++(45:5mm) -- cycle; end{tikzpicture} end{document}has no such problem. Rather, this might be due toturn.
– marmot
12 hours ago
1
@marmot: I was 3 second faster :o)
– hpekristiansen
12 hours ago
1
@hpekristiansen Yes, which is why I upvoted your comment. (Mine may still be somewhat useful because one can immediately compile it.)
– marmot
12 hours ago
|
show 1 more comment
6
6
6
1
I'm trying to align two paths using polar coordinates:
documentclass[tikz]{standalone}
begin{document}
begin{tikzpicture}
path [fill=blue] (0,0) -- +(-135:5mm) -- ([turn]90:25mm) -- ([turn]90:5mm) -- cycle;
path [fill=red] (0,0) -- +(-135:5mm) -- ([turn]90: 5mm) -- ([turn]90:5mm) -- cycle;
end{tikzpicture}
end{document}
However, they are slightly misaligned:
(The picture below is cropped and zoomed in)
Am I missing, i.e. miscalculating something here?
tikz-pgf
asked 12 hours ago
barbazbarbaz
67711018
I'm trying to align two paths using polar coordinates:
documentclass[tikz]{standalone}
begin{document}
begin{tikzpicture}
path [fill=blue] (0,0) -- +(-135:5mm) -- ([turn]90:25mm) -- ([turn]90:5mm) -- cycle;
path [fill=red] (0,0) -- +(-135:5mm) -- ([turn]90: 5mm) -- ([turn]90:5mm) -- cycle;
end{tikzpicture}
end{document}
However, they are slightly misaligned:
(The picture below is cropped and zoomed in)
Am I missing, i.e. miscalculating something here?
tikz-pgf
tikz-pgf
asked 12 hours ago
barbazbarbaz
67711018
asked 12 hours ago
barbazbarbaz
67711018
edited 12 hours ago
barbaz
asked 12 hours ago
barbazbarbaz
67711018
asked 12 hours ago
barbazbarbaz
67711018
asked 12 hours ago
barbazbarbaz
67711018
67711018
1
What a funny coincidence to hear from you first. Just an hour ago I came across your name when learning about tikzlings :). The output is cropped and zoomed to the critical location, it's incomplete. I'm using pdflatex from MacTeX 2018.
– barbaz
12 hours ago
7
I can not answer, but it does not happen, if you avoid[turn]e.g.path [fill=blue] (0,0) -- ++(-135:5mm) -- ++(-45:25mm) -- ++(45:5mm) -- cycle;
– hpekristiansen
12 hours ago
5
It doesn't seem that polar coordinates are the reason sincedocumentclass[tikz]{standalone} begin{document} begin{tikzpicture} path [fill=blue] (0,0) -- ++(-135:5mm) -- ++ (-45:25mm) -- ++ (45:5mm) -- cycle; path [fill=red] (0,0) -- ++(-135:5mm) -- ++ (-45: 5mm) -- ++(45:5mm) -- cycle; end{tikzpicture} end{document}has no such problem. Rather, this might be due toturn.
– marmot
12 hours ago
1
@marmot: I was 3 second faster :o)
– hpekristiansen
12 hours ago
1
@hpekristiansen Yes, which is why I upvoted your comment. (Mine may still be somewhat useful because one can immediately compile it.)
– marmot
12 hours ago
|
show 1 more comment
1
What a funny coincidence to hear from you first. Just an hour ago I came across your name when learning about tikzlings :). The output is cropped and zoomed to the critical location, it's incomplete. I'm using pdflatex from MacTeX 2018.
– barbaz
12 hours ago
7
I can not answer, but it does not happen, if you avoid[turn]e.g.path [fill=blue] (0,0) -- ++(-135:5mm) -- ++(-45:25mm) -- ++(45:5mm) -- cycle;
– hpekristiansen
12 hours ago
5
It doesn't seem that polar coordinates are the reason sincedocumentclass[tikz]{standalone} begin{document} begin{tikzpicture} path [fill=blue] (0,0) -- ++(-135:5mm) -- ++ (-45:25mm) -- ++ (45:5mm) -- cycle; path [fill=red] (0,0) -- ++(-135:5mm) -- ++ (-45: 5mm) -- ++(45:5mm) -- cycle; end{tikzpicture} end{document}has no such problem. Rather, this might be due toturn.
– marmot
12 hours ago
1
@marmot: I was 3 second faster :o)
– hpekristiansen
12 hours ago
1
@hpekristiansen Yes, which is why I upvoted your comment. (Mine may still be somewhat useful because one can immediately compile it.)
– marmot
12 hours ago
1
1
What a funny coincidence to hear from you first. Just an hour ago I came across your name when learning about tikzlings :). The output is cropped and zoomed to the critical location, it's incomplete. I'm using pdflatex from MacTeX 2018.
– barbaz
12 hours ago
What a funny coincidence to hear from you first. Just an hour ago I came across your name when learning about tikzlings :). The output is cropped and zoomed to the critical location, it's incomplete. I'm using pdflatex from MacTeX 2018.
– barbaz
12 hours ago
7
7
I can not answer, but it does not happen, if you avoid
[turn] e.g. path [fill=blue] (0,0) -- ++(-135:5mm) -- ++(-45:25mm) -- ++(45:5mm) -- cycle;– hpekristiansen
12 hours ago
I can not answer, but it does not happen, if you avoid
[turn] e.g. path [fill=blue] (0,0) -- ++(-135:5mm) -- ++(-45:25mm) -- ++(45:5mm) -- cycle;– hpekristiansen
12 hours ago
5
5
It doesn't seem that polar coordinates are the reason since
documentclass[tikz]{standalone} begin{document} begin{tikzpicture} path [fill=blue] (0,0) -- ++(-135:5mm) -- ++ (-45:25mm) -- ++ (45:5mm) -- cycle; path [fill=red] (0,0) -- ++(-135:5mm) -- ++ (-45: 5mm) -- ++(45:5mm) -- cycle; end{tikzpicture} end{document} has no such problem. Rather, this might be due to turn.– marmot
12 hours ago
It doesn't seem that polar coordinates are the reason since
documentclass[tikz]{standalone} begin{document} begin{tikzpicture} path [fill=blue] (0,0) -- ++(-135:5mm) -- ++ (-45:25mm) -- ++ (45:5mm) -- cycle; path [fill=red] (0,0) -- ++(-135:5mm) -- ++ (-45: 5mm) -- ++(45:5mm) -- cycle; end{tikzpicture} end{document} has no such problem. Rather, this might be due to turn.– marmot
12 hours ago
1
1
@marmot: I was 3 second faster :o)
– hpekristiansen
12 hours ago
@marmot: I was 3 second faster :o)
– hpekristiansen
12 hours ago
1
1
@hpekristiansen Yes, which is why I upvoted your comment. (Mine may still be somewhat useful because one can immediately compile it.)
– marmot
12 hours ago
@hpekristiansen Yes, which is why I upvoted your comment. (Mine may still be somewhat useful because one can immediately compile it.)
– marmot
12 hours ago
|
show 1 more comment
1 Answer
1
active
oldest
votes
5
The problem is this old inaccuracies in PGF pointed long time ago by Mark Wibrow. If we apply its correction of pgfpointnormalised we obtain a better precision not only for the orthogonal projections but also for [turn].
documentclass[tikz]{standalone}
usetikzlibrary{spy}
% use the Mark Wibrow's correction
makeatletter
defpgfpointnormalised#1{%
pgf@process{#1}%
pgfmathatantwo{thepgf@y}{thepgf@x}%
letpgf@tmp=pgfmathresult%
pgfmathcos@{pgf@tmp}pgf@x=pgfmathresult ptrelax%
pgfmathsin@{pgf@tmp}pgf@y=pgfmathresult ptrelax%
}
makeatother
begin{document}
begin{tikzpicture}[spy using outlines={circle, magnification=7, size=17mm, connect spies}]
path [draw=blue] (0,0) -- +(-135:5mm) -- ([turn]90:25mm) -- ([turn]90:5mm) -- cycle;
path [draw=red] (0,0) -- +(-135:5mm) -- ([turn]90: 5mm) -- ([turn]90:5mm) -- cycle;
spy on (-45:5mm) in node at (2,-.5);
end{tikzpicture}
end{document}
answered 11 hours ago
KpymKpym
16.2k23988
+1: Do you know if this "bug" is officially reported?
– Dr. Manuel Kuehner
11 hours ago
1
@Dr.ManuelKuehner this is not an easy "bug" because by designpgfpointnormalisedis not supposed to be really precise in direction, but it is designed to really have length1pt(as described in the manual). The problem is that it is used in places where the precision in direction is important ... I'll check if this is discussed in SourceForge.
– Kpym
10 hours ago
2
@Dr.ManuelKuehner this "bug" is reported now.
– Kpym
10 hours ago
Thanks! I do not understand the technicalities but I appreciate the effort.
– Dr. Manuel Kuehner
8 hours ago
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "85"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f476776%2fcan-polar-coordinate-cause-misalignment-in-tikz%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
5
The problem is this old inaccuracies in PGF pointed long time ago by Mark Wibrow. If we apply its correction of pgfpointnormalised we obtain a better precision not only for the orthogonal projections but also for [turn].
documentclass[tikz]{standalone}
usetikzlibrary{spy}
% use the Mark Wibrow's correction
makeatletter
defpgfpointnormalised#1{%
pgf@process{#1}%
pgfmathatantwo{thepgf@y}{thepgf@x}%
letpgf@tmp=pgfmathresult%
pgfmathcos@{pgf@tmp}pgf@x=pgfmathresult ptrelax%
pgfmathsin@{pgf@tmp}pgf@y=pgfmathresult ptrelax%
}
makeatother
begin{document}
begin{tikzpicture}[spy using outlines={circle, magnification=7, size=17mm, connect spies}]
path [draw=blue] (0,0) -- +(-135:5mm) -- ([turn]90:25mm) -- ([turn]90:5mm) -- cycle;
path [draw=red] (0,0) -- +(-135:5mm) -- ([turn]90: 5mm) -- ([turn]90:5mm) -- cycle;
spy on (-45:5mm) in node at (2,-.5);
end{tikzpicture}
end{document}
answered 11 hours ago
KpymKpym
16.2k23988
+1: Do you know if this "bug" is officially reported?
– Dr. Manuel Kuehner
11 hours ago
1
@Dr.ManuelKuehner this is not an easy "bug" because by designpgfpointnormalisedis not supposed to be really precise in direction, but it is designed to really have length1pt(as described in the manual). The problem is that it is used in places where the precision in direction is important ... I'll check if this is discussed in SourceForge.
– Kpym
10 hours ago
2
@Dr.ManuelKuehner this "bug" is reported now.
– Kpym
10 hours ago
Thanks! I do not understand the technicalities but I appreciate the effort.
– Dr. Manuel Kuehner
8 hours ago
add a comment |
5
The problem is this old inaccuracies in PGF pointed long time ago by Mark Wibrow. If we apply its correction of pgfpointnormalised we obtain a better precision not only for the orthogonal projections but also for [turn].
documentclass[tikz]{standalone}
usetikzlibrary{spy}
% use the Mark Wibrow's correction
makeatletter
defpgfpointnormalised#1{%
pgf@process{#1}%
pgfmathatantwo{thepgf@y}{thepgf@x}%
letpgf@tmp=pgfmathresult%
pgfmathcos@{pgf@tmp}pgf@x=pgfmathresult ptrelax%
pgfmathsin@{pgf@tmp}pgf@y=pgfmathresult ptrelax%
}
makeatother
begin{document}
begin{tikzpicture}[spy using outlines={circle, magnification=7, size=17mm, connect spies}]
path [draw=blue] (0,0) -- +(-135:5mm) -- ([turn]90:25mm) -- ([turn]90:5mm) -- cycle;
path [draw=red] (0,0) -- +(-135:5mm) -- ([turn]90: 5mm) -- ([turn]90:5mm) -- cycle;
spy on (-45:5mm) in node at (2,-.5);
end{tikzpicture}
end{document}
answered 11 hours ago
KpymKpym
16.2k23988
+1: Do you know if this "bug" is officially reported?
– Dr. Manuel Kuehner
11 hours ago
1
@Dr.ManuelKuehner this is not an easy "bug" because by designpgfpointnormalisedis not supposed to be really precise in direction, but it is designed to really have length1pt(as described in the manual). The problem is that it is used in places where the precision in direction is important ... I'll check if this is discussed in SourceForge.
– Kpym
10 hours ago
2
@Dr.ManuelKuehner this "bug" is reported now.
– Kpym
10 hours ago
Thanks! I do not understand the technicalities but I appreciate the effort.
– Dr. Manuel Kuehner
8 hours ago
add a comment |
5
5
5
The problem is this old inaccuracies in PGF pointed long time ago by Mark Wibrow. If we apply its correction of pgfpointnormalised we obtain a better precision not only for the orthogonal projections but also for [turn].
documentclass[tikz]{standalone}
usetikzlibrary{spy}
% use the Mark Wibrow's correction
makeatletter
defpgfpointnormalised#1{%
pgf@process{#1}%
pgfmathatantwo{thepgf@y}{thepgf@x}%
letpgf@tmp=pgfmathresult%
pgfmathcos@{pgf@tmp}pgf@x=pgfmathresult ptrelax%
pgfmathsin@{pgf@tmp}pgf@y=pgfmathresult ptrelax%
}
makeatother
begin{document}
begin{tikzpicture}[spy using outlines={circle, magnification=7, size=17mm, connect spies}]
path [draw=blue] (0,0) -- +(-135:5mm) -- ([turn]90:25mm) -- ([turn]90:5mm) -- cycle;
path [draw=red] (0,0) -- +(-135:5mm) -- ([turn]90: 5mm) -- ([turn]90:5mm) -- cycle;
spy on (-45:5mm) in node at (2,-.5);
end{tikzpicture}
end{document}
answered 11 hours ago
KpymKpym
16.2k23988
The problem is this old inaccuracies in PGF pointed long time ago by Mark Wibrow. If we apply its correction of pgfpointnormalised we obtain a better precision not only for the orthogonal projections but also for [turn].
documentclass[tikz]{standalone}
usetikzlibrary{spy}
% use the Mark Wibrow's correction
makeatletter
defpgfpointnormalised#1{%
pgf@process{#1}%
pgfmathatantwo{thepgf@y}{thepgf@x}%
letpgf@tmp=pgfmathresult%
pgfmathcos@{pgf@tmp}pgf@x=pgfmathresult ptrelax%
pgfmathsin@{pgf@tmp}pgf@y=pgfmathresult ptrelax%
}
makeatother
begin{document}
begin{tikzpicture}[spy using outlines={circle, magnification=7, size=17mm, connect spies}]
path [draw=blue] (0,0) -- +(-135:5mm) -- ([turn]90:25mm) -- ([turn]90:5mm) -- cycle;
path [draw=red] (0,0) -- +(-135:5mm) -- ([turn]90: 5mm) -- ([turn]90:5mm) -- cycle;
spy on (-45:5mm) in node at (2,-.5);
end{tikzpicture}
end{document}
answered 11 hours ago
KpymKpym
16.2k23988
answered 11 hours ago
KpymKpym
16.2k23988
answered 11 hours ago
KpymKpym
16.2k23988
answered 11 hours ago
KpymKpym
16.2k23988
16.2k23988
+1: Do you know if this "bug" is officially reported?
– Dr. Manuel Kuehner
11 hours ago
1
@Dr.ManuelKuehner this is not an easy "bug" because by designpgfpointnormalisedis not supposed to be really precise in direction, but it is designed to really have length1pt(as described in the manual). The problem is that it is used in places where the precision in direction is important ... I'll check if this is discussed in SourceForge.
– Kpym
10 hours ago
2
@Dr.ManuelKuehner this "bug" is reported now.
– Kpym
10 hours ago
Thanks! I do not understand the technicalities but I appreciate the effort.
– Dr. Manuel Kuehner
8 hours ago
add a comment |
+1: Do you know if this "bug" is officially reported?
– Dr. Manuel Kuehner
11 hours ago
1
@Dr.ManuelKuehner this is not an easy "bug" because by designpgfpointnormalisedis not supposed to be really precise in direction, but it is designed to really have length1pt(as described in the manual). The problem is that it is used in places where the precision in direction is important ... I'll check if this is discussed in SourceForge.
– Kpym
10 hours ago
2
@Dr.ManuelKuehner this "bug" is reported now.
– Kpym
10 hours ago
Thanks! I do not understand the technicalities but I appreciate the effort.
– Dr. Manuel Kuehner
8 hours ago
+1: Do you know if this "bug" is officially reported?
– Dr. Manuel Kuehner
11 hours ago
+1: Do you know if this "bug" is officially reported?
– Dr. Manuel Kuehner
11 hours ago
1
1
@Dr.ManuelKuehner this is not an easy "bug" because by design
pgfpointnormalised is not supposed to be really precise in direction, but it is designed to really have length 1pt (as described in the manual). The problem is that it is used in places where the precision in direction is important ... I'll check if this is discussed in SourceForge.– Kpym
10 hours ago
@Dr.ManuelKuehner this is not an easy "bug" because by design
pgfpointnormalised is not supposed to be really precise in direction, but it is designed to really have length 1pt (as described in the manual). The problem is that it is used in places where the precision in direction is important ... I'll check if this is discussed in SourceForge.– Kpym
10 hours ago
2
2
@Dr.ManuelKuehner this "bug" is reported now.
– Kpym
10 hours ago
@Dr.ManuelKuehner this "bug" is reported now.
– Kpym
10 hours ago
Thanks! I do not understand the technicalities but I appreciate the effort.
– Dr. Manuel Kuehner
8 hours ago
Thanks! I do not understand the technicalities but I appreciate the effort.
– Dr. Manuel Kuehner
8 hours ago
add a comment |
draft saved
draft discarded
Thanks for contributing an answer to TeX - LaTeX Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f476776%2fcan-polar-coordinate-cause-misalignment-in-tikz%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
What a funny coincidence to hear from you first. Just an hour ago I came across your name when learning about tikzlings :). The output is cropped and zoomed to the critical location, it's incomplete. I'm using pdflatex from MacTeX 2018.
– barbaz
12 hours ago
7
I can not answer, but it does not happen, if you avoid
[turn]e.g.path [fill=blue] (0,0) -- ++(-135:5mm) -- ++(-45:25mm) -- ++(45:5mm) -- cycle;– hpekristiansen
12 hours ago
5
It doesn't seem that polar coordinates are the reason since
documentclass[tikz]{standalone} begin{document} begin{tikzpicture} path [fill=blue] (0,0) -- ++(-135:5mm) -- ++ (-45:25mm) -- ++ (45:5mm) -- cycle; path [fill=red] (0,0) -- ++(-135:5mm) -- ++ (-45: 5mm) -- ++(45:5mm) -- cycle; end{tikzpicture} end{document}has no such problem. Rather, this might be due toturn.– marmot
12 hours ago
1
@marmot: I was 3 second faster :o)
– hpekristiansen
12 hours ago
1
@hpekristiansen Yes, which is why I upvoted your comment. (Mine may still be somewhat useful because one can immediately compile it.)
– marmot
12 hours ago