Bug in TikZ? Line width on layers

Multi tool use
Multi tool use












16















I found a curios behavior in TikZ. If I set the line width globaly or for the current scope it wont affect the line with inside a {pgfonlayer} but the arrow tips are changed:



line width



Did I found a bug and does anyone know a solution or at least a workaround?



Code



documentclass{minimal}

usepackage{tikz}
pgfdeclarelayer{background}
pgfsetlayers{background,main}

begin{document}
begin{tikzpicture}[line width=5pt]
draw (0,0) -- (5,0);
draw [<->] (0,1) -- (5,1);
begin{pgfonlayer}{background}
draw (0,2) -- (5,2) node [right] {on BG};
draw [<->] (0,3) -- (5,3) node [right] {on BG};
end{pgfonlayer}
end{tikzpicture}
end{document}




Update



As Christian Feuersäger said, it could be a feature that a new layer sets a fully new picture with the default settings. But in this case all settings should be reset. And in my opinion the every picture style should be evaluated anyway.



Here’s an extended example showing the inconsequent behavior with every picture (color is taken only for nodes of background layer, line width is completely ignored and arrow tips are changed even according to the line width setting).

It shows also my workaround, since I’m using a shortcut for the {pgfonlayer} environment it was easy to add a scope which uses every picture. Unfortunately this {scope}doesn’t respect settings given directly to the {tikzpicture}. And it seems to be incompatible with Caramdir’s makeatlettertikz@optionsmakeatother workaround …



documentclass{minimal}

usepackage{tikz}
pgfdeclarelayer{background}
pgfsetlayers{background,main}
tikzset{every picture/.style={line width=5pt,blue,>=stealth}}

newcommand{bglayer}[1]{%
begin{pgfonlayer}{background}
begin{scope}[every picture]
#1
end{scope}
end{pgfonlayer}
}

begin{document}
begin{tikzpicture}[green]
draw (0,0) -- (5,0);
draw [<->] (0,1) -- (5,1);
bglayer{%
draw (0,2) -- (5,2) node [right] {on BG};
draw [<->] (0,3) -- (5,3) node [right] {on BG};
}
end{tikzpicture}
end{document}


example 2





Follow up question: Restore TikZ settings after {pgfonlayer}










share|improve this question

























  • I come across this problem a lot. I'd be very interested to see if it's something we're doing wrong or a bug.

    – qubyte
    Nov 3 '11 at 23:45











  • Just a little comment about the arrows. This shows that arrows are set at "definition-time" in that the shape and size of the arrows are set before the line is stuck into the layer box. Whereas the line width is set at render-time.

    – Loop Space
    Nov 5 '11 at 18:56
















16















I found a curios behavior in TikZ. If I set the line width globaly or for the current scope it wont affect the line with inside a {pgfonlayer} but the arrow tips are changed:



line width



Did I found a bug and does anyone know a solution or at least a workaround?



Code



documentclass{minimal}

usepackage{tikz}
pgfdeclarelayer{background}
pgfsetlayers{background,main}

begin{document}
begin{tikzpicture}[line width=5pt]
draw (0,0) -- (5,0);
draw [<->] (0,1) -- (5,1);
begin{pgfonlayer}{background}
draw (0,2) -- (5,2) node [right] {on BG};
draw [<->] (0,3) -- (5,3) node [right] {on BG};
end{pgfonlayer}
end{tikzpicture}
end{document}




Update



As Christian Feuersäger said, it could be a feature that a new layer sets a fully new picture with the default settings. But in this case all settings should be reset. And in my opinion the every picture style should be evaluated anyway.



Here’s an extended example showing the inconsequent behavior with every picture (color is taken only for nodes of background layer, line width is completely ignored and arrow tips are changed even according to the line width setting).

It shows also my workaround, since I’m using a shortcut for the {pgfonlayer} environment it was easy to add a scope which uses every picture. Unfortunately this {scope}doesn’t respect settings given directly to the {tikzpicture}. And it seems to be incompatible with Caramdir’s makeatlettertikz@optionsmakeatother workaround …



documentclass{minimal}

usepackage{tikz}
pgfdeclarelayer{background}
pgfsetlayers{background,main}
tikzset{every picture/.style={line width=5pt,blue,>=stealth}}

newcommand{bglayer}[1]{%
begin{pgfonlayer}{background}
begin{scope}[every picture]
#1
end{scope}
end{pgfonlayer}
}

begin{document}
begin{tikzpicture}[green]
draw (0,0) -- (5,0);
draw [<->] (0,1) -- (5,1);
bglayer{%
draw (0,2) -- (5,2) node [right] {on BG};
draw [<->] (0,3) -- (5,3) node [right] {on BG};
}
end{tikzpicture}
end{document}


example 2





Follow up question: Restore TikZ settings after {pgfonlayer}










share|improve this question

























  • I come across this problem a lot. I'd be very interested to see if it's something we're doing wrong or a bug.

    – qubyte
    Nov 3 '11 at 23:45











  • Just a little comment about the arrows. This shows that arrows are set at "definition-time" in that the shape and size of the arrows are set before the line is stuck into the layer box. Whereas the line width is set at render-time.

    – Loop Space
    Nov 5 '11 at 18:56














