Last modified: 14:52:26, Thu 09 Nov 2000 UTC

Technical notes

Perl notes

As I have emphasized again and again (users: "enough, already!"), epsmerge is intended to run on just about any Perl you might have out there (provided you have 5.000 or later). Many users are at universities or do not otherwise have root access, and can't be bothered with downloading the latest Perl, or even CPAN modules (installing CPAN modules without root access (i.e., in your home directory) while at the same time not aggravating your sysadmin by filling up your disk space?) Version 5.000 is certainly required since epsmerge is object oriented.

Even the Tk interface should run on just about any Tk in existence (at least above 4.0), but since it relies heavily on closures it requires Perl 5.001 or later. (Note: the Tk interface is not finished and I am working on more important aspects of epsmerge at the moment, but I will return to it later.)

Implementation notes

Security Issues

epsmerge is able to run perl scripts to generate labels. This is normally useful if (1) you need labels other than a few standard ones such as filename, time or whatever, and (2) you know perl. However, it is also technically a security issue if more than one user uses epsmerge in the same directory (where the default options file will be read).

So far, I have tried to solve the problem by sticking an $Allow_Scripts variable into the epsmerge file (i.e., the one called epsmerge). Default is `false'.

Perl specific

First of all, epsmerge is strict. I.e., if you run it with perl -w then it shouldn't say anything at all. Small Perl programs can easily be written without the strict pragma, but epsmerge is too complex for such youthful foolhardiness.

General programming issues

If you want to get to grips with the internals of epsmerge, you would have a much better chance if you knew about design patterns ([G]). For example:

Cell and its derived classes form a composite pattern. This is central to the design and modus operandi of epsmerge.
LabelDecoratorCell is a decorator.
Formatter is a Strategy pattern, but simplified, because there is currently only one strategy. (Which is, admittedly, growing rather big...)
Options is a simpleton, I mean Singleton pattern. Although the Option class is anything but simple, this design (from version 1.2.0) has allowed option handling, central to the inner workings of epsmerge, to be implemented in a much more efficient and, above all, beautiful way.
As of version 2.0, there is a FakeCell hierarchy which mirrors that of the cells (in fact, they should have been derived from a common abstract class hierarchy since they do share some code, but this would have complicated things too much). It is used to draw a sketch of the formatted page inside the formatter widget (when you use the Tk interface).
There is a CellFactory which is precisely what it says; it knows how to build the main cell (the cell representing a full page), and derived versions build using either the original cell hierarchy (now called FileCell to be precise, since their ultimate raison d'etre is to write a postscript file), or the Fake cells which draw their representation in a canvas widget.
The Io hierarchy is an abstract factory providing methods to construct certain simple dialogs and prompts. Again there are derived classes for each kind of interface.
Driver is an object hierarchy that really controls the whole process. There are derived versions for each kind of interface (currently console and Tk) which override certain methods for building windows etc.

There could be other patterns that I have forgotten about, but these are the important ones.

I decided to roll my own options handling package to get some more functionality beyond that offered by Getopt::Long. It hasn't quite stabilized in terms of functionality and interface, but there is nothing inside it that says ``epsmerge'', so it could be used for other Perl programs, too. More than half of the file is POD.

Postscript technicalities

As of version 2.0.0, I am trying to build support for extracting pages from (non-encapsulated) postscript files. The difficulty is that they will appear as parts of a page in the generated EPS/PS file, but they might still require prologs and setups. Worse yet, what happens when you merge pages from different postscript files, and they all require different kinds of prologs and setups?

I assume, until proved otherwise, that %%Begin(End)Setup gives setup code necessary to display page foo, and the %%Trailer cleans up whichever mess created by the setup. So each included thingy, whether from a non-encapsulated or encapsulated postscript file, would get the setup written before the file itself, and the trailer after it. Likewise, probably the same should happen with %%Begin(End)PageSetup and %%PageTrailer, except that page specific DSCs are not handled yet (as of 2.2.0).

Procedures and resources that occur in the included EPS or PS files are, as of 2.2.0, supposed to be written into the target file. However, to ensure that each is not written several times, I test uniqueness by using Perl hashes (rather than just the name specified). The entire body of the procedure/resource is hashed to prevent silly programs from cheating.

References

Note: the Adobe URLs are no longer valid and I don't know where they have hidden the information. Sorry.

[EPS]: Encapsulated Postscript File Format Specification, Version 3.0, Adobe Systems, Inc..
[G]: Gamma, Helm, Johnson, Vlissides: Design Patterns. Elements of Reusable Object-Oriented Software, Addison-Wesley.
[PS]: Postscript Language Document Structuring Conventions Specification, version 3.0, Adobe Systems, Inc..
[W]: Wall, Schwartz, Christiansen.: Programming Perl, 2nd ed., O'Reilly.