some fixes for old version of tikz, such as TeXLive <= 2018#22
Conversation
| \RequirePackage{xcolor} | ||
| \RequirePackage{tikz} | ||
| \usetikzlibrary{patterns.meta,calc} | ||
| \usetikzlibrary{calc} |
There was a problem hiding this comment.
I see that \usetikzlibrary{patterns.meta} is on line 774 below. Why is that necessary?
There was a problem hiding this comment.
The old version of patterns.meta (~2015, which is what I have in TeXLive 2018) redefines some tikz-internal commands (specifically \pgf@declarepattern) to use macros that pgf doesn't know about. So the patterns other than lightcones which use pgfdeclarepatternformonly break.
| } | ||
| \tikzdeclarepattern{ | ||
| name=lightcones, | ||
| \tikzdeclarepattern{name=lightcones, |
There was a problem hiding this comment.
This linebreak removal was not needed
There was a problem hiding this comment.
I just looked at your issue #21 and saw your comment about whitespace sensitivity. Is this what you were referring to?
There was a problem hiding this comment.
Yes; \tikzdeclarepattern can't handle whitespace before name= on old versions. I get "pattern lightcones not defined" (paraphrased) if I include the linebreak.
There was a problem hiding this comment.
That is very surprising... that makes it sound like it's doing some low-level parsing. Anyway, does it work if you instead add a percent line ending?
\tikzdeclarepattern{%
name=lightcones,There was a problem hiding this comment.
Yeah, it seems the linebreak is the problem, not all whitespace. I can push a commit changing this if you like!
There was a problem hiding this comment.
TeXLive 2018 patterns.meta code snippet:
\def\pgfdeclarepattern#1{% \begingroup% \nullfont% \def\pgf@pat@options{#1}% \pgfkeys{/pgf/patterns/.cd, #1}% \pgf@declarepattern% \endgroup% } \def\pgf@declarepattern{% \pgfifpatternundefined{\pgf@pat@name}{%
Latest patterns.meta code snippet:
\def\pgfdeclarepattern#1{% \begingroup% \nullfont% \def\pgf@pat@options{,#1}%
...
\pgf@declarepattern@meta% \endgroup% }% \def\pgf@declarepattern@meta{%
...
In the new version, a comma has been added (fixing the linebreak issue, I suspect) and the helper command is renamed with meta at the end to avoid overwriting the old pgf command. So both these were bugs in PGF/Tikz that have been fixed only (relatively) recently.
| \GP@declarelightconepat | ||
| \GP@declaredotpat | ||
|
|
||
| \usetikzlibrary{patterns.meta} | ||
| \GP@declarelightconepat | ||
|
|
There was a problem hiding this comment.
Is this needed? Why not keep the \usetikzlibrary{patterns.meta} up above (like it was originally), and keep the order of pattern declaration the same?
There was a problem hiding this comment.
See comment above on where it was removed. The 'early' GP@declares use pgfdeclarepatternformonly; GP@declarelightconepat uses tikzdeclarepattern, which is part of patterns.meta. This is a kludgy workaround for the fact that old versions of patterns.meta break pgf's pattern declaration.
|
Thanks for your help, @tdwiser! Please see questions above. |
|
I added some short explanations in comments to hopefully preserve these bugfixes in future versions! |
|
@mcnees and @tdwiser, should we make this PR dependent on whether or not we can fix the pattern shifting bug? We separately talked about fixing it for light cones by no longer using the pgf/tikz patterns, and just drawing a tilted grid (#23). If we completely avoid using pgf/tikz patterns, then the bugs related to patterns.meta go away (the dashing one is independent). But can we completely avoid the pattern code, or do we even want to? Maybe the pgf folks will figure out the correct shifting? |
|
One option to clean up this PR and make it less dependent on the lightcone/pattern issue would be translating all patterns to the new tikz format, which is what @mcnees did for some of them already in #19 . The only thing to ensure there is that we protect that first newline with a %. If you like this idea I can work on implementing it and testing on TL2018. |
2 participants
Addresses Issue #21 (not yet extensively tested on current TeXLive!!!)