gnuplot-beta

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.

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

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Broeker wrote:

>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.
>

Yes, that seems like an assembler controlled directive.

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

Can you issue an assembler directive using the "asm()" command depending 
upon if it is DOS?  How many different assemblers are there for DOS? 
 (Borland, Microsoft)   And how different are there assembler commands 
for control memory location?  But that might still not do it, because 
controlling the string placement is the issue, right?

This is odd, I just grabbed an old Microsoft C book by Jamsa.  He has an 
example:

main()
{
   char far *str = "Message to display";
   str_display(str);
}

where the subroutine has the command

   printf("%c %p\n", str[i], &str[i]);

which ends up printing the memory values as

6CB2:0282 M
6CB2:0283 e
...

and so on.  So that seems to suggest to me that assemblers should be 
programmed smart enough to recognize that the strings declared with 
"far" pointers can be placed in far memory blocks.

Perhaps the C syntax above is conflicting.  Maybe by also declaring the 
pointer as "const", the assembler is forced to place the strings in the 
segment where constant memory is located; and that may be in the code 
segment.  As a wild guess, you might try removing the "static" and/or 
"const" qualifiers.

Dan

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

[Ethan A M. <merritt@u.washington.edu>]

On Saturday 28 February 2004 08:12 am, Hans-Bernhard Broeker wrote:
> On Fri, 27 Feb 2004, Ethan Merritt wrote:
> > 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.

People can always break things if they try hard enough.

The normal unix way would be to install the default prologue file read-only
in some system directory, but have the program check first for a 
possibly modified copy in ~/.gnuplot/prologue.ps  or some such.
The first line of defence in the FAQ and in screening bug reports then
becomes:  "If you have a locally customized version of prologue.ps
in your home directory, please remove it and see if the problem persists."

-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle

Re: PostScript prologue

[Dave D. <dde...@es...>]

Hans-Bernhard Broeker <br...@ph...> writes:

> 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.
>



Aren't string literals merely a convenience feature. You can implement
things explicitly as

static const char label1[] = "hello world\n";

main()
{
  printf(label1);
}

which probably generates identical code (apart from pollution of name space)


So, while tedious, it should be possible to force the string data
to go anywhere you want ..?


dd
-- 
Dave Denholm              <dde...@es...>       http://www.esmertec.com