gnuplot-beta — Developers and beta testers of new gnuplot code

Re: 'set size ratio' plot

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

jun...@so... wrote:
> The ratio-corrected box is seemed be centerd on the page.
> This change looks good for ploting just one graph, but it becomses
> practically impossible to put some ratio-corrected graphs on the positions
> which I want. Thus, I made some patches to controll this centering behavior
> by using the sign of the ysize.
> 
> There may be some problem, but please check.
> 
> Jun

Thanks for bringing this to attention, Jun.  This centering sounds like something I changed.  I may well have overlooked the case where the user wants to manually position a ratio corrected plot.

However, I'm not so sure adding meaning to a negative size value is the way to address this.  (Don't know how others feel about this, but I prefer simply adding another option if necessary.)

It seems to me that centering should simply be the default and if the user specifies a position then move the plot to that position.

Is there an alternative syntax to accomplish this?

Dan

Re: 'set size ratio' plot

[<br...@ph...>]

jun...@so... wrote:

> The ratio-corrected box is seemed be centerd on the page.
> This change looks good for ploting just one graph, but it becomses
> practically impossible to put some ratio-corrected graphs on the positions
> which I want. 

That's at least 50% practically impossible anyway --- a graph with 'set 
size ratio' turned on changes shape outside the control of 'set size'.
That's how that whole feature works.  Even after you fixated its
bottom left corner, its top right one can be anywhere.  I don't see how 
changing half the problem is of any help.  It would be just as easy to
adjust the main 'size' parameters manually, such that the difference 
between left-justified and centered position of the actual graph area 
becomes negligible.

 > Thus, I made some patches to controll this centering behavior
> by using the sign of the ysize.

I find that unacceptably obfuscated.  This is basically a change to
the origin and/or margin settings, not to the size of the graph.  It has 
no business being controlled as part of 'set size' at all --- even less 
so being hidden in the sign of a must-be-positive parameter.

'set size ratio' plot

[<jun...@so...>]

The ratio-corrected box is seemed be centerd on the page.
This change looks good for ploting just one graph, but it becomses
practically impossible to put some ratio-corrected graphs on the positions
which I want. Thus, I made some patches to controll this centering behavior
by using the sign of the ysize.

There may be some problem, but please check.

Jun


*** gadgets.c.org	Sat Apr  8 02:20:01 2006
--- gadgets.c	Sat Apr  8 02:21:02 2006
***************
*** 75,80 ****
--- 75,81 ----
  float xoffset = 0.0;		/* x origin */
  float yoffset = 0.0;		/* y origin */
  float aspect_ratio = 0.0;	/* don't attempt to force it */
+ TBOOLEAN centering_in_ratio = TRUE;      /* centering in ratio plot */
  
  /* space between left edge and plot_bounds.xleft in chars (-1: computed) */
  float lmargin = -1;


*** gadgets.h.org	Sat Apr  8 02:21:51 2006
--- gadgets.h	Sat Apr  8 02:22:12 2006
***************
*** 304,310 ****
  extern float xoffset;		/* x origin setting */
  extern float yoffset;		/* y origin setting */
  extern float aspect_ratio;	/* 1.0 for square */
! 
  /* plot border autosizing overrides, in characters (-1: autosize) */
  extern float lmargin, bmargin, rmargin, tmargin;
  
--- 304,310 ----
  extern float xoffset;		/* x origin setting */
  extern float yoffset;		/* y origin setting */
  extern float aspect_ratio;	/* 1.0 for square */
! extern TBOOLEAN centering_in_ratio; /* TRUE */
  /* plot border autosizing overrides, in characters (-1: autosize) */
  extern float lmargin, bmargin, rmargin, tmargin;


*** set.c.org	Sat Apr  8 02:20:08 2006
--- set.c	Sat Apr  8 02:21:15 2006
***************
*** 3468,3476 ****
  	    }
  	}
      }
!     if (xsize <= 0 || ysize <=0) {
  	xsize = ysize = 1.0;
  	int_error(NO_CARET,"Illegal value for size");
      }
  }
  
