| 28 Sep 2021 |
 Paulo Cereda | ooh :) | 18:32:43 |
 kir∅ul | Should the #latex:crossbach.de room also be added to this space? | 18:45:05 |
 samcarter | In reply to @cereda:matrix.org
🦆 Now that the ducks are here, this chat immediately feels like home :) | 19:41:41 |
 hmenke | kir∅ul: I don't think this channel has any relation to TUG. | 19:53:26 |
| kir∅ul | In reply to @hmenke:matrix.org
kir∅ul: I don't think this channel has any relation to TUG. Ah ok, I guess I misunderstood the aim of this space 😬 | 20:02:18 |
| kir∅ul | In reply to @hmenke:matrix.org
kir∅ul: I don't think this channel has any relation to TUG. * Ah oops, I guess I misunderstood the aim of this space 😬 | 20:16:47 |
 Norbert Preining | The space is TUG, that is right, but channels can be related to anything around TeX etc ... | 22:13:21 |
| kir∅ul | In reply to @kir0ul:matrix.org
Should the #latex:crossbach.de room also be added to this space? In case the Matrix space is not only for TUG related channels then there's also the #iot-community:matrix.org room. | 22:31:52 |
| 29 Sep 2021 |
|  Merlin Göttlinger joined the room. | 05:35:51 |
|  Romano Giannetti joined the room. | 09:26:36 |
| Romano Giannetti set a profile picture. | 09:27:20 |
|  निरंजन joined the room. | 12:30:39 |
 josephwright | Did people see https://tex.stackexchange.com/questions/617175/pdf-is-modified-when-included-in-a-tikz-environment? I wonder if all graphic state values should reset at the start of a picture | 13:50:29 |
| hmenke | josephwright: https://github.com/pgf-tikz/pgf/issues/870 | 14:05:11 |
| hmenke | The problem is that changing this now will break an unknown number of existing documents. | 14:05:30 |
| hmenke | If this behavior is desired, users can do
\tikzset{
every picture/.style={
execute at begin picture={
\pgfsetbuttcap%
\pgfsetmiterjoin%
\pgfsetmiterlimit{10}%
\pgfsetdash{}{0pt}%
}
}
}
| 14:06:21 |
| hmenke | * If this behavior is desired, users can do
\tikzset{
every picture/.style={%
execute at begin picture={%
\pgfsetbuttcap%
\pgfsetmiterjoin%
\pgfsetmiterlimit{10}%
\pgfsetdash{}{0pt}%
}
}
}
| 14:06:38 |
| josephwright | hmenke: Thanks | 14:06:55 |
| hmenke | Maybe I should document all the things that are intentionally left broken at some point. | 14:07:56 |
| josephwright | hmenke: I might make a different decision for l3draw: I think one could of course argue this is a flaw in the PDF format | 14:08:36 |
| hmenke | This is a general problem of any stack-based system. | 14:09:12 |
| hmenke | You definitely should reset the graphics state in l3draw at the beginning of every picture. | 14:09:42 |
| josephwright | hmenke: There will be an update later today then :) | 14:09:59 |
| hmenke | I would really like to do this too, but as I remarked already, this has the potential of silently breaking old documents. | 14:10:26 |
| hmenke | And I don't want to get into writing a compat feature like pgfplots. | 14:10:46 |
| josephwright | hmenke: Thanks - I'll point to this info | 14:10:54 |
| hmenke | Also be careful to not reset to much stuff. Things like transparency and blend mode should probably carry over to nested pictures. | 14:11:49 |
| hmenke | * Also be careful to not reset too much stuff. Things like transparency and blend mode should probably carry over to nested pictures. | 14:11:58 |
| josephwright | In reply to @hmenke:matrix.org
Also be careful to not reset too much stuff. Things like transparency and blend mode should probably carry over to nested pictures. I'm lucky that l3draw is still very experimental, so I can change some stuff and kick the rest 'down the road' | 14:13:44 |
| hmenke | You're also lucky that l3draw has tests from the very start. | 14:14:34 |
