# 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