--- 3468,3485 ----
  	    }
  	}
      }
!     if ((aspect_ratio ==0.0) && (xsize <= 0 || ysize <=0)) {
  	xsize = ysize = 1.0;
  	int_error(NO_CARET,"Illegal value for size");
+     } else if ( xsize == 0.0 || ysize == 0.0 ) {
+ 	xsize = ysize = 1.0;
+ 	centering_in_ratio = TRUE;
+       	int_error(NO_CARET,"Illegal value for size");
+     } else if ( ysize > 0 ) {
+       centering_in_ratio = TRUE;
+     } else if ( ysize < 0 ) {
+       ysize = -ysize;
+       centering_in_ratio = FALSE;
      }
  }


*** graphics.c.org	Sat Apr  8 02:20:15 2006
--- graphics.c	Sat Apr  8 02:21:20 2006
***************
*** 899,910 ****
--- 899,915 ----
  
  	    if (current > required) {
  		/* too tall */
+ 	      if (centering_in_ratio) {
+ 		/* centering */
  		int height = plot_bounds.ytop - plot_bounds.ybot;
  		plot_bounds.ytop = plot_bounds.ybot + required * (plot_bounds.xright - plot_bounds.xleft);
  		height -= (plot_bounds.ytop - plot_bounds.ybot);
  		height /= 2;
  		plot_bounds.ytop += height;
  		plot_bounds.ybot += height;
+ 	      } else {
+ 		plot_bounds.ytop = plot_bounds.ybot + required * (plot_bounds.xright - plot_bounds.xleft);
+ 	      }
  	    } else {
  		int width = plot_bounds.xright - plot_bounds.xleft;
  		plot_bounds.xright = plot_bounds.xleft + (plot_bounds.ytop - plot_bounds.ybot) / required;

Re: Connect gnuplot_x11 to exterior application window

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

Hans-Bernhard Br=F6ker wrote:
> Daniel J Sebald wrote:
>=20
>> I've updated the patch, 1027032, for connecting to the external X11=20
>> window against the most recent CVS version.  [Is SourceForge updating=20
>> the CVS version... the last update seems over a week ago and there is=20
>> a bug.]
>=20
>=20
> The SF anonymous CVS is not being updated at this time, following the=20
> serious problem with their developers' CVS server over the past weekend=
.=20
>  See their "site status" (klick on the little coloured ball in the top=20
> right-hand corner of the main frame) for details.

Oh, thanks Hans.  (Sorry, but SourceForge has gotten so overloaded with d=
etail and nausiating animated adverts that I try spending as little time =
looking at it as possible.)

Dan

Re: Connect gnuplot_x11 to exterior application window

[<br...@ph...>]

Daniel J Sebald wrote:
> I've updated the patch, 1027032, for connecting to the external X11 
> window against the most recent CVS version.  [Is SourceForge updating 
> the CVS version... the last update seems over a week ago and there is a 
> bug.]

The SF anonymous CVS is not being updated at this time, following the 
serious problem with their developers' CVS server over the past weekend. 
  See their "site status" (klick on the little coloured ball in the top 
right-hand corner of the main frame) for details.

Connect gnuplot_x11 to exterior application window

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

I've updated the patch, 1027032, for connecting to the external X11 window against the most recent CVS version.  [Is SourceForge updating the CVS version... the last update seems over a week ago and there is a bug.]

This left off where Ethan couldn't get the TCL demo to run on his system.  Ethan, please give it a try and let me know if it is work.

The amount of extra code is actually small but the patch is big because "plot" is changed to "current_plot" in a lot of places.  I'd propose if this is added to CVS I go back and simply get rid of the EXPERIMENTAL option of "--disable-external-x11-window".  It would simply be bloating CVS with a bunch of conditionals for slightly different code.

Dan

Re: Bug Report and Enhanced text question

[Bastian M. <bma...@we...>]

Hans-Bernhard Br=F6ker wrote:
 > Bastian Maerkisch wrote:
 >> Ethan Merritt wrote:
 >
 >>> I don't think this is true.  Could you give a specific example?
 >>> For instance, the postscript driver itself knows little about text
 >>> layout.  That information is not available until much later, when
 >>> the output file is run through a postscript interpreter (e.g. a
 >>> PostScript printer, ghostscript). By then it is far to late
 >>> to feed any information back to the gnuplot core routines.
 >
 >> I think that this is only true for postscript. win.trm and pm.trm bot=
h
 >> need to know where to write the next piece of text and therefore need=

 >> to know the width of the text.
 >
 > Some drivers need to know the width.  The fact that the drivers exists=

 > is proof that they can get at it.
 >
 > Other drivers don't need it.  The fact that some drivers exist even
 > though they can't get at this information proves they don't strictly
 > need it.
 >

In another post yesterday Ethan already pointed out that he and I did hav=
e
a different understanding of Chris's question. I (still) agree that
information about the text layout size is not mandatory for every driver,=

but a useful and necessary information for some. So you're demonstration
wasn't really necessary.

--=20
Bastian M=E4rkisch
Physikalisches Institut, Universit=E4t Heidelberg

Re: Bug Report and Enhanced text question

[<br...@ph...>]

Bastian Maerkisch wrote:
> Ethan Merritt wrote:

>> I don't think this is true.  Could you give a specific example?
>> For instance, the postscript driver itself knows little about text
>> layout.  That information is not available until much later, when
>> the output file is run through a postscript interpreter (e.g. a 
>> PostScript printer, ghostscript). By then it is far to late
>> to feed any information back to the gnuplot core routines.

> I think that this is only true for postscript. win.trm and pm.trm both
> need to know where to write the next piece of text and therefore need
> to know the width of the text.

Some drivers need to know the width.  The fact that the drivers exists 
is proof that they can get at it.

Other drivers don't need it.  The fact that some drivers exist even 
though they can't get at this information proves they don't strictly 
need it.

> So for most terminals you really need a way to get feedback about the
> text layout size.

Counting and arguing about "most terminals" from a sample of just 4 of 
them  makes little sense.

 > Postscript is special since the decision about the exact positioning
> of enhanced text can (and must) be postponed to when the file is actually
> rendered.

It's not all that special.

The fact that GD needs that two-pass try-and-fixup technique to do right 
and centered horizontal justification is a flaw of GD, not something to 
base terminal API design on.

Re: Bug Report (reprise)

[Chris K <gnu...@li...>]

Ethan A Merritt wrote:
> On Wednesday 05 April 2006 02:24 am, Chris K wrote:
>>>> (The '/' character MUST be the first character after the '{'.)
>>> [the code] clearly skips spaces after each opening brace.
>>> So the "MUST" in the help and the code are in conflict.
> 
> I do not view this as a bug.
> 
> The docs state that the supported syntax is '{' followed immediately
> by '/'.  The code does support this.  It also forgives intervening
> whitespace, which is undocumented.  If you place extra whitespace
> in the command, then you have gone outside the documented spec and
> should not complain about the results. It happens that the code does
> something reasonable anyhow, which is a relatively user-friendly
> outcome and hardly deserves the label "bug".
> 

With only one parsing engine, then you get a consistent and implicitly defined
enhanced text specification.  The original Netscape browser made the decision to
be liberal in what it accepted and rendered, and so many people and programs
created nonstandard HTML and every other browser then had to deal with either
breaking backward compatibility with Netscape or copying the informal implicit
specification.  And upgrades to Netscape could not abandon the old leniency,
which is exactly what I am asking here: I want to make a clear decision on the
specification, document it, and make the parser match the documentation.

The only unclear clear bit of the enhanced text behavior and documentation has
to do with whitespace handling.  There are two goals to making a spec for this:

(1) It should be obvious to people which whitespace is significant so they can
add whitespace where they want it (i.e. principle of least surprise).
(2) It should be obvious to someone writing a GUI front-end how to write a
editor that generates enhanced text.

The secondary unclear bit of the current behavior is that the braces are not
always parsed in pair because of the localfontname parsing.

Re: Bug Report (reprise)

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

On Wednesday 05 April 2006 09:01 am, you wrote:
> Ethan A Merritt wrote:
> 
> > The docs state that the supported syntax is '{' followed immediately
> > by '/'.  The code does support this.  It also forgives intervening
> > whitespace, which is undocumented.
> 
> There's a difference between being undocumented and contradicting the 
> documentation, even more so if the relevant part of the documentation 
>   SHOUTS.  Documentation stating wrong facts is a bug in its own right.

I don't see how it can ever be a bug for the documentation to say
"the supported syntax requires that blah, blah, blah".
If the docs tell you not to do something, but you do it anyway, 
the fact that it happens to work is not a bug.  If it works today
but not tomorrow, that also is not a bug.  

I do agree that it is odd for the documentation to SHOUT while
stating the supported syntax.  

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: Bug Report (reprise)

[<br...@ph...>]

Ethan A Merritt wrote:

> The docs state that the supported syntax is '{' followed immediately
> by '/'.  The code does support this.  It also forgives intervening
> whitespace, which is undocumented.

There's a difference between being undocumented and contradicting the 
documentation, even more so if the relevant part of the documentation 
  SHOUTS.  Documentation stating wrong facts is a bug in its own right.

Re: Bug Report (reprise)

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

On Wednesday 05 April 2006 02:24 am, Chris K wrote:
> >> (The '/' character MUST be the first character after the '{'.)
> > 
> > [the code] clearly skips spaces after each opening brace.
> > So the "MUST" in the help and the code are in conflict.

I do not view this as a bug.

The docs state that the supported syntax is '{' followed immediately
by '/'.  The code does support this.  It also forgives intervening
whitespace, which is undocumented.  If you place extra whitespace
in the command, then you have gone outside the documented spec and
should not complain about the results. It happens that the code does
something reasonable anyhow, which is a relatively user-friendly
outcome and hardly deserves the label "bug".

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Bug Report (reprise)

[<br...@ph...>]

Chris K wrote:

>> So it looks like the line I call SKIPPY used to be after the (overprint==2)
>> parsing code and has been cut and pasted to now be before the (overprint==2)
>> code.  

Checking this (via "cvs annotate")... unlikely.  That line has been in 
that place ever since enhanced_recursion() moved to term.c late in 2003.

> I don't want to smash backward compatibility and then have to fix it.
> How can I check backward compatibility of enhanced text?
> I have just downloaded the version 3.7.3 code.   Should I take the behavior of
> its post.trm ENHPS_recurse routine as canonical?

Not really.  The latest release (i.e. 4.0) should be the baseline.  Any 
conflicts between source and documentation of that are bugs that need to 
be discussed here and fixed.  In case of doubt, given the lack of will 
to update documentation along with the changes to the source that is 
sort of a tradition among developers, the source is to be trusted more 
than the docs.

Re: Bug Report (reprise)

[Chris K <gnu...@li...>]

Before I can write the patch I want to, this specification bug below needs to be
resolved:

Chris K wrote:
> In the help text it claims:
> 
>> (The '/' character MUST be the first character after the '{'.)
> 
> But in term.c (edited to clarity) in the enhanced_recursion routine:
> 
>>         switch (*p) {
>>         case '{'  :
>>             {
>>                 while (*++p == ' '); /* Line I will call SKIPPY */
>>                 if (overprint == 2) {
>>                     ovp = (float)strtod(p,&p);
>>                     if (term->flags & TERM_IS_POSTSCRIPT)
>>                         base = ovp*f;
>>                     else
>>                         base += ovp*f;
>>                 }
>>                 --p;
>>                 if (*++p == '/') {
> 
> Which clearly skips spaces after each opening brace.  So the "MUST" in the help
> and the code are in conflict.  A related documentation / parser mismatch error is:
> 
>>  You can change the font for one or
>>  both strings ('~a{.5 /*.2 o}'---an 'a' with a one-fifth-size 'o' on top---and
>>  the space between the number and the slash is necessary), but you can't
>>  change it after the beginning of the string.
> 
> Which from reading the code and performing tests is wrong -- you MUST NOT put a
> space between the vertical shift and the '/'.
> 
> So it looks like the line I call SKIPPY used to be after the (overprint==2)
> parsing code and has been cut and pasted to now be before the (overprint==2)
> code.  This causes both of the differences with the help text documentation.
> 
> There are several fixes:
> *) Move SKIPPY back to below the (overprint==2) block, keep help text
> *) Change the help text to reflect the new behavior
> *) Put a copy of SKIPPY below the (overprint==2) block, change help text
> *) Delete SKIPPY and change the help text
> 
> 

