Can polar coordinate cause misalignment in TikZ?Drawing the three altitudes of a triangle with TikZ;...

How to access internet and run apt-get through a middle server?

Non-Cancer terminal illness that can affect young (age 10-13) girls?

Can you tell from a blurry photo if focus was too close or too far?

What is a good reason for every spaceship to carry a weapon on board?

What is the industry term for house wiring diagrams?

Utilizing a Right and Left Outer Joins in same SELECT

How does one write from a minority culture? A question on cultural references

What is a DAG (Graph Theory)?

I have trouble understanding this fallacy: "If A, then B. Therefore if not-B, then not-A."

Can 5 Aarakocra PCs summon an Air Elemental?

Does the ditching switch allow an A320 to float indefinitely?

False written accusations not made public - is there law to cover this?

Does diversity provide anything that meritocracy does not?

Saint abbreviation

Can polar coordinate cause misalignment in TikZ?

Why didn't Tom Riddle take the presence of Fawkes and the Sorting Hat as more of a threat?

The probability of reaching the absorbing states from a particular transient state?

Bash script to truncate subject line of incoming email

How can I play a serial killer in a party of good PCs?

Separate environment for personal and development use under macOS

A starship is travelling at 0.9c and collides with a small rock. Will it leave a clean hole through, or will more happen?

Has any human ever had the choice to leave Earth permanently?

Existence of Riemann surface, holomorphic maps

Prioritising polygons in QGIS



Can polar coordinate cause misalignment in TikZ?


Drawing the three altitudes of a triangle with TikZ; incorrect orthocenterTikz Polar GridIs there a polar coordinate registers in the let command?tikz and polar plotTikZ: Drawing an arc from an intersection to an intersectionDrawing rectilinear curves in Tikz, aka an Etch-a-Sketch drawingLine up nested tikz enviroments or how to get rid of themhow to use 3d polar coordinate systemPolar Triangle with Tikztikz coordinate at a coordinateSetting polar coordinates for coordinate system in TikZ via macro













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)



enter image description here



Am I missing, i.e. miscalculating something here?










share|improve this question




















  • 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
    3 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
    3 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 to turn.

    – marmot
    3 hours ago






  • 1





    @marmot: I was 3 second faster :o)

    – hpekristiansen
    3 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
    3 hours ago
















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)



enter image description here



Am I missing, i.e. miscalculating something here?










share|improve this question




















  • 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
    3 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
    3 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 to turn.

    – marmot
    3 hours ago






  • 1





    @marmot: I was 3 second faster :o)

    – hpekristiansen
    3 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
    3 hours ago














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)



enter image description here



Am I missing, i.e. miscalculating something here?










share|improve this question
















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)



enter image description here



Am I missing, i.e. miscalculating something here?







tikz-pgf






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 3 hours ago







barbaz

















asked 4 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
    3 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
    3 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 to turn.

    – marmot
    3 hours ago






  • 1





    @marmot: I was 3 second faster :o)

    – hpekristiansen
    3 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
    3 hours ago














  • 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
    3 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
    3 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 to turn.

    – marmot
    3 hours ago






  • 1





    @marmot: I was 3 second faster :o)

    – hpekristiansen
    3 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
    3 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
3 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
3 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
3 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
3 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
3 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
3 hours ago




1




1





@marmot: I was 3 second faster :o)

– hpekristiansen
3 hours ago





@marmot: I was 3 second faster :o)

– hpekristiansen
3 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
3 hours ago





@hpekristiansen Yes, which is why I upvoted your comment. (Mine may still be somewhat useful because one can immediately compile it.)

– marmot
3 hours ago










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}


enter image description here






share|improve this answer
























  • +1: Do you know if this "bug" is officially reported?

    – Dr. Manuel Kuehner
    2 hours ago






  • 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
    2 hours ago








  • 2





    @Dr.ManuelKuehner this "bug" is reported now.

    – Kpym
    1 hour ago











  • Thanks! I do not understand the technicalities but I appreciate the effort.

    – Dr. Manuel Kuehner
    9 mins ago











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


















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}


enter image description here






share|improve this answer
























  • +1: Do you know if this "bug" is officially reported?

    – Dr. Manuel Kuehner
    2 hours ago






  • 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
    2 hours ago








  • 2





    @Dr.ManuelKuehner this "bug" is reported now.

    – Kpym
    1 hour ago











  • Thanks! I do not understand the technicalities but I appreciate the effort.

    – Dr. Manuel Kuehner
    9 mins ago
















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}


enter image description here






share|improve this answer
























  • +1: Do you know if this "bug" is officially reported?

    – Dr. Manuel Kuehner
    2 hours ago






  • 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
    2 hours ago








  • 2





    @Dr.ManuelKuehner this "bug" is reported now.

    – Kpym
    1 hour ago











  • Thanks! I do not understand the technicalities but I appreciate the effort.

    – Dr. Manuel Kuehner
    9 mins ago














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}


enter image description here






share|improve this answer













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}


enter image description here







share|improve this answer












share|improve this answer



share|improve this answer










answered 2 hours ago









KpymKpym

16.2k23988




16.2k23988













  • +1: Do you know if this "bug" is officially reported?

    – Dr. Manuel Kuehner
    2 hours ago






  • 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
    2 hours ago








  • 2





    @Dr.ManuelKuehner this "bug" is reported now.

    – Kpym
    1 hour ago











  • Thanks! I do not understand the technicalities but I appreciate the effort.

    – Dr. Manuel Kuehner
    9 mins ago



















  • +1: Do you know if this "bug" is officially reported?

    – Dr. Manuel Kuehner
    2 hours ago






  • 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
    2 hours ago








  • 2





    @Dr.ManuelKuehner this "bug" is reported now.

    – Kpym
    1 hour ago











  • Thanks! I do not understand the technicalities but I appreciate the effort.

    – Dr. Manuel Kuehner
    9 mins ago

















+1: Do you know if this "bug" is officially reported?

– Dr. Manuel Kuehner
2 hours ago





+1: Do you know if this "bug" is officially reported?

– Dr. Manuel Kuehner
2 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
2 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
2 hours ago






2




2





@Dr.ManuelKuehner this "bug" is reported now.

– Kpym
1 hour ago





@Dr.ManuelKuehner this "bug" is reported now.

– Kpym
1 hour ago













Thanks! I do not understand the technicalities but I appreciate the effort.

– Dr. Manuel Kuehner
9 mins ago





Thanks! I do not understand the technicalities but I appreciate the effort.

– Dr. Manuel Kuehner
9 mins ago


















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














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





















































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







Popular posts from this blog

“%fieldName is a required field.”, in Magento2 REST API Call for GET Method Type The Next...

How to change City field to a dropdown in Checkout step Magento 2Magento 2 : How to change UI field(s)...

夢乃愛華...