16












16








16








I found a curios behavior in TikZ. If I set the line width globaly or for the current scope it wont affect the line with inside a {pgfonlayer} but the arrow tips are changed:



line width



Did I found a bug and does anyone know a solution or at least a workaround?



Code



documentclass{minimal}

usepackage{tikz}
pgfdeclarelayer{background}
pgfsetlayers{background,main}

begin{document}
begin{tikzpicture}[line width=5pt]
draw (0,0) -- (5,0);
draw [<->] (0,1) -- (5,1);
begin{pgfonlayer}{background}
draw (0,2) -- (5,2) node [right] {on BG};
draw [<->] (0,3) -- (5,3) node [right] {on BG};
end{pgfonlayer}
end{tikzpicture}
end{document}




Update



As Christian Feuersäger said, it could be a feature that a new layer sets a fully new picture with the default settings. But in this case all settings should be reset. And in my opinion the every picture style should be evaluated anyway.



Here’s an extended example showing the inconsequent behavior with every picture (color is taken only for nodes of background layer, line width is completely ignored and arrow tips are changed even according to the line width setting).

It shows also my workaround, since I’m using a shortcut for the {pgfonlayer} environment it was easy to add a scope which uses every picture. Unfortunately this {scope}doesn’t respect settings given directly to the {tikzpicture}. And it seems to be incompatible with Caramdir’s makeatlettertikz@optionsmakeatother workaround …



documentclass{minimal}

usepackage{tikz}
pgfdeclarelayer{background}
pgfsetlayers{background,main}
tikzset{every picture/.style={line width=5pt,blue,>=stealth}}

newcommand{bglayer}[1]{%
begin{pgfonlayer}{background}
begin{scope}[every picture]
#1
end{scope}
end{pgfonlayer}
}

begin{document}
begin{tikzpicture}[green]
draw (0,0) -- (5,0);
draw [<->] (0,1) -- (5,1);
bglayer{%
draw (0,2) -- (5,2) node [right] {on BG};
draw [<->] (0,3) -- (5,3) node [right] {on BG};
}
end{tikzpicture}
end{document}


example 2





Follow up question: Restore TikZ settings after {pgfonlayer}










share|improve this question
















I found a curios behavior in TikZ. If I set the line width globaly or for the current scope it wont affect the line with inside a {pgfonlayer} but the arrow tips are changed:



line width



Did I found a bug and does anyone know a solution or at least a workaround?



Code



documentclass{minimal}

usepackage{tikz}
pgfdeclarelayer{background}
pgfsetlayers{background,main}

begin{document}
begin{tikzpicture}[line width=5pt]
draw (0,0) -- (5,0);
draw [<->] (0,1) -- (5,1);
begin{pgfonlayer}{background}
draw (0,2) -- (5,2) node [right] {on BG};
draw [<->] (0,3) -- (5,3) node [right] {on BG};
end{pgfonlayer}
end{tikzpicture}
end{document}




Update



As Christian Feuersäger said, it could be a feature that a new layer sets a fully new picture with the default settings. But in this case all settings should be reset. And in my opinion the every picture style should be evaluated anyway.



Here’s an extended example showing the inconsequent behavior with every picture (color is taken only for nodes of background layer, line width is completely ignored and arrow tips are changed even according to the line width setting).

It shows also my workaround, since I’m using a shortcut for the {pgfonlayer} environment it was easy to add a scope which uses every picture. Unfortunately this {scope}doesn’t respect settings given directly to the {tikzpicture}. And it seems to be incompatible with Caramdir’s makeatlettertikz@optionsmakeatother workaround …



documentclass{minimal}

usepackage{tikz}
pgfdeclarelayer{background}
pgfsetlayers{background,main}
tikzset{every picture/.style={line width=5pt,blue,>=stealth}}

newcommand{bglayer}[1]{%
begin{pgfonlayer}{background}
begin{scope}[every picture]
#1
end{scope}
end{pgfonlayer}
}

begin{document}
begin{tikzpicture}[green]
draw (0,0) -- (5,0);
draw [<->] (0,1) -- (5,1);
bglayer{%
draw (0,2) -- (5,2) node [right] {on BG};
draw [<->] (0,3) -- (5,3) node [right] {on BG};
}
end{tikzpicture}
end{document}


example 2





Follow up question: Restore TikZ settings after {pgfonlayer}







tikz-pgf






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 26 mins ago







Tobi

















asked Nov 3 '11 at 21:57









TobiTobi

38k8130254




38k8130254













  • I come across this problem a lot. I'd be very interested to see if it's something we're doing wrong or a bug.

    – qubyte
    Nov 3 '11 at 23:45











  • Just a little comment about the arrows. This shows that arrows are set at "definition-time" in that the shape and size of the arrows are set before the line is stuck into the layer box. Whereas the line width is set at render-time.

    – Loop Space
    Nov 5 '11 at 18:56



















  • I come across this problem a lot. I'd be very interested to see if it's something we're doing wrong or a bug.

    – qubyte
    Nov 3 '11 at 23:45











  • Just a little comment about the arrows. This shows that arrows are set at "definition-time" in that the shape and size of the arrows are set before the line is stuck into the layer box. Whereas the line width is set at render-time.

    – Loop Space
    Nov 5 '11 at 18:56

