I have checked the 4.0.0 tarball: The above code and bug looks to be the same in
that version. (I did not compile and test).

Consider this command which is currently accepted by the latest code, in
contradiction to help text:

plot x title "aaa{   /   Symbol   {   }   {   bbb}}ccc"

Which spaces should be required, optional, or forbidden?

The resulting label is "aaa   BBBccc"  where B means "Beta".  Which three spaces
from the command correspond to the three in the label?

These three: "}   {"

I don't want to smash backward compatibility and then have to fix it.
How can I check backward compatibility of enhanced text?
I have just downloaded the version 3.7.3 code.   Should I take the behavior of
its post.trm ENHPS_recurse routine as canonical?
It appears that this parser agrees with the help text about no space allowed
between "{/", though it lacks the overprint '~' capability.

Or does the development version of gnuplot have a "license to kill" backward
compatibility in corner cases?

-- 
Chris

Re: Bug Report and Enhanced text question

[Chris K <gnu...@li...>]

(moving back onto the list)

Ethan A Merritt wrote:
> On Tuesday 04 April 2006 12:24 pm, you wrote:
>> I strongly propose that '}' should also be excluded from the valid font name
>> characters, and therefore '{' as well.  The new code would be:
>>
>>>                     localfontname = p;
>>>                     while ((ch = *p) > ' ' && ch != '=' && ch != '*' 
>>>                                            && ch != '{' && ch != '}')
>>>                         ++p;
>>>                     save = *(savepos=p);
> 
> I just tried that, and it doesn't quite work.
> See for example the output of
> 
>    set title "aaa{/Symbol{bbb}}ccc"
> 
> Your intent, I think, was to forgive the missing ' ' and
> proceed to process the next chunk of text.  But it seems to
> need additional checks and/or case statements in order to
> avoid spurious error messages about mismatched curly braces.
> 
> Anyhow, if you can prepare a patch with a bit more
> error checking and testing, I'll apply it.
> 

