tikzexternalize, list-and-make, list of figures to be updated
I am using tikz' externalize library on windows. Since my document contains graphics with ref
, I need to use list and make
instead of convert with system call
.
Since I am working on windows, I cannot use make main.makefile
, as was also reported in this question.
Issuing the correct system calls is not a problem. However, I do not know how to find out which figures need to be updated since main.figlist
seems to always list all figures. externalize
obviously checks for whether a figure needs to be updated before issuing the system call, and I believe something like this is included in the makefile as well.
Unfortunately I do not know how makefiles work.
Is there a way to issue this check manually, or can I get a list of outdated figures?
The generated makefiles look as follows:
ALL_FIGURE_NAMES=$(shell cat thesis.figlist)
ALL_FIGURES=$(ALL_FIGURE_NAMES:%=%.pdf)
allimages: $(ALL_FIGURES)
@echo All images exist now. Use make -B to re-generate them.
FORCEREMAKE:
include $(ALL_FIGURE_NAMES:%=%.dep)
%.dep:
mkdir -p "$(dir $@)"
touch "$@" # will be filled later.
fig-0.pdf:
pdflatex -enable-write18 -halt-on-error -interaction=batchmode -jobname "fig-0" "deftikzexternalrealjob{main}input{main}"
fig-0.pdf: fig-0.md5
Edit: tikz-externalize
does collect the information on whether a figure is up-to-date or not. This is obvious because after a full run, it can issue a warning if there are figures that are not up-to-date. Furthermore, if externalize is set to convert with system call
, only those figures are updated, that were outdated. So tikz has to have a way to invoke something like an md5 check.
So instead of creating a list of outdated figures, is there maybe a way to invoke this up-to-date-check using a manual pdflatex command? Naivly put, something like pdflatex -jobname=figure0 --check-md5
?
I am perfectly happy to start updating figures manually, but creating all figures everytime I change one is - to put it mildy - time consuming... There has to be a solution that is working on windows as well, I suppose?
I had a look into the tikz-externalize files, but my tex is not good enough for this...
Edit 2: I realize I did not make my problem clear enough, or maybe the motivation for my question.
My document includes several tikz pictures, many of those are very time consuming to create. I have tikzexternalize configured to consecutively number all figures in my document. Thus, I can manually invoke pdflatex -jobname=figure0 ...
, and somehow pdflatex finds the right tikz code, although the tikzfiles are not named figure0.tikz
and so on. I really can't do the manual md5 check unless I either find out where the externalize magic happens. This leaves me with the following choices:
- understand the magic (propably not going to happen anytime soon)
- find a way to invoke the tikze-md5check before typesetting
- find a way to get a list of outdated figures
windows tikz-external
|
show 10 more comments
I am using tikz' externalize library on windows. Since my document contains graphics with ref
, I need to use list and make
instead of convert with system call
.
Since I am working on windows, I cannot use make main.makefile
, as was also reported in this question.
Issuing the correct system calls is not a problem. However, I do not know how to find out which figures need to be updated since main.figlist
seems to always list all figures. externalize
obviously checks for whether a figure needs to be updated before issuing the system call, and I believe something like this is included in the makefile as well.
Unfortunately I do not know how makefiles work.
Is there a way to issue this check manually, or can I get a list of outdated figures?
The generated makefiles look as follows:
ALL_FIGURE_NAMES=$(shell cat thesis.figlist)
ALL_FIGURES=$(ALL_FIGURE_NAMES:%=%.pdf)
allimages: $(ALL_FIGURES)
@echo All images exist now. Use make -B to re-generate them.
FORCEREMAKE:
include $(ALL_FIGURE_NAMES:%=%.dep)
%.dep:
mkdir -p "$(dir $@)"
touch "$@" # will be filled later.
fig-0.pdf:
pdflatex -enable-write18 -halt-on-error -interaction=batchmode -jobname "fig-0" "deftikzexternalrealjob{main}input{main}"
fig-0.pdf: fig-0.md5
Edit: tikz-externalize
does collect the information on whether a figure is up-to-date or not. This is obvious because after a full run, it can issue a warning if there are figures that are not up-to-date. Furthermore, if externalize is set to convert with system call
, only those figures are updated, that were outdated. So tikz has to have a way to invoke something like an md5 check.
So instead of creating a list of outdated figures, is there maybe a way to invoke this up-to-date-check using a manual pdflatex command? Naivly put, something like pdflatex -jobname=figure0 --check-md5
?
I am perfectly happy to start updating figures manually, but creating all figures everytime I change one is - to put it mildy - time consuming... There has to be a solution that is working on windows as well, I suppose?
I had a look into the tikz-externalize files, but my tex is not good enough for this...
Edit 2: I realize I did not make my problem clear enough, or maybe the motivation for my question.
My document includes several tikz pictures, many of those are very time consuming to create. I have tikzexternalize configured to consecutively number all figures in my document. Thus, I can manually invoke pdflatex -jobname=figure0 ...
, and somehow pdflatex finds the right tikz code, although the tikzfiles are not named figure0.tikz
and so on. I really can't do the manual md5 check unless I either find out where the externalize magic happens. This leaves me with the following choices:
- understand the magic (propably not going to happen anytime soon)
- find a way to invoke the tikze-md5check before typesetting
- find a way to get a list of outdated figures
windows tikz-external
I don't know how it works on Windows, but everywhere elsemake
only makes things which need remaking. It doesn't matter that they are listed. Unless you force a remake,make
will check if they need remaking before doing so. Have you tried to see if it does the right thing?
– cfr
Jul 27 '16 at 2:55
Since I cannot run the makefile, I cannot test this. So, basically the up to date check is done by make?
– Dux
Jul 27 '16 at 6:49
Yes. That's howmake
works. You can force it to remake things which don't look as if they need to be remade, but to do that you have to override the default.
– cfr
Jul 27 '16 at 10:16
But tikz externalize seems to have a way to do this check as well. After a full run of pdflatex the library prints out whether all images are up to date or not. So this information should be somewhere...
– Dux
Jul 27 '16 at 14:43
Why can't you do whatmake
does and just look at the modification times for the files? If the.md5
is newer than the.pdf
, then the image needs remaking. Otherwise not.
– cfr
Jul 28 '16 at 18:10
|
show 10 more comments
I am using tikz' externalize library on windows. Since my document contains graphics with ref
, I need to use list and make
instead of convert with system call
.
Since I am working on windows, I cannot use make main.makefile
, as was also reported in this question.
Issuing the correct system calls is not a problem. However, I do not know how to find out which figures need to be updated since main.figlist
seems to always list all figures. externalize
obviously checks for whether a figure needs to be updated before issuing the system call, and I believe something like this is included in the makefile as well.
Unfortunately I do not know how makefiles work.
Is there a way to issue this check manually, or can I get a list of outdated figures?
The generated makefiles look as follows:
ALL_FIGURE_NAMES=$(shell cat thesis.figlist)
ALL_FIGURES=$(ALL_FIGURE_NAMES:%=%.pdf)
allimages: $(ALL_FIGURES)
@echo All images exist now. Use make -B to re-generate them.
FORCEREMAKE:
include $(ALL_FIGURE_NAMES:%=%.dep)
%.dep:
mkdir -p "$(dir $@)"
touch "$@" # will be filled later.
fig-0.pdf:
pdflatex -enable-write18 -halt-on-error -interaction=batchmode -jobname "fig-0" "deftikzexternalrealjob{main}input{main}"
fig-0.pdf: fig-0.md5
Edit: tikz-externalize
does collect the information on whether a figure is up-to-date or not. This is obvious because after a full run, it can issue a warning if there are figures that are not up-to-date. Furthermore, if externalize is set to convert with system call
, only those figures are updated, that were outdated. So tikz has to have a way to invoke something like an md5 check.
So instead of creating a list of outdated figures, is there maybe a way to invoke this up-to-date-check using a manual pdflatex command? Naivly put, something like pdflatex -jobname=figure0 --check-md5
?
I am perfectly happy to start updating figures manually, but creating all figures everytime I change one is - to put it mildy - time consuming... There has to be a solution that is working on windows as well, I suppose?
I had a look into the tikz-externalize files, but my tex is not good enough for this...
Edit 2: I realize I did not make my problem clear enough, or maybe the motivation for my question.
My document includes several tikz pictures, many of those are very time consuming to create. I have tikzexternalize configured to consecutively number all figures in my document. Thus, I can manually invoke pdflatex -jobname=figure0 ...
, and somehow pdflatex finds the right tikz code, although the tikzfiles are not named figure0.tikz
and so on. I really can't do the manual md5 check unless I either find out where the externalize magic happens. This leaves me with the following choices:
- understand the magic (propably not going to happen anytime soon)
- find a way to invoke the tikze-md5check before typesetting
- find a way to get a list of outdated figures
windows tikz-external
I am using tikz' externalize library on windows. Since my document contains graphics with ref
, I need to use list and make
instead of convert with system call
.
Since I am working on windows, I cannot use make main.makefile
, as was also reported in this question.
Issuing the correct system calls is not a problem. However, I do not know how to find out which figures need to be updated since main.figlist
seems to always list all figures. externalize
obviously checks for whether a figure needs to be updated before issuing the system call, and I believe something like this is included in the makefile as well.
Unfortunately I do not know how makefiles work.
Is there a way to issue this check manually, or can I get a list of outdated figures?
The generated makefiles look as follows:
ALL_FIGURE_NAMES=$(shell cat thesis.figlist)
ALL_FIGURES=$(ALL_FIGURE_NAMES:%=%.pdf)
allimages: $(ALL_FIGURES)
@echo All images exist now. Use make -B to re-generate them.
FORCEREMAKE:
include $(ALL_FIGURE_NAMES:%=%.dep)
%.dep:
mkdir -p "$(dir $@)"
touch "$@" # will be filled later.
fig-0.pdf:
pdflatex -enable-write18 -halt-on-error -interaction=batchmode -jobname "fig-0" "deftikzexternalrealjob{main}input{main}"
fig-0.pdf: fig-0.md5
Edit: tikz-externalize
does collect the information on whether a figure is up-to-date or not. This is obvious because after a full run, it can issue a warning if there are figures that are not up-to-date. Furthermore, if externalize is set to convert with system call
, only those figures are updated, that were outdated. So tikz has to have a way to invoke something like an md5 check.
So instead of creating a list of outdated figures, is there maybe a way to invoke this up-to-date-check using a manual pdflatex command? Naivly put, something like pdflatex -jobname=figure0 --check-md5
?
I am perfectly happy to start updating figures manually, but creating all figures everytime I change one is - to put it mildy - time consuming... There has to be a solution that is working on windows as well, I suppose?
I had a look into the tikz-externalize files, but my tex is not good enough for this...
Edit 2: I realize I did not make my problem clear enough, or maybe the motivation for my question.
My document includes several tikz pictures, many of those are very time consuming to create. I have tikzexternalize configured to consecutively number all figures in my document. Thus, I can manually invoke pdflatex -jobname=figure0 ...
, and somehow pdflatex finds the right tikz code, although the tikzfiles are not named figure0.tikz
and so on. I really can't do the manual md5 check unless I either find out where the externalize magic happens. This leaves me with the following choices:
- understand the magic (propably not going to happen anytime soon)
- find a way to invoke the tikze-md5check before typesetting
- find a way to get a list of outdated figures
windows tikz-external
windows tikz-external
edited Apr 13 '17 at 12:36
Community♦
1
1
asked Jul 22 '16 at 17:52
DuxDux
685421
685421
I don't know how it works on Windows, but everywhere elsemake
only makes things which need remaking. It doesn't matter that they are listed. Unless you force a remake,make
will check if they need remaking before doing so. Have you tried to see if it does the right thing?
– cfr
Jul 27 '16 at 2:55
Since I cannot run the makefile, I cannot test this. So, basically the up to date check is done by make?
– Dux
Jul 27 '16 at 6:49
Yes. That's howmake
works. You can force it to remake things which don't look as if they need to be remade, but to do that you have to override the default.
– cfr
Jul 27 '16 at 10:16
But tikz externalize seems to have a way to do this check as well. After a full run of pdflatex the library prints out whether all images are up to date or not. So this information should be somewhere...
– Dux
Jul 27 '16 at 14:43
Why can't you do whatmake
does and just look at the modification times for the files? If the.md5
is newer than the.pdf
, then the image needs remaking. Otherwise not.
– cfr
Jul 28 '16 at 18:10
|
show 10 more comments
I don't know how it works on Windows, but everywhere elsemake
only makes things which need remaking. It doesn't matter that they are listed. Unless you force a remake,make
will check if they need remaking before doing so. Have you tried to see if it does the right thing?
– cfr
Jul 27 '16 at 2:55
Since I cannot run the makefile, I cannot test this. So, basically the up to date check is done by make?
– Dux
Jul 27 '16 at 6:49
Yes. That's howmake
works. You can force it to remake things which don't look as if they need to be remade, but to do that you have to override the default.
– cfr
Jul 27 '16 at 10:16
But tikz externalize seems to have a way to do this check as well. After a full run of pdflatex the library prints out whether all images are up to date or not. So this information should be somewhere...
– Dux
Jul 27 '16 at 14:43
Why can't you do whatmake
does and just look at the modification times for the files? If the.md5
is newer than the.pdf
, then the image needs remaking. Otherwise not.
– cfr
Jul 28 '16 at 18:10
I don't know how it works on Windows, but everywhere else
make
only makes things which need remaking. It doesn't matter that they are listed. Unless you force a remake, make
will check if they need remaking before doing so. Have you tried to see if it does the right thing?– cfr
Jul 27 '16 at 2:55
I don't know how it works on Windows, but everywhere else
make
only makes things which need remaking. It doesn't matter that they are listed. Unless you force a remake, make
will check if they need remaking before doing so. Have you tried to see if it does the right thing?– cfr
Jul 27 '16 at 2:55
Since I cannot run the makefile, I cannot test this. So, basically the up to date check is done by make?
– Dux
Jul 27 '16 at 6:49
Since I cannot run the makefile, I cannot test this. So, basically the up to date check is done by make?
– Dux
Jul 27 '16 at 6:49
Yes. That's how
make
works. You can force it to remake things which don't look as if they need to be remade, but to do that you have to override the default.– cfr
Jul 27 '16 at 10:16
Yes. That's how
make
works. You can force it to remake things which don't look as if they need to be remade, but to do that you have to override the default.– cfr
Jul 27 '16 at 10:16
But tikz externalize seems to have a way to do this check as well. After a full run of pdflatex the library prints out whether all images are up to date or not. So this information should be somewhere...
– Dux
Jul 27 '16 at 14:43
But tikz externalize seems to have a way to do this check as well. After a full run of pdflatex the library prints out whether all images are up to date or not. So this information should be somewhere...
– Dux
Jul 27 '16 at 14:43
Why can't you do what
make
does and just look at the modification times for the files? If the .md5
is newer than the .pdf
, then the image needs remaking. Otherwise not.– cfr
Jul 28 '16 at 18:10
Why can't you do what
make
does and just look at the modification times for the files? If the .md5
is newer than the .pdf
, then the image needs remaking. Otherwise not.– cfr
Jul 28 '16 at 18:10
|
show 10 more comments
2 Answers
2
active
oldest
votes
This here may address the problem at hand, although I might have missed some point.
First, your basic assumption that you "need to use list and make
instead of convert with system call
" is outdated:
Some decent version (*) of the external
lib comes with support for ref
inside of pictures relying on the default convert with system call
. The solution is based on a detection that the image contains an undefined reference. It then writes some special marker into the image's .dpth
file. Later-on, this marker is read and the image will be reconverted during end{document}
, assuming that the reference is available then.
Thus, one solution to the problem "I need to handle ref
inside of my external images" might be to update to a decent version of the external
lib and use convert with system call
. Such a decent version is probably shipped with pgfplots
, i.e.
usepackage{pgfplots}
usepgfplotslibrary{external}
tikzexternalize
might do the trick.
(*) At the time of this writing, the "decent version" needs to be defined properly:
- the
external
library as it is shipped and documented in the current stable PGF 3.0.1a does not contain the mentioned feature. - a copy of the
external
library is shipped withpgfplots
. This one is always at least as recent as the version shipped with PGF. At the time of this writing, it is more recent and comes with the mentioned feature. If you writeusepgfplotslibrary{external}
, the code checks if the version available as part of PGF happens to be more recent. If so, the version of PGF will be used. If not, the copy shipped withpgfplots
will be used. Eventually, both will be in sync, but PGF's release cycle is way longer. That means that you are always better off withusepgfplotslibrary{external}
(at the cost of loadingpgfplots
).
That said, if you want to know which figures need to be remade due to a changed MD5, you can check if the file fig-0.pdf
is older than the file fig-0.md5
.
Note that the line
fig-0.pdf: fig-0.md5
in the Makefile does the same trick. And running LaTeX on the main file will update the .md5
file if and only if the MD5 has changed.
tex.stackexchange.com/questions/320584/…, tex.stackexchange.com/questions/320584/…. The first part of your answer is interesting. Has the manual not been updated? Or are you suggesting the OP use a development version of TikZ not yet on CTAN? Page 609 of the manually clearly says this won't work withconvert with system call
. ...
– cfr
Jul 28 '16 at 19:42
@cfr, same here,ref
in a tikz image does not work with a recent updated MikTex 2.9
– Dux
Jul 28 '16 at 21:10
@Christian Feuersänger, I will try your approach. I am not that good with windows command line scripts, or PowerShell for what its worth, so I will probably take some time until I have a script ready that compares time stamps. Stay tuned.
– Dux
Jul 28 '16 at 21:11
1
Just to make things clear: The external library in pgfplots and tikz are in sync. The only reason why pgfplots comes with a copy is that pgfplots has a release cycle of about 6-7 months whereas tikz has a release cycle of 2 years. That means: the next version of tikz will have the very same version.
– Christian Feuersänger
Jul 30 '16 at 6:14
1
@Dux you are right, an alternative forlist and make
under windows would be great. Since I am author and maintainer of theexternal
lib, I accept this as feature request.
– Christian Feuersänger
Jul 30 '16 at 6:17
|
show 7 more comments
I've had several years of success using Windows 7 (and more recently using Windows 10) with tikz externalization
under mode = list-and-make
.
I cannot comment (not enough points), hence this answer instead, in hopes of resolving what may be some misconceptions such as
Since I am working on windows, I cannot use make main.makefile, as was also reported in this question,
where the linked question was closed based on the author's thought that
It seems that only I have the problem.
(I think I, too, experienced the same or similar problem).
The culprit appeared to me to be differences in the behavior of the cat
command between linux and what was available in my case by default on Windows: one variant put a space between concatenations, the other produced a newline (I can't remember which did what). I installed RTools
(with RTools
ahead of related components on the Windows system path) so that the cat
command on Windows changed to behaving as the linux version (I had issues I didn't understand with cygwin
), and problems related to main.makefile
and main.figlist
(mentioned in the closed linked question) resolved, and everything worked. (I've been using externalization
with mode = list-and-make
on Windows for documents of classes beamer
, article
and tufte-handout
, with the only hickup being that I cannot get the tufte
class to work with lualatex
as the externalization
engine (have to stick with pdflatex
), which is a different issue).
Welcome to TeX.SE! If you think you have the same problem it would be better to add an comment (after you got more reputation) to that question and ask for reopen it ...
– Kurt
Feb 16 at 19:06
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
});
}
});
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%2f320584%2ftikzexternalize-list-and-make-list-of-figures-to-be-updated%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
This here may address the problem at hand, although I might have missed some point.
First, your basic assumption that you "need to use list and make
instead of convert with system call
" is outdated:
Some decent version (*) of the external
lib comes with support for ref
inside of pictures relying on the default convert with system call
. The solution is based on a detection that the image contains an undefined reference. It then writes some special marker into the image's .dpth
file. Later-on, this marker is read and the image will be reconverted during end{document}
, assuming that the reference is available then.
Thus, one solution to the problem "I need to handle ref
inside of my external images" might be to update to a decent version of the external
lib and use convert with system call
. Such a decent version is probably shipped with pgfplots
, i.e.
usepackage{pgfplots}
usepgfplotslibrary{external}
tikzexternalize
might do the trick.
(*) At the time of this writing, the "decent version" needs to be defined properly:
- the
external
library as it is shipped and documented in the current stable PGF 3.0.1a does not contain the mentioned feature. - a copy of the
external
library is shipped withpgfplots
. This one is always at least as recent as the version shipped with PGF. At the time of this writing, it is more recent and comes with the mentioned feature. If you writeusepgfplotslibrary{external}
, the code checks if the version available as part of PGF happens to be more recent. If so, the version of PGF will be used. If not, the copy shipped withpgfplots
will be used. Eventually, both will be in sync, but PGF's release cycle is way longer. That means that you are always better off withusepgfplotslibrary{external}
(at the cost of loadingpgfplots
).
That said, if you want to know which figures need to be remade due to a changed MD5, you can check if the file fig-0.pdf
is older than the file fig-0.md5
.
Note that the line
fig-0.pdf: fig-0.md5
in the Makefile does the same trick. And running LaTeX on the main file will update the .md5
file if and only if the MD5 has changed.
tex.stackexchange.com/questions/320584/…, tex.stackexchange.com/questions/320584/…. The first part of your answer is interesting. Has the manual not been updated? Or are you suggesting the OP use a development version of TikZ not yet on CTAN? Page 609 of the manually clearly says this won't work withconvert with system call
. ...
– cfr
Jul 28 '16 at 19:42
@cfr, same here,ref
in a tikz image does not work with a recent updated MikTex 2.9
– Dux
Jul 28 '16 at 21:10
@Christian Feuersänger, I will try your approach. I am not that good with windows command line scripts, or PowerShell for what its worth, so I will probably take some time until I have a script ready that compares time stamps. Stay tuned.
– Dux
Jul 28 '16 at 21:11
1
Just to make things clear: The external library in pgfplots and tikz are in sync. The only reason why pgfplots comes with a copy is that pgfplots has a release cycle of about 6-7 months whereas tikz has a release cycle of 2 years. That means: the next version of tikz will have the very same version.
– Christian Feuersänger
Jul 30 '16 at 6:14
1
@Dux you are right, an alternative forlist and make
under windows would be great. Since I am author and maintainer of theexternal
lib, I accept this as feature request.
– Christian Feuersänger
Jul 30 '16 at 6:17
|
show 7 more comments
This here may address the problem at hand, although I might have missed some point.
First, your basic assumption that you "need to use list and make
instead of convert with system call
" is outdated:
Some decent version (*) of the external
lib comes with support for ref
inside of pictures relying on the default convert with system call
. The solution is based on a detection that the image contains an undefined reference. It then writes some special marker into the image's .dpth
file. Later-on, this marker is read and the image will be reconverted during end{document}
, assuming that the reference is available then.
Thus, one solution to the problem "I need to handle ref
inside of my external images" might be to update to a decent version of the external
lib and use convert with system call
. Such a decent version is probably shipped with pgfplots
, i.e.
usepackage{pgfplots}
usepgfplotslibrary{external}
tikzexternalize
might do the trick.
(*) At the time of this writing, the "decent version" needs to be defined properly:
- the
external
library as it is shipped and documented in the current stable PGF 3.0.1a does not contain the mentioned feature. - a copy of the
external
library is shipped withpgfplots
. This one is always at least as recent as the version shipped with PGF. At the time of this writing, it is more recent and comes with the mentioned feature. If you writeusepgfplotslibrary{external}
, the code checks if the version available as part of PGF happens to be more recent. If so, the version of PGF will be used. If not, the copy shipped withpgfplots
will be used. Eventually, both will be in sync, but PGF's release cycle is way longer. That means that you are always better off withusepgfplotslibrary{external}
(at the cost of loadingpgfplots
).
That said, if you want to know which figures need to be remade due to a changed MD5, you can check if the file fig-0.pdf
is older than the file fig-0.md5
.
Note that the line
fig-0.pdf: fig-0.md5
in the Makefile does the same trick. And running LaTeX on the main file will update the .md5
file if and only if the MD5 has changed.
tex.stackexchange.com/questions/320584/…, tex.stackexchange.com/questions/320584/…. The first part of your answer is interesting. Has the manual not been updated? Or are you suggesting the OP use a development version of TikZ not yet on CTAN? Page 609 of the manually clearly says this won't work withconvert with system call
. ...
– cfr
Jul 28 '16 at 19:42
@cfr, same here,ref
in a tikz image does not work with a recent updated MikTex 2.9
– Dux
Jul 28 '16 at 21:10
@Christian Feuersänger, I will try your approach. I am not that good with windows command line scripts, or PowerShell for what its worth, so I will probably take some time until I have a script ready that compares time stamps. Stay tuned.
– Dux
Jul 28 '16 at 21:11
1
Just to make things clear: The external library in pgfplots and tikz are in sync. The only reason why pgfplots comes with a copy is that pgfplots has a release cycle of about 6-7 months whereas tikz has a release cycle of 2 years. That means: the next version of tikz will have the very same version.
– Christian Feuersänger
Jul 30 '16 at 6:14
1
@Dux you are right, an alternative forlist and make
under windows would be great. Since I am author and maintainer of theexternal
lib, I accept this as feature request.
– Christian Feuersänger
Jul 30 '16 at 6:17
|
show 7 more comments
This here may address the problem at hand, although I might have missed some point.
First, your basic assumption that you "need to use list and make
instead of convert with system call
" is outdated:
Some decent version (*) of the external
lib comes with support for ref
inside of pictures relying on the default convert with system call
. The solution is based on a detection that the image contains an undefined reference. It then writes some special marker into the image's .dpth
file. Later-on, this marker is read and the image will be reconverted during end{document}
, assuming that the reference is available then.
Thus, one solution to the problem "I need to handle ref
inside of my external images" might be to update to a decent version of the external
lib and use convert with system call
. Such a decent version is probably shipped with pgfplots
, i.e.
usepackage{pgfplots}
usepgfplotslibrary{external}
tikzexternalize
might do the trick.
(*) At the time of this writing, the "decent version" needs to be defined properly:
- the
external
library as it is shipped and documented in the current stable PGF 3.0.1a does not contain the mentioned feature. - a copy of the
external
library is shipped withpgfplots
. This one is always at least as recent as the version shipped with PGF. At the time of this writing, it is more recent and comes with the mentioned feature. If you writeusepgfplotslibrary{external}
, the code checks if the version available as part of PGF happens to be more recent. If so, the version of PGF will be used. If not, the copy shipped withpgfplots
will be used. Eventually, both will be in sync, but PGF's release cycle is way longer. That means that you are always better off withusepgfplotslibrary{external}
(at the cost of loadingpgfplots
).
That said, if you want to know which figures need to be remade due to a changed MD5, you can check if the file fig-0.pdf
is older than the file fig-0.md5
.
Note that the line
fig-0.pdf: fig-0.md5
in the Makefile does the same trick. And running LaTeX on the main file will update the .md5
file if and only if the MD5 has changed.
This here may address the problem at hand, although I might have missed some point.
First, your basic assumption that you "need to use list and make
instead of convert with system call
" is outdated:
Some decent version (*) of the external
lib comes with support for ref
inside of pictures relying on the default convert with system call
. The solution is based on a detection that the image contains an undefined reference. It then writes some special marker into the image's .dpth
file. Later-on, this marker is read and the image will be reconverted during end{document}
, assuming that the reference is available then.
Thus, one solution to the problem "I need to handle ref
inside of my external images" might be to update to a decent version of the external
lib and use convert with system call
. Such a decent version is probably shipped with pgfplots
, i.e.
usepackage{pgfplots}
usepgfplotslibrary{external}
tikzexternalize
might do the trick.
(*) At the time of this writing, the "decent version" needs to be defined properly:
- the
external
library as it is shipped and documented in the current stable PGF 3.0.1a does not contain the mentioned feature. - a copy of the
external
library is shipped withpgfplots
. This one is always at least as recent as the version shipped with PGF. At the time of this writing, it is more recent and comes with the mentioned feature. If you writeusepgfplotslibrary{external}
, the code checks if the version available as part of PGF happens to be more recent. If so, the version of PGF will be used. If not, the copy shipped withpgfplots
will be used. Eventually, both will be in sync, but PGF's release cycle is way longer. That means that you are always better off withusepgfplotslibrary{external}
(at the cost of loadingpgfplots
).
That said, if you want to know which figures need to be remade due to a changed MD5, you can check if the file fig-0.pdf
is older than the file fig-0.md5
.
Note that the line
fig-0.pdf: fig-0.md5
in the Makefile does the same trick. And running LaTeX on the main file will update the .md5
file if and only if the MD5 has changed.
edited Jul 30 '16 at 15:23
answered Jul 28 '16 at 18:54
Christian FeuersängerChristian Feuersänger
49k4116174
49k4116174
tex.stackexchange.com/questions/320584/…, tex.stackexchange.com/questions/320584/…. The first part of your answer is interesting. Has the manual not been updated? Or are you suggesting the OP use a development version of TikZ not yet on CTAN? Page 609 of the manually clearly says this won't work withconvert with system call
. ...
– cfr
Jul 28 '16 at 19:42
@cfr, same here,ref
in a tikz image does not work with a recent updated MikTex 2.9
– Dux
Jul 28 '16 at 21:10
@Christian Feuersänger, I will try your approach. I am not that good with windows command line scripts, or PowerShell for what its worth, so I will probably take some time until I have a script ready that compares time stamps. Stay tuned.
– Dux
Jul 28 '16 at 21:11
1
Just to make things clear: The external library in pgfplots and tikz are in sync. The only reason why pgfplots comes with a copy is that pgfplots has a release cycle of about 6-7 months whereas tikz has a release cycle of 2 years. That means: the next version of tikz will have the very same version.
– Christian Feuersänger
Jul 30 '16 at 6:14
1
@Dux you are right, an alternative forlist and make
under windows would be great. Since I am author and maintainer of theexternal
lib, I accept this as feature request.
– Christian Feuersänger
Jul 30 '16 at 6:17
|
show 7 more comments
tex.stackexchange.com/questions/320584/…, tex.stackexchange.com/questions/320584/…. The first part of your answer is interesting. Has the manual not been updated? Or are you suggesting the OP use a development version of TikZ not yet on CTAN? Page 609 of the manually clearly says this won't work withconvert with system call
. ...
– cfr
Jul 28 '16 at 19:42
@cfr, same here,ref
in a tikz image does not work with a recent updated MikTex 2.9
– Dux
Jul 28 '16 at 21:10
@Christian Feuersänger, I will try your approach. I am not that good with windows command line scripts, or PowerShell for what its worth, so I will probably take some time until I have a script ready that compares time stamps. Stay tuned.
– Dux
Jul 28 '16 at 21:11
1
Just to make things clear: The external library in pgfplots and tikz are in sync. The only reason why pgfplots comes with a copy is that pgfplots has a release cycle of about 6-7 months whereas tikz has a release cycle of 2 years. That means: the next version of tikz will have the very same version.
– Christian Feuersänger
Jul 30 '16 at 6:14
1
@Dux you are right, an alternative forlist and make
under windows would be great. Since I am author and maintainer of theexternal
lib, I accept this as feature request.
– Christian Feuersänger
Jul 30 '16 at 6:17
tex.stackexchange.com/questions/320584/…, tex.stackexchange.com/questions/320584/…. The first part of your answer is interesting. Has the manual not been updated? Or are you suggesting the OP use a development version of TikZ not yet on CTAN? Page 609 of the manually clearly says this won't work with
convert with system call
. ...– cfr
Jul 28 '16 at 19:42
tex.stackexchange.com/questions/320584/…, tex.stackexchange.com/questions/320584/…. The first part of your answer is interesting. Has the manual not been updated? Or are you suggesting the OP use a development version of TikZ not yet on CTAN? Page 609 of the manually clearly says this won't work with
convert with system call
. ...– cfr
Jul 28 '16 at 19:42
@cfr, same here,
ref
in a tikz image does not work with a recent updated MikTex 2.9– Dux
Jul 28 '16 at 21:10
@cfr, same here,
ref
in a tikz image does not work with a recent updated MikTex 2.9– Dux
Jul 28 '16 at 21:10
@Christian Feuersänger, I will try your approach. I am not that good with windows command line scripts, or PowerShell for what its worth, so I will probably take some time until I have a script ready that compares time stamps. Stay tuned.
– Dux
Jul 28 '16 at 21:11
@Christian Feuersänger, I will try your approach. I am not that good with windows command line scripts, or PowerShell for what its worth, so I will probably take some time until I have a script ready that compares time stamps. Stay tuned.
– Dux
Jul 28 '16 at 21:11
1
1
Just to make things clear: The external library in pgfplots and tikz are in sync. The only reason why pgfplots comes with a copy is that pgfplots has a release cycle of about 6-7 months whereas tikz has a release cycle of 2 years. That means: the next version of tikz will have the very same version.
– Christian Feuersänger
Jul 30 '16 at 6:14
Just to make things clear: The external library in pgfplots and tikz are in sync. The only reason why pgfplots comes with a copy is that pgfplots has a release cycle of about 6-7 months whereas tikz has a release cycle of 2 years. That means: the next version of tikz will have the very same version.
– Christian Feuersänger
Jul 30 '16 at 6:14
1
1
@Dux you are right, an alternative for
list and make
under windows would be great. Since I am author and maintainer of the external
lib, I accept this as feature request.– Christian Feuersänger
Jul 30 '16 at 6:17
@Dux you are right, an alternative for
list and make
under windows would be great. Since I am author and maintainer of the external
lib, I accept this as feature request.– Christian Feuersänger
Jul 30 '16 at 6:17
|
show 7 more comments
I've had several years of success using Windows 7 (and more recently using Windows 10) with tikz externalization
under mode = list-and-make
.
I cannot comment (not enough points), hence this answer instead, in hopes of resolving what may be some misconceptions such as
Since I am working on windows, I cannot use make main.makefile, as was also reported in this question,
where the linked question was closed based on the author's thought that
It seems that only I have the problem.
(I think I, too, experienced the same or similar problem).
The culprit appeared to me to be differences in the behavior of the cat
command between linux and what was available in my case by default on Windows: one variant put a space between concatenations, the other produced a newline (I can't remember which did what). I installed RTools
(with RTools
ahead of related components on the Windows system path) so that the cat
command on Windows changed to behaving as the linux version (I had issues I didn't understand with cygwin
), and problems related to main.makefile
and main.figlist
(mentioned in the closed linked question) resolved, and everything worked. (I've been using externalization
with mode = list-and-make
on Windows for documents of classes beamer
, article
and tufte-handout
, with the only hickup being that I cannot get the tufte
class to work with lualatex
as the externalization
engine (have to stick with pdflatex
), which is a different issue).
Welcome to TeX.SE! If you think you have the same problem it would be better to add an comment (after you got more reputation) to that question and ask for reopen it ...
– Kurt
Feb 16 at 19:06
add a comment |
I've had several years of success using Windows 7 (and more recently using Windows 10) with tikz externalization
under mode = list-and-make
.
I cannot comment (not enough points), hence this answer instead, in hopes of resolving what may be some misconceptions such as
Since I am working on windows, I cannot use make main.makefile, as was also reported in this question,
where the linked question was closed based on the author's thought that
It seems that only I have the problem.
(I think I, too, experienced the same or similar problem).
The culprit appeared to me to be differences in the behavior of the cat
command between linux and what was available in my case by default on Windows: one variant put a space between concatenations, the other produced a newline (I can't remember which did what). I installed RTools
(with RTools
ahead of related components on the Windows system path) so that the cat
command on Windows changed to behaving as the linux version (I had issues I didn't understand with cygwin
), and problems related to main.makefile
and main.figlist
(mentioned in the closed linked question) resolved, and everything worked. (I've been using externalization
with mode = list-and-make
on Windows for documents of classes beamer
, article
and tufte-handout
, with the only hickup being that I cannot get the tufte
class to work with lualatex
as the externalization
engine (have to stick with pdflatex
), which is a different issue).
Welcome to TeX.SE! If you think you have the same problem it would be better to add an comment (after you got more reputation) to that question and ask for reopen it ...
– Kurt
Feb 16 at 19:06
add a comment |
I've had several years of success using Windows 7 (and more recently using Windows 10) with tikz externalization
under mode = list-and-make
.
I cannot comment (not enough points), hence this answer instead, in hopes of resolving what may be some misconceptions such as
Since I am working on windows, I cannot use make main.makefile, as was also reported in this question,
where the linked question was closed based on the author's thought that
It seems that only I have the problem.
(I think I, too, experienced the same or similar problem).
The culprit appeared to me to be differences in the behavior of the cat
command between linux and what was available in my case by default on Windows: one variant put a space between concatenations, the other produced a newline (I can't remember which did what). I installed RTools
(with RTools
ahead of related components on the Windows system path) so that the cat
command on Windows changed to behaving as the linux version (I had issues I didn't understand with cygwin
), and problems related to main.makefile
and main.figlist
(mentioned in the closed linked question) resolved, and everything worked. (I've been using externalization
with mode = list-and-make
on Windows for documents of classes beamer
, article
and tufte-handout
, with the only hickup being that I cannot get the tufte
class to work with lualatex
as the externalization
engine (have to stick with pdflatex
), which is a different issue).
I've had several years of success using Windows 7 (and more recently using Windows 10) with tikz externalization
under mode = list-and-make
.
I cannot comment (not enough points), hence this answer instead, in hopes of resolving what may be some misconceptions such as
Since I am working on windows, I cannot use make main.makefile, as was also reported in this question,
where the linked question was closed based on the author's thought that
It seems that only I have the problem.
(I think I, too, experienced the same or similar problem).
The culprit appeared to me to be differences in the behavior of the cat
command between linux and what was available in my case by default on Windows: one variant put a space between concatenations, the other produced a newline (I can't remember which did what). I installed RTools
(with RTools
ahead of related components on the Windows system path) so that the cat
command on Windows changed to behaving as the linux version (I had issues I didn't understand with cygwin
), and problems related to main.makefile
and main.figlist
(mentioned in the closed linked question) resolved, and everything worked. (I've been using externalization
with mode = list-and-make
on Windows for documents of classes beamer
, article
and tufte-handout
, with the only hickup being that I cannot get the tufte
class to work with lualatex
as the externalization
engine (have to stick with pdflatex
), which is a different issue).
answered Feb 16 at 18:36
24thAlchemist24thAlchemist
134
134
Welcome to TeX.SE! If you think you have the same problem it would be better to add an comment (after you got more reputation) to that question and ask for reopen it ...
– Kurt
Feb 16 at 19:06
add a comment |
Welcome to TeX.SE! If you think you have the same problem it would be better to add an comment (after you got more reputation) to that question and ask for reopen it ...
– Kurt
Feb 16 at 19:06
Welcome to TeX.SE! If you think you have the same problem it would be better to add an comment (after you got more reputation) to that question and ask for reopen it ...
– Kurt
Feb 16 at 19:06
Welcome to TeX.SE! If you think you have the same problem it would be better to add an comment (after you got more reputation) to that question and ask for reopen it ...
– Kurt
Feb 16 at 19:06
add a comment |
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.
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%2f320584%2ftikzexternalize-list-and-make-list-of-figures-to-be-updated%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
I don't know how it works on Windows, but everywhere else
make
only makes things which need remaking. It doesn't matter that they are listed. Unless you force a remake,make
will check if they need remaking before doing so. Have you tried to see if it does the right thing?– cfr
Jul 27 '16 at 2:55
Since I cannot run the makefile, I cannot test this. So, basically the up to date check is done by make?
– Dux
Jul 27 '16 at 6:49
Yes. That's how
make
works. You can force it to remake things which don't look as if they need to be remade, but to do that you have to override the default.– cfr
Jul 27 '16 at 10:16
But tikz externalize seems to have a way to do this check as well. After a full run of pdflatex the library prints out whether all images are up to date or not. So this information should be somewhere...
– Dux
Jul 27 '16 at 14:43
Why can't you do what
make
does and just look at the modification times for the files? If the.md5
is newer than the.pdf
, then the image needs remaking. Otherwise not.– cfr
Jul 28 '16 at 18:10