I come across this problem a lot. I'd be very interested to see if it's something we're doing wrong or a bug.

– qubyte
Nov 3 '11 at 23:45





I come across this problem a lot. I'd be very interested to see if it's something we're doing wrong or a bug.

– qubyte
Nov 3 '11 at 23:45













Just a little comment about the arrows. This shows that arrows are set at "definition-time" in that the shape and size of the arrows are set before the line is stuck into the layer box. Whereas the line width is set at render-time.

– Loop Space
Nov 5 '11 at 18:56





Just a little comment about the arrows. This shows that arrows are set at "definition-time" in that the shape and size of the arrows are set before the line is stuck into the layer box. Whereas the line width is set at render-time.

– Loop Space
Nov 5 '11 at 18:56










2 Answers
2






active

oldest

votes


















7














As noted in a comment, I believe that the PGF responsible will see your request as a feature request (not a bug report). As such, it might take longer for results. But perhaps the PGF responsible will see that it is quite unexpected that options set for the complete picture are not part of the layer, he may want to implement a fix for that particular part, I do not know.
Many words just to state: I would like a better solution as well. But be prepared to wait (perhaps very long).



In the meantime, it might help to understand how the given layering architecture works in order to avoid such problems.



Here is what I understand of it. It consists of the interaction between




  1. layers

  2. option changes (especially styles)

  3. graphics settings


Usually, you can change options as you want and at any time. If you change styles, the styles will be evaluated on usage (for example every node will be evaluated during node). But options which affect the graphics state (like color, linewidth and similar ones) are different: they are applied by scopes (at least I think so) and by paths (including draw, of course).



Whenever you switch the layer, pgf starts to collect low level drawing instructions into a different box. All low level drawing instructions which have been collected in a different layer will NOT be copied into the new layer.



This is pretty clear. But since "low level drawing instruction" includes things like pgfsetlinewidth as well as color assignments, such settings are not copied to the activated layer as well.



After switching to the new layer, PGF will continue its normal processing. In particular, it will continue to evaluate styles, and these styles still have the same value as they had before switching layers.



I suppose this is also not new for you. But it means that you can (and perhaps should) define (custom) styles to share options between layers. Your approach
with the every picture style actually uses the approach, but it can be applied in general.



For example,



begin{tikzpicture}
tikzset{my style/.style={red,line width=10pt}}
begin{scope}[my style]
...
end{scope}

pgfonlayer{...}
begin{scope}[my style]
...
end{scope}
endpgfonlayer}
end{tikzpicture}


will do the job. It is not as simple as one would like (or expect), I agree. But this is how it has been designed until now; everything else will have to wait (until someone implements an improved version).



In other words: your approach with the every picture is correct and perhaps the only way to do it right now.



Concerning the "reset": as explained, a layer does not introduce a completely new picture. It inherits all current styles and all current options (except for those graphics state options which have already been written to its layer). Thus, "resetting" anything is not an option.






share|improve this answer
























  • Thanks for this explanation! “Concerning the "reset": …” Ok but I thought the size of an arrow tip is depending on the line width so if the line width is set by {pgfonlayer} the arrow tips should be set to the normal size as well, thats what I meant as an inconsequent resetting chiefly.

    – Tobi
    Nov 4 '11 at 15:45











  • @Tobi I see your point.

    – Christian Feuersänger
    Nov 5 '11 at 1:24











  • Hi, it seems like your solution using a {scope} doesn't work anymore (or never has). I created a new example showing the (in my eyes) odd behaviour and be glad if you could take a look: tex.stackexchange.com/q/470351/4918

    – Tobi
    26 mins ago



















7














This seems to be bug in pgf: path styles like pgfsetlinewidth seem to be forgotten when the layers are set. I have no idea why this happens. Here is a minimal example directly in pgf:



documentclass{article}

usepackage{pgf}
pgfdeclarelayer{background}
pgfsetlayers{background,main}

begin{document}
begin{pgfpicture}
pgfsetlinewidth{5pt}
pgfpathmoveto{pgfpointorigin}
pgfpathlineto{pgfpoint{5cm}{0cm}}
pgfusepath{draw}

begin{pgfonlayer}{background}
pgfpathmoveto{pgfpoint{0cm}{1cm}}
pgfpathlineto{pgfpoint{5cm}{1cm}}
pgfusepath{draw}
end{pgfonlayer}
end{pgfpicture}
end{document}


Using TikZ, you can add makeatlettertikz@optionsmakeatother after begin{pgfonlayer}{background}. This should get you the options set in the last scope (or tikzpicture), but it won't work correctly if you have nested scopes (i.e. only the options from the innermost scope are used).