I see what the problem is now.  You need a sacrificial character, a space, after
the font name in order to use the parsing optimization where you overwrite the
space with '\0'.  So in the above "aaa{/Symbol{bbb}}ccc\0 "you get
"aaa{/Symbol\0bbb}ccc\0" for localfontname "Symbol\0" and recurse with "bbb}ccc\0".

If the next character is '=' or '*' then it has to recognize this before
overwriting it with '\0'.

The overwritten character is always stored and replaced after the recursion.

If the parser would just copy the localfontname to separate storage, this would
not be an issue, and the parser would not need to mutate input string this way.

So long as the number of font changes in a plot is less than a few thousand, the
performance loss will be negligible.

I will contribute a patch for this.

-- 
Chris

Re: Bug Report and Enhanced text question

[Bastian M. <bma...@we...>]

Ethan Merritt wrote:
>=20
> I'm not sure we're all three of us on the same page here.
> It may be that I misunderstood the original question.
>=20
> The terminal driver itself may need to track such information
> internally in order to implement enhanced text.
> That is certainly true.
>=20
> But I thought Chris's question was whether a driver was=20
> obligated to pass such information back to the core code.
> The answer to that one is 'no'.=20
 >
> It would be nice if the core routines *could* ask a driver
> for specific details, but unfortunately this doesn't work
> in general.  PostScript is a major example, but it is also
> true for svg and x11. =20
>=20

