pdflatex makefile doesn't support grayscale

[GoogleCodeExporter]

Building thesis._gray_.pdf doesn't create any gray images for any of the 
figures.  It silently uses the color versions.

On Wed, Mar 10, 2010 at 04:00:14PM -0500, Chris Monson wrote:
> Grayscale output works for me, oddly enough.  Did you check the VERBOSE=1
> output of the makefile?  You should see the word "monochrome" fly by.

This is weird, and I don't know what it means:

If I have already built "thesis.pdf", making "thesis._gray_.pdf" ends up
building an exact copy of "thesis.pdf".  However, if I do a "make clean"
and then "make thesis._gray_.pdf", I get:

amcnabb@maggie:~/clone/docs/thesis% make thesis._gray_.pdf
NOTE: You may ignore warnings about the following files:

     thesis._gray_.d

Makefile:2029: thesis._gray_.d: No such file or directory
make: *** No rule to make target `thesis._gray_.d'.  Stop.
amcnabb@maggie:~/clone/docs/thesis%

I'm attaching the verbose output from when "thesis._gray_.pdf" builds
when "thesis.pdf" already exists.

Original issue reported on code.google.com by amcna...@gmail.com on 10 Mar 2010 at 9:32

Attachments:

• gray_verbose.txt

[GoogleCodeExporter]

It looks like in the process of allowing bare graphic filenames, we have lost 
the ability to 
properly generate ._gray_.tex with the filenames rewritten to ._gray_.  I'm 
working on it.

Original comment by shiblon on 11 Mar 2010 at 2:49

• Changed state: Started

[GoogleCodeExporter]

CRAP.  This is hard.

So, graphicx sees ._gray_ at the end of the filename and barfs because it 
doesn't know 
the extension.  If I add .pdf to the end of it to force the issue, then the 
dependency 
problem rears its ugly head again.  There is no way to win this one with 
pdflatex easily.

I can't change it to be something like __gray_ (instead of ._gray_) because 
then the %. 
matching rules don't work properly.  I am welcoming any suggestions at this 
point.

Original comment by shiblon on 11 Mar 2010 at 3:21

[GoogleCodeExporter]

OK - fixed.  Miraculously.

r32cccde058e3 has the fix.  Or you can pull from the tip.

Note that I had to change it from using ._gray_ to __gray_ (double underscore 
at the 
beginning).  This is configurable with the GRAY_INFIX variable.

Original comment by shiblon on 11 Mar 2010 at 3:43

• Changed state: Fixed

[GoogleCodeExporter]

I was able to make a grayscale figure by making "figure1__gray_.pdf".  However, 
I 
wasn't able to do the whole document:

amcnabb@prodigy:~/clone/docs/thesis% make thesis__gray_.pdf
NOTE: You may ignore warnings about the following files:

     thesis__gray_.d

Makefile:2051: thesis__gray_.d: No such file or directory
make: *** No rule to make target `thesis__gray_.d'.  Stop.
amcnabb@prodigy:~/clone/docs/thesis%

I tried to do a log with VERBOSE=1, but it didn't give any additional 
information.

And totally bikeshedding here, but the asymmetricity of the name is a little 
rough 
for me.  Would you consider having GRAY_INFIX default to __gray?  This would 
make it 
thesis__gray.pdf, which I think would be easier for me to remember.  If you 
hate the 
idea, I would probably rather use your default than to set my own GRAY_INFIX.

Original comment by amcna...@gmail.com on 11 Mar 2010 at 9:06

• Changed state: Started

[GoogleCodeExporter]

Ping me off list about this - maybe I can pull your thesis and try building it.

Original comment by shiblon on 11 Mar 2010 at 9:12

[GoogleCodeExporter]

It appears that building thesis__gray_.pdf works as long as I have already 
built 
thesis.pdf.  The problem only occurs if I build thesis__gray_.pdf in a clean 
directory.  I don't know the Makefile as well as I should, but it looks like 
the rule 
"thesis.d thesis.tex --> thesis__gray_.tex" can't occur in the __gray_ case 
because 
"thesis.d" doesn't exist.

Would it be possible to fix this by making making thesis__gray_.d depend on the 
rule 
that creates thesis.d?

Original comment by amcna...@gmail.com on 11 Mar 2010 at 11:52

[GoogleCodeExporter]

What's confusing is that it is working for me.  Did you pull from the tip?

The normal procedure is this:

file__gray.pdf is handled by this rule:
  %.$(build_target_extension): %.bbl %.aux

That searches all the way down the dependency path until it finds that it needs
file__gray.tex, which depends on file.d and file.tex