share|improve this answer



















  • 2





    I reported the bug: sourceforge.net/tracker/…

    – Caramdir
    Nov 4 '11 at 0:06











  • Technically, the observed problem arises because each layer collects the complete graphics state on its own. I am honestly unsure of whether this is a bug or a feature request. It should work if you replicate the changes of the graphics state to each layer (for example, by replicating begin{scope}[<options>] for each layer). Anyway, introducing a completely hierarchy graphics state inheritance (which appears to be your expectation) might be way to involved.

    – Christian Feuersänger
    Nov 4 '11 at 8:35













  • @ChristianFeuersänger: But if the actual behavior is a feature all settings should be reset (please see the update to my question).

    – Tobi
    Nov 4 '11 at 9:46











  • There is a slight misunderstanding: I meant it is either a bug report or a feature request. If the pgf responsible considers this to be a bug, he may want to fix it. It he considers it to be a feature request, he may reject or postpone it. I am not responsible for this feature, but I would consider it to be a feature request.

    – Christian Feuersänger
    Nov 4 '11 at 13:23













  • @ChristianFeuersänger: Ah ok. In my opinion it’s a bug since it is so inconsistent (as said in my update) … but either way we have to wait what happens …

    – Tobi
    Nov 4 '11 at 15:39











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%2f33601%2fbug-in-tikz-line-width-on-layers%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes









7














As noted in a comment, I believe that the PGF responsible will see your request as a feature request (not a bug report). As such, it might take longer for results. But perhaps the PGF responsible will see that it is quite unexpected that options set for the complete picture are not part of the layer, he may want to implement a fix for that particular part, I do not know.
Many words just to state: I would like a better solution as well. But be prepared to wait (perhaps very long).



In the meantime, it might help to understand how the given layering architecture works in order to avoid such problems.



Here is what I understand of it. It consists of the interaction between




  1. layers

  2. option changes (especially styles)

  3. graphics settings


Usually, you can change options as you want and at any time. If you change styles, the styles will be evaluated on usage (for example every node will be evaluated during node). But options which affect the graphics state (like color, linewidth and similar ones) are different: they are applied by scopes (at least I think so) and by paths (including draw, of course).



Whenever you switch the layer, pgf starts to collect low level drawing instructions into a different box. All low level drawing instructions which have been collected in a different layer will NOT be copied into the new layer.



This is pretty clear. But since "low level drawing instruction" includes things like pgfsetlinewidth as well as color assignments, such settings are not copied to the activated layer as well.



After switching to the new layer, PGF will continue its normal processing. In particular, it will continue to evaluate styles, and these styles still have the same value as they had before switching layers.



I suppose this is also not new for you. But it means that you can (and perhaps should) define (custom) styles to share options between layers. Your approach
with the every picture style actually uses the approach, but it can be applied in general.



For example,



begin{tikzpicture}
tikzset{my style/.style={red,line width=10pt}}
begin{scope}[my style]
...
end{scope}

pgfonlayer{...}
begin{scope}[my style]
...
end{scope}
endpgfonlayer}
end{tikzpicture}


will do the job. It is not as simple as one would like (or expect), I agree. But this is how it has been designed until now; everything else will have to wait (until someone implements an improved version).



In other words: your approach with the every picture is correct and perhaps the only way to do it right now.



Concerning the "reset": as explained, a layer does not introduce a completely new picture. It inherits all current styles and all current options (except for those graphics state options which have already been written to its layer). Thus, "resetting" anything is not an option.






share|improve this answer
























  • Thanks for this explanation! “Concerning the "reset": …” Ok but I thought the size of an arrow tip is depending on the line width so if the line width is set by {pgfonlayer} the arrow tips should be set to the normal size as well, thats what I meant as an inconsequent resetting chiefly.

    – Tobi
    Nov 4 '11 at 15:45











  • @Tobi I see your point.

    – Christian Feuersänger
    Nov 5 '11 at 1:24











  • Hi, it seems like your solution using a {scope} doesn't work anymore (or never has). I created a new example showing the (in my eyes) odd behaviour and be glad if you could take a look: tex.stackexchange.com/q/470351/4918

    – Tobi
    26 mins ago
















7














As noted in a comment, I believe that the PGF responsible will see your request as a feature request (not a bug report). As such, it might take longer for results. But perhaps the PGF responsible will see that it is quite unexpected that options set for the complete picture are not part of the layer, he may want to implement a fix for that particular part, I do not know.
Many words just to state: I would like a better solution as well. But be prepared to wait (perhaps very long).



In the meantime, it might help to understand how the given layering architecture works in order to avoid such problems.



Here is what I understand of it. It consists of the interaction between




  1. layers

  2. option changes (especially styles)

  3. graphics settings


Usually, you can change options as you want and at any time. If you change styles, the styles will be evaluated on usage (for example every node will be evaluated during node). But options which affect the graphics state (like color, linewidth and similar ones) are different: they are applied by scopes (at least I think so) and by paths (including draw, of course).



Whenever you switch the layer, pgf starts to collect low level drawing instructions into a different box. All low level drawing instructions which have been collected in a different layer will NOT be copied into the new layer.



This is pretty clear. But since "low level drawing instruction" includes things like pgfsetlinewidth as well as color assignments, such settings are not copied to the activated layer as well.



After switching to the new layer, PGF will continue its normal processing. In particular, it will continue to evaluate styles, and these styles still have the same value as they had before switching layers.



