I am creating a new document class that needs to render an image (e.g., a logo) on the title page. What is the correct way to distribute image with the class? Should the image file be distributed along with the .cls file? That seems like a hack to me, since the user would have to have that image file in the same directory as each of the documents that uses the class, correct?

I seem to recall (from years ago) reading about a method for embedding an image into a .tex file itself. That seems prone to error, too, since one would have to know if the document is being rendered using pdftex (requiring the image to be a .pdf file) as opposed to latex (requiring a .eps file).

The approach up with which I ended was to convert the logo to Tikz code which I embedded in the .cls file. The downside is that my class now requires tikz as a dependency, and many users with old LaTeX installations don't have tikz installed.

My approach works well because my original image is simple vector art. What would one do if it were a raster image?

What is the correct way to handle this?


2 Answers 2


There are a few approaches, and the 'best' one depends upon the nature of your target community.

Approach one is to use a .dtx file to distribute your class. You can then include and .eps file in the source and have it extract out on unpacking. I've done this in the chemstyle package. Now, you will end up needing to use latex rather than pdflatex in this case, although automatic conversion is available using the auto-pst-pdf package or in TeX Live 2010 with no extra effort.

Approach two is to distribute your files as a ready-to-install 'TDS-style' .zip file. The idea here is that you include everything in a .zip file with the correct folder structure to just unzip in the local texmf folder on the users PC. In that case, you can include both a .eps and .pdf version of the picture. This method is also best for raster images, as you can have a .jpeg for pdflatex and convert it to .eps format for latex users.

The third approach is as you say to use tikz. That avoids needing anything other than the .cls file itself, and keeps things easy to use with latex and pdflatex. The downside is the requirement for a reasonably new distribution. Then again, you might find it better to require something up to date as other packages can also change a lot over the years.

Finally, you could just not worry too much and provide a standard .zip file including the necessary extras. This is often seen with journals. It's then down to the user to put the right files in the right place, but this is probably the easiest and most general approach for you.

As I say, what is best in a given case does to some extent depend on the situation. For example, normally logos are only needed withing organisations. I do a journal class which in the 'real thing' includes a logo, but that is only needed for final printing by the publisher. So the user version just has a space!


I'm not sure what the correct way to handle this is, but here's one idea. End your .cls file with \endinput. After that, include the contents of the eps. After that, put in a marker line and then include the contents of the pdf.

Then, for the code that needs to display the image, use \openin and the e-TeX extension \readline to read your class file line by line until you reach the \endinput. Then you \openout the foo.eps file to write, read and write each line until you reach the marker. Then you \closeout the eps file, \openout the foo.pdf file, read and write each line until \ifeof is true. (The e-TeX extension \unless is pretty handy in loops like \loop\unless\ifeof\file ...\repeat.) Finally \closeout the pdf and \closein the class file.

Then you can just use \includegraphics{foo} and it'll pick the correct one.

There are some details to take care of such as handling the \endlinechar, but in principle, it should work.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.