I fully agree. Such a routine would make a nice (optional) addition
to the terminal interface though. That way we could provide non terminal
specific versions of enh_put_text(), enh_flush() and enh_open().
These could be used for gd.trm, win.trm, pm.trm and probably pdf.trm and
bitmap based terminals.

--=20
Bastian M=E4rkisch

Re: Bug Report and Enhanced text question

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

On Tuesday 04 April 2006 12:25 pm, Bastian Maerkisch wrote:
> > 
> >> The usual enhanced_recursion calls will need feedback about the text 
> >> layout size from the terminal driver.
> 
> > For instance, the postscript driver itself knows little about text
> > layout.  That information is not available until much later, when
> > the output file is run through a postscript interpreter 
> > (e.g. a PostScript printer, ghostscript). By then it is far to late
> > to feed any information back to the gnuplot core routines.

> A quick look at gd.trm reveals the following piece of code in ENHGD_put_text():
> 
>     /* EAM - Software text justification requires two passes */
>      if (png_state.justify == RIGHT || png_state.justify == CENTRE)
> 	ENHgd_sizeonly = TRUE;
> 
> So for most terminals you really need a way to get feedback about the text layout
> size.

I'm not sure we're all three of us on the same page here.
It may be that I misunderstood the original question.

The terminal driver itself may need to track such information
internally in order to implement enhanced text.
That is certainly true.

