tikzexternalize, list-and-make, list of figures to be updated












4















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










share|improve this question

























  • 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
















4















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










share|improve this question

























  • 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














4












4








4


1






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










share|improve this question
















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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 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



















  • 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

















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










2 Answers
2






active

oldest

votes


















2





+50









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:




  1. the external library as it is shipped and documented in the current stable PGF 3.0.1a does not contain the mentioned feature.

  2. a copy of the external library is shipped with pgfplots. 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 write usepgfplotslibrary{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 with pgfplots 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 with usepgfplotslibrary{external} (at the cost of loading pgfplots).




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.






share|improve this answer


























  • 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











  • @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 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



















0














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).






share|improve this answer
























  • 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











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%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









2





+50









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:




  1. the external library as it is shipped and documented in the current stable PGF 3.0.1a does not contain the mentioned feature.

  2. a copy of the external library is shipped with pgfplots. 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 write usepgfplotslibrary{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 with pgfplots 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 with usepgfplotslibrary{external} (at the cost of loading pgfplots).




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.






share|improve this answer


























  • 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











  • @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 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
















2





+50









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:




  1. the external library as it is shipped and documented in the current stable PGF 3.0.1a does not contain the mentioned feature.

  2. a copy of the external library is shipped with pgfplots. 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 write usepgfplotslibrary{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 with pgfplots 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 with usepgfplotslibrary{external} (at the cost of loading pgfplots).




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.






share|improve this answer


























  • 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











  • @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 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














2





+50







2





+50



2




+50





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:




  1. the external library as it is shipped and documented in the current stable PGF 3.0.1a does not contain the mentioned feature.

  2. a copy of the external library is shipped with pgfplots. 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 write usepgfplotslibrary{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 with pgfplots 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 with usepgfplotslibrary{external} (at the cost of loading pgfplots).




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.






share|improve this answer















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:




  1. the external library as it is shipped and documented in the current stable PGF 3.0.1a does not contain the mentioned feature.

  2. a copy of the external library is shipped with pgfplots. 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 write usepgfplotslibrary{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 with pgfplots 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 with usepgfplotslibrary{external} (at the cost of loading pgfplots).




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.







share|improve this answer














share|improve this answer



share|improve this answer








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 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











  • @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 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



















  • 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











  • @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 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

















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











0














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).






share|improve this answer
























  • 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
















0














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).






share|improve this answer
























  • 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














0












0








0







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).






share|improve this answer













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).







share|improve this answer












share|improve this answer



share|improve this answer










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



















  • 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


















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%2f320584%2ftikzexternalize-list-and-make-list-of-figures-to-be-updated%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Biblatex bibliography style without URLs when DOI exists (in Overleaf with Zotero bibliography)

ComboBox Display Member on multiple fields

Is it possible to collect Nectar points via Trainline?