missing/outdated figures for building strategies (2.2.0-rc6)

[GoogleCodeExporter]

First of all, thanks for the great effort for this project.
I use this a lot.

There are two issues in using eps figures with the pdflatex engine.

1/
For the first compilation, the Makefile would automatically convert eps to pdf, 
but it would complain, and the converted figures do not show in the resulted 
PDF.
I need to make again to resolve the problem.

$ make
= fig1.eps --> fig1.pdf =
= form.tex --> form.d form.pdf.1st.make (0-1) =
LaTeX Error: File `fig1' not found.
Success!  Wrote 2 pages, 248684 bytes to form.pdf

$ make
= form.tex --> form.d form.pdf.1st.make (0-1) =
Success!  Wrote 3 pages, 327992 bytes to form.pdf

2/
When I change the eps figures, 
I need to manually remove the previously generated pdf figures.
Otherwise, the new figures would not get detected and updated.

Is it possible to track these intermediate pdf figures?
So Makefile can detect the actual change to the source eps figures, 
and convert the figures when necessary.
Or at least, to remove them easily with the 'make clean' commands.

Original issue reported on code.google.com by payne.ch...@gmail.com on 25 Dec 2010 at 11:28

[GoogleCodeExporter]

Would you do me a favor and attach a minimal tarball of files that cause this 
failure?  I can try to reproduce on my end (and I will), but that will ensure 
that I am actually tackling the right problem when I work on this.

Now, to make sure that I understand how to reproduce this, is this the right 
sequence?

Create a blah.eps file that stands alone (not adjacent to a different source 
file that compiles to .eps)

Problem 1:
- Run make on the including source document
- Note that blah.pdf does not get included (but does get created?)
- Run make again
- Note that all is well

For the above problem, I suspect that the .d file is not getting generated 
correctly, and not triggering a rebuild of the .tex file after the graphics are 
created, then the error coloring code runs on the first log file and notes that 
there was a missing graphic (which it already knew in order to build it).  What 
it really should do is run pdflatex again.

Problem 2:
- Run make "blah.pdf"
- Run make clean
- Note that blah.pdf didn't go away.

I think this is due to .eps not being properly marked as a source file type.  
It's a tricky issue, so I'm not yet sure about that.

Original comment by shiblon on 26 Dec 2010 at 7:26

• Changed state: Accepted

[GoogleCodeExporter]

thanks for looking into this.
I attached an example tarball which would cause the issue.
I logged the commands in README.

And for the problem 2, I notice that, upon the first fresh make,
the .d file would contain the following entry for each of the eps figure.
"-include fig/test1.gpi.d"

However, after the first make, 
the new generated .d file would contain only ONE such entry for the last 
included eps figure.
And I think this is the reason why that the updated eps do not get re-converted.

Original comment by payne.ch...@gmail.com on 27 Dec 2010 at 3:15

Attachments:

• example.tar.gz

[GoogleCodeExporter]

Oh, you have figures in subdirectories?  That's not supported by the makefile, 
and never will be.  I suspect that if you were to move things into the same 
directory, it would start working (at least better than it is now).

Original comment by shiblon on 31 Dec 2010 at 7:43

[GoogleCodeExporter]

This might work better with the changes related to issue 100.  Can you take a 
look at the revision listed there and see if your problems are fixed?  I think 
the problems are related.

Original comment by shiblon on 1 Jan 2011 at 12:15

[GoogleCodeExporter]

The latest fix of issue100 doesn't seem to solve my problem.
But I agree that this one looks highly related to issue100, and maybe some more 
tweaks would be needed to capture the latex error.

And, the problem persists without putting figures in subdirectories.
I've just attached another tarball.

Original comment by payne.ch...@gmail.com on 1 Jan 2011 at 2:09

Attachments:

• example.tar.gz

[GoogleCodeExporter]

I have fixed the clean issue, and am now working on the build failure.  
rddbeeae3f23c

Original comment by shiblon on 4 Jan 2011 at 2:59

[GoogleCodeExporter]

And now, the failure to rebuild after creating test1.pdf and test2.pdf is 
fixed.  r07ee69208eac should do it.

That was a subtle one where the difference between pdflatex and latex messed up 
my previous latex-oriented logic.

For the failure to properly clean out .pdf files and .log files (you can remove 
your Makefile.ini, now), the problem was a lack of stated support for .eps 
source files.  You could have fixed that by gzipping them, but now it should 
work properly.

For the failure to call pdflatex after graphics were created, the problem was 
caused by a deep assumption made about latex's behavior when graphics files are 
missing.  When producing a .dvi file, latex will go ahead and do that even if 
it can't find any graphics that it needs.  pdflatex, however, will fail to 
produce a .pdf if there are missing graphics.  I wasn't handling the missing 
file properly and it broke my logic.  That should be fixed, now.

Both of your issues have now been addressed.  Feel free to either verify or 
reopen this bug if that is not the case.  I'm probably going to upload a new 
version, soon, but I've attached the new Makefile here for you to try out first.

Original comment by shiblon on 4 Jan 2011 at 3:38

• Changed state: Fixed

Attachments:

• Makefile

[GoogleCodeExporter]

Thanks! 
The fix works great for issue1.

I found that there is a remaining problem for issue2, 
caused by the file "get-graphics.sed".

There is a code segment like the following, 
to extract the graphic entries from the log.
------------------------------------
/.*File: \(.*\) Graphic file (type [^)]*).*/{
  s//\1/
  b addtargets
}
------------------------------------

The code works if there is only one file entry in each paragraph, 
but this is not mostly true.
In my previous attached example, there exist multiple entries in the same 
paragraph.
And thus the previous greedy regx would only match the last file: test3.pdf.
That means, changes to test1.eps or test2.eps would not trigger the rebuild.
------------------------------------
File: test1.pdf Graphic file (type pdf)
<use test1.pdf> <test2.pdf, id=2, 344.28625pt x 212.795pt>
File: test2.pdf Graphic file (type pdf)
<use test2.pdf> <test3.pdf, id=3, 344.28625pt x 212.795pt>
File: test3.pdf Graphic file (type pdf)
<use test3.pdf> <test4.pdf, id=4, 344.28625pt x 212.795pt>
------------------------------------

I fixed this by using loops to extract multiple entries within one paragraph,
and output one target per entry.
The updated file is attached here, but I am no doubt a sed newbie.
So you would know better how to address this.

Original comment by payne.ch...@gmail.com on 5 Jan 2011 at 12:47

Attachments:

• get-graphics.sed

[GoogleCodeExporter]

Oh, fascinating!  I'll work on this tomorrow (if I forget, please feel free to 
pester me - this is an important issue).

Original comment by shiblon on 5 Jan 2011 at 1:26

• Changed state: Started
• Added labels: Priority-Critical
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Would you do me a favor and send me the minimal .tex file that generates this 
log?  I'd like to add a regression test for this and am having a hard time 
reproducing it.

Original comment by shiblon on 5 Jan 2011 at 2:36

[GoogleCodeExporter]

By the way, that's a very nice sed patch.  Not bad for a self-proclaimed newbie 
:-)

You must be using GNU sed, though.  I see things like [^\n], which doesn't work 
in BSD sed.  There are other things in there, too, that don't work for BSD sed, 
so I'm going to have to hack at it a bit.  I'm sorry about that, and hope you 
don't mind the hack job it's about to get.

Original comment by shiblon on 5 Jan 2011 at 2:42

[GoogleCodeExporter]

Never mind about the minimal case.  I get it, now.  Boy, it's been a while.

So, here's what happens.  get-graphics detects graphics in two cases: missing 
graphics files and existing graphics files (since no matter when make runs, we 
need to know whether to rebuild because a file *changed*, not just because it 
isn't there anymore).

Thanks very much for the patch.  Now that I have a log file to work with, I 
should be able to easily reproduce this and get a fix that works properly.

Original comment by shiblon on 5 Jan 2011 at 2:51

[GoogleCodeExporter]

I found a very simple patch that will fix this.  Check it out.

Original comment by shiblon on 5 Jan 2011 at 3:59

Attachments:

• get-graphics.sed.diff

[GoogleCodeExporter]

I found an even simpler patch and commited r9eca3daadc0e .  Marking fixed.  
Feel free to reopen if it doesn't work for you.

This is the last big blocking issue that I know of for releasing a new rc 
download.  If you verify this, I'll upload a new rc.

Original comment by shiblon on 5 Jan 2011 at 4:08

• Changed state: Fixed

[GoogleCodeExporter]

Ah... really an elegant fix.
Thanks! it works like a charm finally.

Original comment by payne.ch...@gmail.com on 5 Jan 2011 at 9:46

[GoogleCodeExporter]

Original comment by shiblon on 6 Jan 2011 at 8:28

• Changed state: Verified