# What to do with 237 eps files?

I have some 237 .eps files that represent the printer's ornaments from the small press The Underground Grammarian. I would like to build and provide (to CTAN) a package similar to the pgfornament package. I'd like to create a command something like \UGOrnament which would take either a number or a name as indicated with the accompanying documentation. Other options would basically mirror \pgfornament. There are an additional 125 .tif files which should be provided as well but I thought I'd start with the .eps files first.

So 'What is the problem?' you say. Well as may be apparent, my ambitions are inversely proportional to my TeX-Fu. In a nutshell, I've no clue as to how I'd go about this. Knowing this, I ask the above. I don't want someone to do the work (although I'd not turn it down :) ) but I would appreciate links, suggestions and pointers to guide me. I've a copy of Herbert Voss' PSTricks and will most likely begin there but I'd like to gather as much information as I can.

I've given some thought to the API hence the reference to pgfornament, I've even thought about converting the files to a font or fonts since I have both open source and proprietary software for font creation. I think I'd rather go the sty approach instead. Thanks for reading...

-
From a packaging point of view, a font would have the great advantage of collecting all the images in a single file. If you build a package on top of the eps files you'd need to distribute all those files with it, probably both in eps and pdf format. You could still accompany the font with a package selecting the characters. –  Stephan Lehmke Feb 3 '13 at 6:49
Good points all @StephanLehmke although the pgfornament package shoves all of it's 196 images into a single .pro file, so the distribution needn't get out of hand file number wise. –  hsmyers Feb 3 '13 at 6:59
@StephanLehmke come to think of it, if there are sufficient advantages to both approaches I might do both. There are other uses for fonts, i.e. web applications that come to mind. –  hsmyers Feb 3 '13 at 7:01
Maybe you could add a link to the package you're talking about? I couldn't find pgfornament on CTAN and the package here contains 89 single pgf files with one ornament each. –  Stephan Lehmke Feb 3 '13 at 7:23
see ctan.org/pkg/pst-vectorian It also uses the code of eps images –  Herbert Feb 3 '13 at 7:32

pst-vectorian works in the same way. The code of the eps images was saved in a file pst-vectorian.pro (PostScript prologue file):

% PostScript prologue for psvectorian.tex.
% Version 0.03, 2011/11/05
%
/tx@vectorianDict 410 dict def
%
tx@vectorianDict begin
/vec1 {
1 setlinejoin
newpath
109.8516 58.404 moveto
102.7108 70.7583 88.4258 67.3824 82.4704 64.0235 curveto
76.5236 60.6518 72.9472 60.6518 69.3794 75.2496 curveto
[...]
119.3743 21.3326 136.0503 48.2933 136.0503 48.2933 curveto
119.3867 44.9173 116.9958 46.0498 109.8516 58.404 curveto
closepath
fill
} def
%
/vec2 {
[...]
closepath
fill
} def
...

from within pst-vectorian.sty the PostScript functions are called as vec1, vec2, a.s.o. with the possibility to change the font color.

-
The files I have were all created in Adobe Freestyle quite some years ago. Do I analyze the included dictionary throw out the un-necessary and proceed, or leave a single inclusion and then concatenate the eps files minus duplicate information? What about bounding box info? –  hsmyers Feb 3 '13 at 8:27
@hsmyers: analyze the dictionary and delete all what's not important for the code. A bounding box is not needed for an ornament which often is placed over some already given text area. pst-vectorian uses \rput. See the code of the documentation. –  Herbert Feb 3 '13 at 8:41
I've had some initial success using eps2eps on the source. That said I wonder if the following is necessary: cleartomark end end pagesave restore showpage %%PageTrailer %%Trailer %%Pages: 1 at the end of the file? –  hsmyers Feb 4 '13 at 22:56
@hsmyers: no that is all not important –  Herbert Feb 5 '13 at 6:36

I believe that .pro is a good way to go. However, many people use pdfLaTeX and they might like to benefit from your package, too. I therefore suggest converting all the files to .pdf as well (e.g. by epstopdf), and then merging them in a single file (using pdftk). The exact syntax to merge all ornament-*.pdf files in one file is

pdftk ornament-*.pdf cat output allornanements.pdf

Your package could then have a pdf and ps options that would switch between the PS loading command and the PDF one, that looks like

\includegraphics[page=#1]{allornaments.pdf}
-
This would have the advantage of being almost immediately do-able and testable. I think it could also be folded into the final solution. –  hsmyers Feb 3 '13 at 9:07
There's a way how to recognize whether the user invoked pdflatex, lualatex, xelatex or latex, which you could use to fit in the right option in case none is given. I'm just sorry that I don't remember how to do it :-/ –  tohecz Feb 3 '13 at 9:12
@tohecz and @hsmyers \ifpdf, \ifluatex, \ifxetex. See also packages iftex, ifpdf, ifluatex and ifxetex. –  Speravir Feb 3 '13 at 23:01
@Speravir thanks for the reminder. Tohecz I'm going ahead with your idea in parallel with the other approaches---thanks! –  hsmyers Feb 5 '13 at 1:25