But I thought Chris's question was whether a driver was 
obligated to pass such information back to the core code.
The answer to that one is 'no'. 

It would be nice if the core routines *could* ask a driver
for specific details, but unfortunately this doesn't work
in general.  PostScript is a major example, but it is also
true for svg and x11.  

[OK, x11 could be made to work that way but it would probably 
require a new set of pipes between gnuplot and gnuplot_x11.
I did consider doing this at one point, but decided it was
too much work for too little gain.]

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: Bug Report and Enhanced text question

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

Chris K wrote:

> I strongly propose that '}' should also be excluded from the valid font name
> characters, and therefore '{' as well.  The new code would be:
> 
> 
>>                    localfontname = p;
>>                    while ((ch = *p) > ' ' && ch != '=' && ch != '*' 
>>                                           && ch != '{' && ch != '}')
>>                        ++p;
>>                    save = *(savepos=p);

Couldn't the string functions be utilized?  I.e., "strspn()" and "isalnum()"

http://www.cppreference.com/stdstring/index.html

Dan

Re: Bug Report and Enhanced text question

[Bastian M. <bma...@we...>]

Ethan Merritt wrote:
> On Tuesday 04 April 2006 11:23 am, Chris K wrote:
>=20
> I'll have a look at the rest of your comments later, but for this one..=
=2E
>=20
>> The usual enhanced_recursion calls will need feedback about the text l=
ayout size
>> from the terminal driver.

>=20
> I don't think this is true.  Could you give a specific example?
> For instance, the postscript driver itself knows little about text
> layout.  That information is not available until much later, when
> the output file is run through a postscript interpreter=20
> (e.g. a PostScript printer, ghostscript). By then it is far to late
> to feed any information back to the gnuplot core routines.

I think that this is only true for postscript. win.trm and pm.trm both
need to know where to write the next piece of text and therefore need
to know the width of the text.
A quick look at gd.trm reveals the following piece of code in ENHGD_put_t=
ext():

    /* EAM - Software text justification requires two passes */
     if (png_state.justify =3D=3D RIGHT || png_state.justify =3D=3D CENTR=
E)
	ENHgd_sizeonly =3D TRUE;

But also for left justified text the gdlib routines return the new positi=
on
after put_text and hence return the size of the text output.

So for most terminals you really need a way to get feedback about the tex=
t layout
size. Postscript is special since the decision about the exact positionin=
g
of enhanced text can (and must) be postponed to when the file is actually=

rendered.

Bastian

--=20
Bastian M=E4rkisch

Re: Bug Report and Enhanced text question

[Chris K <gnu...@li...>]

Ethan Merritt wrote:
> On Tuesday 04 April 2006 11:23 am, Chris K wrote:
> 
> I'll have a look at the rest of your comments later, but for this one...
> 