I suppose this is also not new for you. But it means that you can (and perhaps should) define (custom) styles to share options between layers. Your approach
with the every picture style actually uses the approach, but it can be applied in general.



For example,



begin{tikzpicture}
tikzset{my style/.style={red,line width=10pt}}
begin{scope}[my style]
...
end{scope}

pgfonlayer{...}
begin{scope}[my style]
...
end{scope}
endpgfonlayer}
end{tikzpicture}


will do the job. It is not as simple as one would like (or expect), I agree. But this is how it has been designed until now; everything else will have to wait (until someone implements an improved version).



In other words: your approach with the every picture is correct and perhaps the only way to do it right now.



Concerning the "reset": as explained, a layer does not introduce a completely new picture. It inherits all current styles and all current options (except for those graphics state options which have already been written to its layer). Thus, "resetting" anything is not an option.






share|improve this answer
























  • Thanks for this explanation! “Concerning the "reset": …” Ok but I thought the size of an arrow tip is depending on the line width so if the line width is set by {pgfonlayer} the arrow tips should be set to the normal size as well, thats what I meant as an inconsequent resetting chiefly.

    – Tobi
    Nov 4 '11 at 15:45











  • @Tobi I see your point.

    – Christian Feuersänger
    Nov 5 '11 at 1:24











  • Hi, it seems like your solution using a {scope} doesn't work anymore (or never has). I created a new example showing the (in my eyes) odd behaviour and be glad if you could take a look: tex.stackexchange.com/q/470351/4918

    – Tobi
    26 mins ago














7












7








7







As noted in a comment, I believe that the PGF responsible will see your request as a feature request (not a bug report). As such, it might take longer for results. But perhaps the PGF responsible will see that it is quite unexpected that options set for the complete picture are not part of the layer, he may want to implement a fix for that particular part, I do not know.
Many words just to state: I would like a better solution as well. But be prepared to wait (perhaps very long).



In the meantime, it might help to understand how the given layering architecture works in order to avoid such problems.



Here is what I understand of it. It consists of the interaction between




  1. layers

  2. option changes (especially styles)

  3. graphics settings


Usually, you can change options as you want and at any time. If you change styles, the styles will be evaluated on usage (for example every node will be evaluated during node). But options which affect the graphics state (like color, linewidth and similar ones) are different: they are applied by scopes (at least I think so) and by paths (including draw, of course).



Whenever you switch the layer, pgf starts to collect low level drawing instructions into a different box. All low level drawing instructions which have been collected in a different layer will NOT be copied into the new layer.



This is pretty clear. But since "low level drawing instruction" includes things like pgfsetlinewidth as well as color assignments, such settings are not copied to the activated layer as well.



After switching to the new layer, PGF will continue its normal processing. In particular, it will continue to evaluate styles, and these styles still have the same value as they had before switching layers.



I suppose this is also not new for you. But it means that you can (and perhaps should) define (custom) styles to share options between layers. Your approach
with the every picture style actually uses the approach, but it can be applied in general.



For example,



begin{tikzpicture}
tikzset{my style/.style={red,line width=10pt}}
begin{scope}[my style]
...
end{scope}

pgfonlayer{...}
begin{scope}[my style]
...
end{scope}
endpgfonlayer}
end{tikzpicture}


will do the job. It is not as simple as one would like (or expect), I agree. But this is how it has been designed until now; everything else will have to wait (until someone implements an improved version).



In other words: your approach with the every picture is correct and perhaps the only way to do it right now.



Concerning the "reset": as explained, a layer does not introduce a completely new picture. It inherits all current styles and all current options (except for those graphics state options which have already been written to its layer). Thus, "resetting" anything is not an option.






share|improve this answer













As noted in a comment, I believe that the PGF responsible will see your request as a feature request (not a bug report). As such, it might take longer for results. But perhaps the PGF responsible will see that it is quite unexpected that options set for the complete picture are not part of the layer, he may want to implement a fix for that particular part, I do not know.
Many words just to state: I would like a better solution as well. But be prepared to wait (perhaps very long).



In the meantime, it might help to understand how the given layering architecture works in order to avoid such problems.



Here is what I understand of it. It consists of the interaction between




  1. layers

  2. option changes (especially styles)

  3. graphics settings


Usually, you can change options as you want and at any time. If you change styles, the styles will be evaluated on usage (for example every node will be evaluated during node). But options which affect the graphics state (like color, linewidth and similar ones) are different: they are applied by scopes (at least I think so) and by paths (including draw, of course).



Whenever you switch the layer, pgf starts to collect low level drawing instructions into a different box. All low level drawing instructions which have been collected in a different layer will NOT be copied into the new layer.



This is pretty clear. But since "low level drawing instruction" includes things like pgfsetlinewidth as well as color assignments, such settings are not copied to the activated layer as well.



After switching to the new layer, PGF will continue its normal processing. In particular, it will continue to evaluate styles, and these styles still have the same value as they had before switching layers.



I suppose this is also not new for you. But it means that you can (and perhaps should) define (custom) styles to share options between layers. Your approach
with the every picture style actually uses the approach, but it can be applied in general.



For example,



begin{tikzpicture}
tikzset{my style/.style={red,line width=10pt}}
begin{scope}[my style]
...
end{scope}

