search

shiblon / latex-makefile

A Makefile for LaTeX - drop it in, type make, and magic happens.
Other
186 stars 30 forks source link

fig -> pdftex[_t] conversion #5

Open shtrom opened 9 years ago

shtrom commented 9 years ago

Hi,

I generally use Xfig files, which I convert to pdftex[_t] and include in my document as 

\input{figs/omsp.pdftex_t}

However, the Makefile doesn't appear to be aware of them at the moment. It is, however aware of pstex[_t] documents. I've tried duplicating this to support pdftex[_t] conversion (see [0]), but to no avail.

However, I haven't been able to exercise the pstex_t bit of code in my test either.

$ make BUILD_STRATEGY=latex
NOTE: You may ignore warnings about the following files:

     lw.d

../latex.mk:2561: lw.d: No such file or directory
NOTE: You may ignore warnings about the following files:

     lw.bib.d

= lw.tex --> lw.d lw.dvi.1st.make (0-1) =
= lw.aux --> lw.bib.d =
make: *** No rule to make target 'figs/omsp.pstex_t.tex', needed by 'lw.d'.  Stop.

Is this still a working feature? How should the pdftex_t support be implemented?

[0] https://github.com/shtrom/latex-makefile/compare/pdftex?diff=unified&expand=1

shiblon commented 9 years ago

Hey, I'm sorry to be so slow to answer these inquiries lately. Life has been upside down. I just looked at this, however, and I have a few comments that might clear things up a bit, especially as regards pstex_t files.

First of all, anything that generates latex code and includes that to make graphics is going to be a problem for the makefile. The way that graphic inclusion works traditionally is as follows:

When your graphics are actually tex code, the "run latex without stopping on errors" part completely and utterly fails when it encounters its first missing dependency. The reason for this is that it doesn't yet have all of its code! It doesn't and can't know that its dependency on that code is completely local to the include itself, so it doesn't know that it could easily parse the rest of the file without problems even though the graphics are not there.

So, pstex_t and friends are oddballs. The only way to really make things happy is to have a separate build step that searches for all of them and builds them independent of the rest of the document, then fails to notice if their sources (e.g., the xfig file) has changed.

In the case of xfig, the makefile will actually automatically build either eps or pdf from it for you, depending on what mode you're using. Is there a particular reason that you would rather generate pdftex from it instead of just producing a .pdf file and including it using graphicx? That is well-supported. :-)

On Wed Sep 24 2014 at 2:58:10 AM Olivier Mehani notifications@github.com wrote:

Hi,

I generally use Xfig files, which I convert to pdftex[_t] and include in my document as

\input{figs/omsp.pdftex_t}

However, the Makefile doesn't appear to be aware of them at the moment. It is, however aware of pstex[_t] documents. I've tried duplicating this to support pdftex[_t] conversion (see [0]), but to no avail.

However, I haven't been able to exercise the pstex_t bit of code in my test either.

$ make BUILD_STRATEGY=latex NOTE: You may ignore warnings about the following files:

 lw.d

../latex.mk:2561: lw.d: No such file or directory NOTE: You may ignore warnings about the following files:

 lw.bib.d

= lw.tex --> lw.d lw.dvi.1st.make (0-1) = = lw.aux --> lw.bib.d = make: *\ No rule to make target 'figs/omsp.pstex_t.tex', needed by 'lw.d'. Stop.

Is this still a working feature? How should the pdftex_t support be implemented?

[0] https://github.com/shtrom/latex-makefile/compare/pdftex?diff=unified&expand=1

— Reply to this email directly or view it on GitHub https://github.com/shiblon/latex-makefile/issues/5.

shtrom commented 9 years ago

When your graphics are actually tex code, the "run latex without stopping on errors" part completely and utterly fails when it encounters its first missing dependency.

Ah, right, this make sense.

So, pstex_t and friends are oddballs. The only way to really make things happy is to have a separate build step that searches for all of them and builds them independent of the rest of the document, then fails to notice if their sources (e.g., the xfig file) has changed.

Well, what I had in my hand-made Makefiles was that I parsed the tex file for any \input, and add it to the list of deps for that file (and cascading dependencies upwards to files that included that file). This forces me to be a bit more specific in my \inputs, by actually including the .pdftex_t extension, but then the Makefile can take care of dependencies and re-building properly. But it needs an additional parsing step. (For reference, the relevant bits of my now deprecated Makefile are there [0]; I'm gradually splitting bits of functionality out so I can keep using them with you Makefile (: ).

Is there a particular reason that you would rather generate pdftex from it instead of just producing a .pdf file and including it using graphicx?

Computer Modern fonts in figures? (:

[0] http://scm.narf.ssji.net/git/latex-makefile/tree/latex.mk

shiblon commented 9 years ago

I see. Parsing a file looking for \input tags can work in many, many cases, but it is also trivial to defeat by accident. For example, if it happens to be commented out. That's the very easiest of the difficult cases, and it's still hard to get right.

Another extremely common case is when an \input files has \inputs of its own, etc. Building that dependency tree and tracking all of those down for the sake of parsing files is somewhat nontrivial and it is not at all uncommon.

The problem is that the only thing that can really parse latex is latex, and it barfs when it finds an unsatisfied \input, because it is essentially inlining that information and then relying on it later on.

It's a hard problem, and I have so far been very hesitant to introduce parsing of actual latex source. I don't mind parsing the logs and the aux and fls files: those are regular, generally line-based, and (relatively) easy to parse. Latex source is another beast entirely, and getting things wrong there has pretty dire consequences.

That said: we would not be modifying the .tex, just reading it. Perhaps parsing is not such a bad idea. We would still need to come up with a solution for the nested inputs problem.