I have an additional comment about term.c's enhanced_recursion.  It accepts
character for the name of the new font with this code:

>                     localfontname = p;
>                     while ((ch = *p) > ' ' && ch != '=' && ch != '*')
>                         ++p;
>                     save = *(savepos=p);

I strongly propose that '}' should also be excluded from the valid font name
characters, and therefore '{' as well.  The new code would be:

>                     localfontname = p;
>                     while ((ch = *p) > ' ' && ch != '=' && ch != '*' 
>                                            && ch != '{' && ch != '}')
>                         ++p;
>                     save = *(savepos=p);

This way input like "{/Symbol}" does not parse a local font name of "Symbol}"


>> The usual enhanced_recursion calls will need feedback about the text layout size
>> from the terminal driver.
> 
> I don't think this is true.  Could you give a specific example?
> For instance, the postscript driver itself knows little about text
> layout.  That information is not available until much later, when
> the output file is run through a postscript interpreter 
> (e.g. a PostScript printer, ghostscript). By then it is far to late
> to feed any information back to the gnuplot core routines.
> 

I think that answers my question.  The output terminal code does not need to
measure the size of the text in order to succeed.  It should have been obvious,
but other drivers do such measurements, so I was uncertain.

>> If a terminal decided to handle the enhanced text 
>> codes internally in the term->put_text call, without using the
>> enhanced_recursion, would it still need to send any information to
>> gnuplot about the text size?
> 
> I'm still not sure what information you mean.
> Are you talking about the estimated string length?
> That estimation is actually done by a special driver that
> does nothing else - estimate.trm.
> 

I had noticed the estimate.trm file, but I did see where it was being used.

What I am hoping to do is have port.trm just put the enhanced text string (with
all the font commands and special codes) into the output. No calls to
enhanced_recursion|open|writec|flush will be made.

Thus port.trm will never get any measurement of the size of the enhanced text.

Then (perhaps much later), the Haskell code must parse the enhanced text as much
like enhanced_recursion as possible while rendering it.  Thus I have been
reading that code very very closely.

I have created a parser in Haskell to comprehend the enhanced text strings.
(Including an amusingly complete emulation of strtod) (And I mimicked the
current code for enhanced_recursion so I will need a bug fix from the menu in my
last message).  The next thing to do is to transform this into Render and Pango
instructions for display.

-- 
Chris

Re: Bug Report and Enhanced text question

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

On Tuesday 04 April 2006 11:23 am, Chris K wrote:

I'll have a look at the rest of your comments later, but for this one...

> The usual enhanced_recursion calls will need feedback about the text layout size
> from the terminal driver.

I don't think this is true.  Could you give a specific example?
For instance, the postscript driver itself knows little about text
layout.  That information is not available until much later, when
the output file is run through a postscript interpreter 
(e.g. a PostScript printer, ghostscript). By then it is far to late
to feed any information back to the gnuplot core routines.

> If a terminal decided to handle the enhanced text 
> codes internally in the term->put_text call, without using the
> enhanced_recursion, would it still need to send any information to
> gnuplot about the text size?

I'm still not sure what information you mean.
Are you talking about the estimated string length?
That estimation is actually done by a special driver that
does nothing else - estimate.trm.

 
-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Bug Report and Enhanced text question

[Chris K <gnu...@li...>]

Hi,

  In considering whether to add enhanced text to port.trm, I have a question:

The usual enhanced_recursion calls will need feedback about the text layout size
from the terminal driver.  If a terminal decided to handle the enhanced text
codes internally in the term->put_text call, without using the
enhanced_rercusion, would it still need to send any information to gnuplot about
the text size?

Also, in looking around to add enhanced text to port.trm, I was reading the
documentation in "gnuplot> help enhanced" and comparing that to the parser in
term.c and I found a contradiction.

In the help text it claims:

> (The '/' character MUST be the first character after the '{'.)

But in term.c (edited to clarity) in the enhanced_recursion routine:

