Re: PostScript prologue [was: 16-bit versions of gnuplot doomed?]

[Hans-Bernhard B. <br...@ph...>]

On Fri, 27 Feb 2004, Ethan Merritt wrote:

> It occurs to me that we might use the approach of Adobe products
> like FrameMaker.  The long PostScript prolog that is constant for
> every output document is stored as a separate file in some appropriate
> directory, and then copied into the output stream when a new 
> document is being generated.

Yeah, that idea had been creeping around at the back of my mind, too.

> 1) It doesn't take up any space in the source code module, which is
>    what your DOS compiler doesn't handle well

At least part of the blame for that goes to the language itself.  There's
no syntax in C to influence where string constants are to be stored.  
If you look at the (slightly modified) definition of PS_header:

	static const char GPFAR * const GPFAR PS_header[] = {
	   "line of text\n",
	   "line of text\n",
	   /*...*/
	  "last line\n"
	};

you'll find that there are two GPFAR markers for the array of pointers,
i.e. it's a "far array" of "far pointers".  But I can't tell the compiler
to put the *strings* themselves into a "far data" or "far code" segment.

I'm not quite through trying all possible tricks to get this through
the compiler's limitations, though.

> 2) It allows local customization of the prologue without having to
>    recompile the main program. 

That would complicate bug report handling, though --- it's one more thing
exposed to be broken by users who don't quite know what they're doing.

> 3) It is possible to have multiple, printer- or language- specific,
> prologues.

I don't really see a need for that...  The prologue we have seems to work
reasonably well for everyone.

> The only possible down-side I can think of at the moment is that this
> separate prologue file might get lost if the installation process is botched.

That's indeed a potentially serious problem, mainly because there's no
"standardized" directory layout for DOS and Windows programs.  Win16
doesn't even recognize the "c:\program files\package" scheme.

Even now, it may take an environment variable just to allow DOS and 
Windows gnuplot to reliably find their help files.

I'll include this option in my further considerations ...

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.