pgfonlayer{...}
begin{scope}[my style]
...
end{scope}
endpgfonlayer}
end{tikzpicture}


will do the job. It is not as simple as one would like (or expect), I agree. But this is how it has been designed until now; everything else will have to wait (until someone implements an improved version).



In other words: your approach with the every picture is correct and perhaps the only way to do it right now.



Concerning the "reset": as explained, a layer does not introduce a completely new picture. It inherits all current styles and all current options (except for those graphics state options which have already been written to its layer). Thus, "resetting" anything is not an option.







share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 4 '11 at 13:42









Christian FeuersängerChristian Feuersänger

48.8k4114172




48.8k4114172













  • Thanks for this explanation! “Concerning the "reset": …” Ok but I thought the size of an arrow tip is depending on the line width so if the line width is set by {pgfonlayer} the arrow tips should be set to the normal size as well, thats what I meant as an inconsequent resetting chiefly.

    – Tobi
    Nov 4 '11 at 15:45











  • @Tobi I see your point.

    – Christian Feuersänger
    Nov 5 '11 at 1:24











  • Hi, it seems like your solution using a {scope} doesn't work anymore (or never has). I created a new example showing the (in my eyes) odd behaviour and be glad if you could take a look: tex.stackexchange.com/q/470351/4918

    – Tobi
    26 mins ago



















  • Thanks for this explanation! “Concerning the "reset": …” Ok but I thought the size of an arrow tip is depending on the line width so if the line width is set by {pgfonlayer} the arrow tips should be set to the normal size as well, thats what I meant as an inconsequent resetting chiefly.

    – Tobi
    Nov 4 '11 at 15:45











  • @Tobi I see your point.

    – Christian Feuersänger
    Nov 5 '11 at 1:24











  • Hi, it seems like your solution using a {scope} doesn't work anymore (or never has). I created a new example showing the (in my eyes) odd behaviour and be glad if you could take a look: tex.stackexchange.com/q/470351/4918

    – Tobi
    26 mins ago

















Thanks for this explanation! “Concerning the "reset": …” Ok but I thought the size of an arrow tip is depending on the line width so if the line width is set by {pgfonlayer} the arrow tips should be set to the normal size as well, thats what I meant as an inconsequent resetting chiefly.

– Tobi
Nov 4 '11 at 15:45





Thanks for this explanation! “Concerning the "reset": …” Ok but I thought the size of an arrow tip is depending on the line width so if the line width is set by {pgfonlayer} the arrow tips should be set to the normal size as well, thats what I meant as an inconsequent resetting chiefly.

– Tobi
Nov 4 '11 at 15:45













@Tobi I see your point.

– Christian Feuersänger
Nov 5 '11 at 1:24





@Tobi I see your point.

– Christian Feuersänger
Nov 5 '11 at 1:24













Hi, it seems like your solution using a {scope} doesn't work anymore (or never has). I created a new example showing the (in my eyes) odd behaviour and be glad if you could take a look: tex.stackexchange.com/q/470351/4918

– Tobi
26 mins ago





Hi, it seems like your solution using a {scope} doesn't work anymore (or never has). I created a new example showing the (in my eyes) odd behaviour and be glad if you could take a look: tex.stackexchange.com/q/470351/4918

– Tobi
26 mins ago











7














This seems to be bug in pgf: path styles like pgfsetlinewidth seem to be forgotten when the layers are set. I have no idea why this happens. Here is a minimal example directly in pgf:



documentclass{article}

usepackage{pgf}
pgfdeclarelayer{background}
pgfsetlayers{background,main}

begin{document}
begin{pgfpicture}
pgfsetlinewidth{5pt}
pgfpathmoveto{pgfpointorigin}
pgfpathlineto{pgfpoint{5cm}{0cm}}
pgfusepath{draw}

begin{pgfonlayer}{background}
pgfpathmoveto{pgfpoint{0cm}{1cm}}
pgfpathlineto{pgfpoint{5cm}{1cm}}
pgfusepath{draw}
end{pgfonlayer}
end{pgfpicture}
end{document}


Using TikZ, you can add makeatlettertikz@optionsmakeatother after begin{pgfonlayer}{background}. This should get you the options set in the last scope (or tikzpicture), but it won't work correctly if you have nested scopes (i.e. only the options from the innermost scope are used).






share|improve this answer



















  • 2





    I reported the bug: sourceforge.net/tracker/…

    – Caramdir
    Nov 4 '11 at 0:06











  • Technically, the observed problem arises because each layer collects the complete graphics state on its own. I am honestly unsure of whether this is a bug or a feature request. It should work if you replicate the changes of the graphics state to each layer (for example, by replicating begin{scope}[<options>] for each layer). Anyway, introducing a completely hierarchy graphics state inheritance (which appears to be your expectation) might be way to involved.

    – Christian Feuersänger
    Nov 4 '11 at 8:35













  • @ChristianFeuersänger: But if the actual behavior is a feature all settings should be reset (please see the update to my question).

    – Tobi
    Nov 4 '11 at 9:46











  • There is a slight misunderstanding: I meant it is either a bug report or a feature request. If the pgf responsible considers this to be a bug, he may want to fix it. It he considers it to be a feature request, he may reject or postpone it. I am not responsible for this feature, but I would consider it to be a feature request.

    – Christian Feuersänger
    Nov 4 '11 at 13:23













  • @ChristianFeuersänger: Ah ok. In my opinion it’s a bug since it is so inconsistent (as said in my update) … but either way we have to wait what happens …

    – Tobi
    Nov 4 '11 at 15:39
















