svg -> pdf via inkscape improved

[shiblon]

Originally reported on Google Code with ID 117

With version inkscape v0.48 it is possible to export svgs via inkscape woth latex support
(http://www.ctan.org/tex-archive/info/svg-inkscape/). It'd great if this Makefile support
this behaviour:

a fast patch modify line 2276 to:
# $(call convert-svg,<svg file>,<eps file>,[gray])
convert-svg     = $(INKSCAPE) --without-gui $(if $(filter %.pdf,$2),--export-pdf,--export-eps)='$2'
--export-latex --file='$1'

Reported by sandroknauss on 2011-03-13 16:13:02

[shiblon]

So, does adding the following to your Makefile.ini work?

INKSCAPE := inkscape --export-latex 

Reported by shiblon on 2011-03-15 14:43:44

• Status changed: Started

[shiblon]

Patched in r8748358cfdb5.  Attached new makefile.  Let me know if it works.

Reported by shiblon on 2011-03-15 14:47:49

---

• Attachment: Makefile

[shiblon]

Ok I now see this patch doesn't fixed it :(

You also need a additional target:
convert-svg-latex = $(INKSCAPE) --without-gui $(if $(filter %.pdf,$2),--export-pdf,--export-eps)='$2'
--export-latex  --file='$1'

%.pdf %.pdf_tex %.pdf_tex.tex:  %.svg
    $(QUIET)$(call echo-graphic,$^,$*.pdf)
    $(QUIET)$(call convert-svg-latex,$<,$*.pdf,$(GRAY))

Reported by sandroknauss on 2011-03-15 15:06:21

---

• Attachment: ink-latex-tex.tar

[shiblon]

No r8748358cfdb5 doesn't fix the problem. If someone use export-latex than he have to
use \input to include the figures. And without he has to use includegraphics. Basiclly
inscape produces a %.pdf and %.pdf_tex file out of one svg. But input wants to include
%.pdf_tex.tex...

Another problem with the Makefile appended in Comment #3 is that the pdf_tex file isn't
deletet by a make clean!

Reported by sandroknauss on 2011-03-15 15:22:42

[shiblon]

Aha.  Well, including \input files (automatically building them) is a real problem with
the makefile, because it can't automatically generate dependency info with those. 
That's a problem with pdflatex (regular latex works fine here), so I'm not sure how
to deal with it.

Perhaps we just won't support export-latex after all, at least not natively. :(

I think that folks that want to use export-latex might need to put stuff into their
Makefile.ini file.  Maybe we can try that angle first, and when we have a .ini that
works, it might illuminate the path toward making this work automatically.

Reported by shiblon on 2011-03-15 15:59:05

[shiblon]

Hi.

I change the inkscape command:
convert-svg = $(INKSCAPE) --without-gui --export-area-drawing $(if $(filter %.pdf,$2),--export-pdf,--export-eps)='$2'
--export-latex '$1' 

and create the files like here:
%.pdf:  %.svg
    $(QUIET)$(call echo-graphic,$^,$@)
    $(QUIET)$(call convert-svg,$<,$@,$(GRAY))

%.pdf_tex:  %.svg | %.pdf
    $(QUIET)$(call echo-graphic,$^,$@)
    $(QUIET)$(call echo-graphic,$<,$@,$(GRAY))

%.pdf_tex.tex:  %.pdf_tex
    $(QUIET)$(call echo-graphic,$^,$@)
    $(QUIET)cp $^ $@

and in latex:
\begin{figure}
\centering
\def\svgwidth{0.5\columnwidth}
\input{SVG.pdf_tex}
\end{figure}

It works, but if some svg file is added like figure (\includegraphics[]{SVG}, then
the makefile dont creates the pdf_tex file and dont clean it.

Maybe some change on the inkscape command line option may be posible to make this simpler.

Reported by paweld2 on 2011-04-03 22:57:37

[shiblon]

I'm leaving this issue open, but all of my experience with using \input to get graphics
is making me want to run away.  As you are noticing, dependencies are nontrivial in
cases like these.

I don't understand what your %.pdf_tex: target is supposed to do; it looks like you
aren't actually doing any work, just echoing.  Is that what you intended?

Reported by shiblon on 2011-04-04 15:37:29

• Status changed: New

[shiblon]

Hi
Yes, the .pdf_tex file is created actually by target %.pdf. But the target :
%.pdf_tex:  %.svg | %.pdf
tells makefile to execute first the "%pdf" target and then the %pdf_tex. When make
executes the %.pdf_tex target it checks if the file was created and then remember to
delete it on clean.

The \include command use file .pdf_tex.tex, that is just a copy of .pdf_tex.

Maybe inkscape people will give a better interface to use --export-latex on next versions.

Reported by paweld2 on 2011-04-04 20:06:51

[shiblon]

Thanks for explaining the way you set up the dependency graph there.

The main issue here is that LaTeX (in all its variants) will *fail* on the first missing
graphic when that graphic is included via \include or \input.  That means that you
can't, for example, have a bunch of .svg files in your directory, type "make" and have
it work.

What will instead happen is it will build the first missing graphic and then fail.
 The only way to make it not fail is to run "make" over and over again until all N
graphics are created.  That sucks.

The only way around this issue is to have a separate phony target in the makefile,
like "all-svg-tex" that builds all of your graphics, then you can just build the rest
normally.  But, if we're going to do that anyway, we might as well just encourage people
to create their own graphics-building phony target in Makefile.ini.

Anyway, it's a thorny issue.  If there were a reliable way for latex to tell us which
files it is missing (*all* such files) then this would be fine, but there isn't, and
it is not, in fact, even theoretically possible, since files that go through input
can contain arbitrary code that is referenced later.

So, I've shied away from any kind of graphics inclusion that is not based on \includegraphics
for that reason.  I have caved on it once before, though, for pstex files (see the
die-on-pstex definition in the makefile for what happens in this case: all I can do
is output a warning and quit until the user has manually run "make all-pstex").

We can do something like I did with the pstex case if that's warranted, here.  It's
worth considering.  But, we would need to come up with a standard filename suffix so
that everyone who just wants .pdf output from inkscape doesn't suffer from the more
esoteric svg->tex pipeline.

Reported by shiblon on 2011-04-04 20:46:09

[shiblon]

Try this example, 2 svg files. make executed ones works.

Reported by paweld2 on 2011-04-04 21:03:00

---

• Attachment: raport.tar.bz2

[shiblon]

anyway, I agree with You. If somebody needs the --export-latex feature, then in this
issue is enough information to create a custom makefile.

Reported by paweld2 on 2011-04-04 21:05:33

[shiblon]

If it should go into the standard makefile you have to differ the two ways of creating
svg for latex. the one way is svg->pdf (without tex output) and the other way svg->pdf
& pdf_tex the problem is that the pdf isn't the same. In the first way all text is
insde the pdf. At second excluded to tex. But it is easy to differ. If the pdf_tex
is needed than the --export-latex should be used. Otherwithe it should be run without
it :)

Reported by sandroknauss on 2011-04-04 21:55:30

[shiblon]

Sure, and the way I've dealt with that in the past has been to enforce a file name convention.

For example, if you want to build a .pdf from .svg and use \includegraphics, things
work as before.  If, however, you want to build a .pdf_tex and do it with \include,
we might consider telling people to name their files something.tex.svg or similar.

If we do it that way, we can automatically generate the appropriate targets and handle
things transparently (except for the warning message that you need to run "make all-svg-pdf"
first).  Just thoughts.

Reported by shiblon on 2011-04-05 14:43:37

[shiblon]

https://bugs.launchpad.net/inkscape/+bug/751667

Reported by paweld2 on 2011-04-05 20:23:17

[shiblon]

I don't think that bug really makes sense, and it definitely doesn't solve the problem
here, anyway.  To reiterate, the problems are these, and they really are LaTeX and
Make issues, not inkscape issues:

1) LaTeX can't proceed if something that it \input or \include is not available.  It
just can't.  It can't even do it theoretically, so it isn't a bug - it's the way the
universe is.

2) We can't automatically determine, before running LaTeX, using only Make, which files
should be pdf_tex and which should not, unless we do it in the file name.

So, for point 1, we're stuck with detection and manual intervention, like a "all-pdf-tex"
phony target and a warning.

For point 2, we can enforce that people name their files .tex.svg or similar, and then
we can do all the detection we want.

Reported by shiblon on 2011-04-06 16:16:46