file.tex is already there, but file.d is not, so it runs pdflatex to generate 
it (look for a 
comment that says "Behavior:" and you'll find the right section)

So, file.d is generated.  Then the rule to generated file__gray.tex runs 
because its 
dependencies are now met.

Then the rest of the build process is exactly as though file__gray.tex had 
already 
existed on the system: dependencies are generated from it and stuff 
(supposedly) 
just builds.

I'm looking into this, but I'm very confused.  There must be a subtle bug 
somewhere.

file__gray.tex comes from file.d and file.tex
file.d isn't there, so it is built from file.tex by running pdflatex once

Original comment by shiblon on 12 Mar 2010 at 1:48

[GoogleCodeExporter]

I've definitely been on tip (but it never hurts to ask).

For some reason, it makes file.d when building file.pdf but not when building 
file__gray.pdf.  Maybe there's something subtle like it's trying to build 
file__gray.d before file.d or something like that (?).  If I manually do "make 
file.d", then a subsequent "make file__gray.pdf" succeeds.

Original comment by amcna...@gmail.com on 12 Mar 2010 at 4:44

[GoogleCodeExporter]

Hmm.  I noticed the following rule:

%.d %.aux %.aux.make %.fls: %.tex

This means that file__gray.d depends on file__gray.tex, as it should.  But 
somehow 
there's a circular dependency making file__gray.tex depend on file__gray.d, 
which 
it shouldn't.  The file__gray.tex file should depend on file.d but not 
file__gray.d, right?

I don't know.  Make confuses me, so maybe I have it all wrong. :)

Original comment by amcna...@gmail.com on 12 Mar 2010 at 4:57

[GoogleCodeExporter]

I don't know if this is related or not, but it seems really weird.  If I do 
"make 
file.tex", I would expect it to quit since file.tex already exists and is not a 
generated file.  However, it instead runs pdflatex and builds the graphics.  
Isn't 
that a little odd?

Original comment by amcna...@gmail.com on 12 Mar 2010 at 5:04

[GoogleCodeExporter]

OK - this is bizarre.  It generates the thesis__gray.d file on my system, same 
files, but 
not on yours.  Looking into it.  Weird, weird, weird.

Original comment by shiblon on 12 Mar 2010 at 5:22

[GoogleCodeExporter]

What I don't get is this: on my system, it has no trouble with the circular 
dependency 
(the nature of it is now obvious to me):

thesis__gray.tex: thesis.d thesis.tex
thesis.d: thesis.tex

BUT, and here's what it seems is happening: if you "include" the thesis__gray.d 
file, 
which we do automatically, it then tries to build thesis__gray.d, and we have 
this 
problem:

thesis__gray.d: thesis__gray.tex

But we're trying to build thesis__gray.tex in the first place.  Yuck.  I'm not 
sure how 
to solve this one.  It works on my system, darn it!

Original comment by shiblon on 12 Mar 2010 at 5:43

[GoogleCodeExporter]

So, just to be clear, grayscale still works, but you have to apply it globally, 
e.g.,

make GRAY=1 thesis.pdf

Then the output will be grayscale.  At this point, I think that's the *only* 
way I can 
sanely support it anymore.  The feature with the magic filenames was always 
very 
brittle, and now it's finally broken.  To that, I say "good riddance".

I'm going to rip it out and submit a revision with it gone.  The GRAY=1 will 
still work, 
though.

Original comment by shiblon on 12 Mar 2010 at 6:02

[GoogleCodeExporter]

r88004880caad rips the magic suffix out.  I'm going to mark this "fixed" (there 
is 
some irony, there, especially if you think of it in terms of pets).

The downside to GRAY=1 is, naturally, that you have to make clean before using 
it.  
That means that things are slower.  Sorry :(.

I imagine, but obviously could be wrong, that grayscale is really only needed 
near the 
end of a paper's build life.  Most edits can be made in the color version.

Or, you can always create a Makefile.ini and set GRAY=1 in there.  Then you'll 
always 
be working in grayscale.

Original comment by shiblon on 12 Mar 2010 at 6:12

• Changed state: Fixed

[GoogleCodeExporter]

Reopening this issue, since I think it is related to issue 70, and that may 
make this work 
properly again.  It's worth trying.

Original comment by shiblon on 16 Mar 2010 at 4:48

• Changed state: Accepted

[GoogleCodeExporter]

I patched magic suffix stuff back in to r3145f63058e3.  It's the current tip - 
please give 
it a try.

Original comment by shiblon on 16 Mar 2010 at 6:13

• Changed state: Started

[GoogleCodeExporter]

Unfortunately, I'm still getting the "No rule to make target `thesis__gray.d`" 
error.   
Thank you for trying to fix it, but it looks like it still just doesn't want to 
work.

Original comment by amcna...@gmail.com on 16 Mar 2010 at 7:08

[GoogleCodeExporter]

Weirdly, if you say "make thesis__gray.tex" first, everything works fine.

It seems like there should be a way to make this work.  I'm looking over the 
dependency 
resolution now.

Original comment by shiblon on 16 Mar 2010 at 7:26

[GoogleCodeExporter]

I've figured out what is causing this.  It's pretty tricky, unfortunately.

The problem can be boiled down thusly:

thesis__gray.d needs thesis__gray.tex  (rule: %.d: %.tex)
thesis__gray.tex needs thesis.d              (rule: %__gray.tex: %.d)
thesis.d needs thesis.tex                          (rule: %.d: %.tex -- oops - 
make thinks this is 
a repeat, which is wrong, but there you have it)

I can fix this by using static pattern matching, but now I'm getting different 
errors.  
I'll keep poking at it for a bit.

Original comment by shiblon on 16 Mar 2010 at 8:14

[GoogleCodeExporter]

I had noticed this, too, but I could never quite figure out why it thinks 
thesis.tex 
is a repeat.  It seems like it should be clear that thesis.tex and 
thesis__gray.tex 
are completely different files.  Crazy stuff.  I admire your patience. :)

Original comment by amcna...@gmail.com on 16 Mar 2010 at 8:35

[GoogleCodeExporter]

Giving up again - in order to fix this properly, many deep changes are 
required, and it's 
very subtle.  I almost had it, but it broke everything else :-/

For the foreseeable future, the way to go is 

make clean
make GRAY=1

Original comment by shiblon on 16 Mar 2010 at 10:34

• Changed state: Fixed