7














This seems to be bug in pgf: path styles like pgfsetlinewidth seem to be forgotten when the layers are set. I have no idea why this happens. Here is a minimal example directly in pgf:



documentclass{article}

usepackage{pgf}
pgfdeclarelayer{background}
pgfsetlayers{background,main}

begin{document}
begin{pgfpicture}
pgfsetlinewidth{5pt}
pgfpathmoveto{pgfpointorigin}
pgfpathlineto{pgfpoint{5cm}{0cm}}
pgfusepath{draw}

begin{pgfonlayer}{background}
pgfpathmoveto{pgfpoint{0cm}{1cm}}
pgfpathlineto{pgfpoint{5cm}{1cm}}
pgfusepath{draw}
end{pgfonlayer}
end{pgfpicture}
end{document}


Using TikZ, you can add makeatlettertikz@optionsmakeatother after begin{pgfonlayer}{background}. This should get you the options set in the last scope (or tikzpicture), but it won't work correctly if you have nested scopes (i.e. only the options from the innermost scope are used).






share|improve this answer



















  • 2





    I reported the bug: sourceforge.net/tracker/…

    – Caramdir
    Nov 4 '11 at 0:06











  • Technically, the observed problem arises because each layer collects the complete graphics state on its own. I am honestly unsure of whether this is a bug or a feature request. It should work if you replicate the changes of the graphics state to each layer (for example, by replicating begin{scope}[<options>] for each layer). Anyway, introducing a completely hierarchy graphics state inheritance (which appears to be your expectation) might be way to involved.

    – Christian Feuersänger
    Nov 4 '11 at 8:35













  • @ChristianFeuersänger: But if the actual behavior is a feature all settings should be reset (please see the update to my question).

    – Tobi
    Nov 4 '11 at 9:46











  • There is a slight misunderstanding: I meant it is either a bug report or a feature request. If the pgf responsible considers this to be a bug, he may want to fix it. It he considers it to be a feature request, he may reject or postpone it. I am not responsible for this feature, but I would consider it to be a feature request.

    – Christian Feuersänger
    Nov 4 '11 at 13:23













  • @ChristianFeuersänger: Ah ok. In my opinion it’s a bug since it is so inconsistent (as said in my update) … but either way we have to wait what happens …

    – Tobi
    Nov 4 '11 at 15:39














7












7








7







This seems to be bug in pgf: path styles like pgfsetlinewidth seem to be forgotten when the layers are set. I have no idea why this happens. Here is a minimal example directly in pgf:



documentclass{article}

usepackage{pgf}
pgfdeclarelayer{background}
pgfsetlayers{background,main}

begin{document}
begin{pgfpicture}
pgfsetlinewidth{5pt}
pgfpathmoveto{pgfpointorigin}
pgfpathlineto{pgfpoint{5cm}{0cm}}
pgfusepath{draw}

begin{pgfonlayer}{background}
pgfpathmoveto{pgfpoint{0cm}{1cm}}
pgfpathlineto{pgfpoint{5cm}{1cm}}
pgfusepath{draw}
end{pgfonlayer}
end{pgfpicture}
end{document}


Using TikZ, you can add makeatlettertikz@optionsmakeatother after begin{pgfonlayer}{background}. This should get you the options set in the last scope (or tikzpicture), but it won't work correctly if you have nested scopes (i.e. only the options from the innermost scope are used).






share|improve this answer













This seems to be bug in pgf: path styles like pgfsetlinewidth seem to be forgotten when the layers are set. I have no idea why this happens. Here is a minimal example directly in pgf:



documentclass{article}

usepackage{pgf}
pgfdeclarelayer{background}
pgfsetlayers{background,main}

begin{document}
begin{pgfpicture}
pgfsetlinewidth{5pt}
pgfpathmoveto{pgfpointorigin}
pgfpathlineto{pgfpoint{5cm}{0cm}}
pgfusepath{draw}

begin{pgfonlayer}{background}
pgfpathmoveto{pgfpoint{0cm}{1cm}}
pgfpathlineto{pgfpoint{5cm}{1cm}}
pgfusepath{draw}
end{pgfonlayer}
end{pgfpicture}
end{document}


Using TikZ, you can add makeatlettertikz@optionsmakeatother after begin{pgfonlayer}{background}. This should get you the options set in the last scope (or tikzpicture), but it won't work correctly if you have nested scopes (i.e. only the options from the innermost scope are used).







share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 4 '11 at 0:03









CaramdirCaramdir

63.9k19213272