>         switch (*p) {
>         case '{'  :
>             {
>                 while (*++p == ' '); /* Line I will call SKIPPY */
>                 if (overprint == 2) {
>                     ovp = (float)strtod(p,&p);
>                     if (term->flags & TERM_IS_POSTSCRIPT)
>                         base = ovp*f;
>                     else
>                         base += ovp*f;
>                 }
>                 --p;
>                 if (*++p == '/') {

Which clearly skips spaces after each opening brace.  So the "MUST" in the help
and the code are in conflict.  A related documentation / parser mismatch error is:

>  You can change the font for one or
>  both strings ('~a{.5 /*.2 o}'---an 'a' with a one-fifth-size 'o' on top---and
>  the space between the number and the slash is necessary), but you can't
>  change it after the beginning of the string.

Which from reading the code and performing tests is wrong -- you MUST NOT put a
space between the vertical shift and the '/'.

So it looks like the line I call SKIPPY used to be after the (overprint==2)
parsing code and has been cut and pasted to now be before the (overprint==2)
code.  This causes both of the differences with the help text documentation.

There are several fixes:
*) Move SKIPPY back to below the (overprint==2) block, keep help text
*) Change the help text to reflect the new behavior
*) Put a copy of SKIPPY below the (overprint==2) block, change help text
*) Delete SKIPPY and change the help text


Also, I am amused that strtod is parsing the numbers for things like the font
size.  Thus "{/=-0x.Deap1Rising}" would print "Rising" with a font size of -1.73926

This should be left undocumented.  As should "/=INF" and "/=NaN".

Finally, the strtod calls all are prefixed with (float) which means it ought to
be a strtof call, so I assume this was done for portability reasons.

Re: moving origin for "set size ratio"

[<br...@ph...>]

Shigeharu TAKENO wrote:
> But a difference appears when we use the ratio option of 
> "set size": 

That difference was introduced on purpose.

> The graph of cvs version is upper than the one of gnuplot-4.0. 

More to the point: the usable region of a 'set size ratio' plot always 
used to be aligned to the left and bottom of the page (i.e. the 
rectangle defined by 'set size' except the ratio and 'set origin'). 
This bias annoyed enough people that it got changed.  Now the 
ratio-corrected box is centered on the page.

moving origin for "set size ratio"

[Shigeharu T. <sh...@ie...>]

shige 04/03 2006
----------------

There may be no difference between gnuplot-4.0 and cvs version 
for the followings:

 set size 0.3 0.6
 set origin 0.2,0.2
 plot x

But a difference appears when we use the ratio option of 
"set size": 

 set size ratio 1 0.3 0.6
 set origin 0.2,0.2
 plot x

The graph of cvs version is upper than the one of gnuplot-4.0. 
This may be caused by the following code in src/graphics.c 
(rev. 1.181, line 900-915):

    if (current > required) {
        /* too tall */
        int height = plot_bounds.ytop - plot_bounds.ybot;
        plot_bounds.ytop = plot_bounds.ybot + required * 
            (plot_bounds.xright - plot_bounds.xleft);
        height -= (plot_bounds.ytop - plot_bounds.ybot);
        height /= 2;
        plot_bounds.ytop += height;
        plot_bounds.ybot += height;
    } else {
        int width = plot_bounds.xright - plot_bounds.xleft;
        plot_bounds.xright = plot_bounds.xleft + 
           (plot_bounds.ytop - plot_bounds.ybot) / required;
        width -= (plot_bounds.xright - plot_bounds.xleft);
        width /= 2;
        plot_bounds.xright += width;
        plot_bounds.xleft += width;
    }

This may move the left bottom point of the graph even if the 
origin is set at desired point. I think this may cause some
problems when user decides the origin.

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Re: gnuplot question

[Petr M. <mi...@ph...>]

>>> How do I set palette to read in a binary rgb palette file

There are several ".lut" binary palette file types, which one do you want 
gnuplot supports? All? (ImageJ, matlab/octave, ...) Do you have a C code?

>> According to
>>     help palette file
>> only ascii files are accepted, so convert your binary file in advance.
>
> Is there any objection to binary data files for the palette?

I think that those .lut et al have some header to be parsed to understand 
the structure.

---
PM