63.9k19213272








  • 2





    I reported the bug: sourceforge.net/tracker/…

    – Caramdir
    Nov 4 '11 at 0:06











  • Technically, the observed problem arises because each layer collects the complete graphics state on its own. I am honestly unsure of whether this is a bug or a feature request. It should work if you replicate the changes of the graphics state to each layer (for example, by replicating begin{scope}[<options>] for each layer). Anyway, introducing a completely hierarchy graphics state inheritance (which appears to be your expectation) might be way to involved.

    – Christian Feuersänger
    Nov 4 '11 at 8:35













  • @ChristianFeuersänger: But if the actual behavior is a feature all settings should be reset (please see the update to my question).

    – Tobi
    Nov 4 '11 at 9:46











  • There is a slight misunderstanding: I meant it is either a bug report or a feature request. If the pgf responsible considers this to be a bug, he may want to fix it. It he considers it to be a feature request, he may reject or postpone it. I am not responsible for this feature, but I would consider it to be a feature request.

    – Christian Feuersänger
    Nov 4 '11 at 13:23













  • @ChristianFeuersänger: Ah ok. In my opinion it’s a bug since it is so inconsistent (as said in my update) … but either way we have to wait what happens …

    – Tobi
    Nov 4 '11 at 15:39














  • 2





    I reported the bug: sourceforge.net/tracker/…

    – Caramdir
    Nov 4 '11 at 0:06











  • Technically, the observed problem arises because each layer collects the complete graphics state on its own. I am honestly unsure of whether this is a bug or a feature request. It should work if you replicate the changes of the graphics state to each layer (for example, by replicating begin{scope}[<options>] for each layer). Anyway, introducing a completely hierarchy graphics state inheritance (which appears to be your expectation) might be way to involved.

    – Christian Feuersänger
    Nov 4 '11 at 8:35













  • @ChristianFeuersänger: But if the actual behavior is a feature all settings should be reset (please see the update to my question).

    – Tobi
    Nov 4 '11 at 9:46











  • There is a slight misunderstanding: I meant it is either a bug report or a feature request. If the pgf responsible considers this to be a bug, he may want to fix it. It he considers it to be a feature request, he may reject or postpone it. I am not responsible for this feature, but I would consider it to be a feature request.

    – Christian Feuersänger
    Nov 4 '11 at 13:23













  • @ChristianFeuersänger: Ah ok. In my opinion it’s a bug since it is so inconsistent (as said in my update) … but either way we have to wait what happens …

    – Tobi
    Nov 4 '11 at 15:39








2




2





I reported the bug: sourceforge.net/tracker/…

– Caramdir
Nov 4 '11 at 0:06





I reported the bug: sourceforge.net/tracker/…

– Caramdir
Nov 4 '11 at 0:06













Technically, the observed problem arises because each layer collects the complete graphics state on its own. I am honestly unsure of whether this is a bug or a feature request. It should work if you replicate the changes of the graphics state to each layer (for example, by replicating begin{scope}[<options>] for each layer). Anyway, introducing a completely hierarchy graphics state inheritance (which appears to be your expectation) might be way to involved.

– Christian Feuersänger
Nov 4 '11 at 8:35







Technically, the observed problem arises because each layer collects the complete graphics state on its own. I am honestly unsure of whether this is a bug or a feature request. It should work if you replicate the changes of the graphics state to each layer (for example, by replicating begin{scope}[<options>] for each layer). Anyway, introducing a completely hierarchy graphics state inheritance (which appears to be your expectation) might be way to involved.

– Christian Feuersänger
Nov 4 '11 at 8:35















@ChristianFeuersänger: But if the actual behavior is a feature all settings should be reset (please see the update to my question).

– Tobi
Nov 4 '11 at 9:46





@ChristianFeuersänger: But if the actual behavior is a feature all settings should be reset (please see the update to my question).

– Tobi
Nov 4 '11 at 9:46













There is a slight misunderstanding: I meant it is either a bug report or a feature request. If the pgf responsible considers this to be a bug, he may want to fix it. It he considers it to be a feature request, he may reject or postpone it. I am not responsible for this feature, but I would consider it to be a feature request.

– Christian Feuersänger
Nov 4 '11 at 13:23







There is a slight misunderstanding: I meant it is either a bug report or a feature request. If the pgf responsible considers this to be a bug, he may want to fix it. It he considers it to be a feature request, he may reject or postpone it. I am not responsible for this feature, but I would consider it to be a feature request.

– Christian Feuersänger
Nov 4 '11 at 13:23















@ChristianFeuersänger: Ah ok. In my opinion it’s a bug since it is so inconsistent (as said in my update) … but either way we have to wait what happens …

– Tobi
Nov 4 '11 at 15:39





@ChristianFeuersänger: Ah ok. In my opinion it’s a bug since it is so inconsistent (as said in my update) … but either way we have to wait what happens …

– Tobi
Nov 4 '11 at 15:39


















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%2f33601%2fbug-in-tikz-line-width-on-layers%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







Y 2TJxfRtyG J,YNA0V
df4b,H,Ta BCkcNyK4VMwiz

Popular posts from this blog

A CLEAN and SIMPLE way to add appendices to Table of Contents and bookmarks

Calculate evaluation metrics using cross_val_predict sklearn

Insert data from modal to MySQL (multiple modal on website)