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

Re: makefile modification for canvas.trm for gnuplot windows, djgpp and so son

[Tatsuro M. <tma...@ya...>]

Hello


I have misled about CANVAS_JSDIR, CANVAS_ENH, CANVAS_NOENH, and CANVAS_OTHER.
The location  /usr/local/share/gnuplot/<version>/js only for unixy environments.

I could like to confirm the following 

1. Files in the directry ...../js are to be placed in the suitable place in the distribution.
For the example, windows distribution ...../share/js like as .../share/postscript seems to be
suitable.

2.The directriy where the javascript library files and gnuplot.css are located in the document of the
distribution.

3.In makefile.xxx,  operations for installing javascript library files and gnuplot.css to
$(DESTDIR)/$(GNUPLOT_CANVAS_JSDIR) are to be described.  

Are my recognition right?
  
I will wait comments on this matter.

Regards

Tatsuro


--- Tatsuro MATSUOKA  wrote:

> Hello
> 
> In the gnuplot help,
> 
> The default standalonemode creates an html page containing javascript code that renders the plot
> using
> the HTML 5 canvas element.The html page links to a javascript library 'canvastext.js'.By default
> this
> is a link to a local file,usually in directory /usr/local/share/gnuplot/<version>/js.You can
> change
> this by using the jsdiroption to set the directory to either a local file or a general URL.The
> latter
> is usually appropriate if the plot is exported for viewing on remote client machines.
> 
> are described.
> 
> The above description : 
> 
> The html page links to a javascript library 'canvastext.js'. By default this is a link to a
> local
> file,usually in directory /usr/local/share/gnuplot/<version>/js.
> 
> seems to be effective for binaries generated through configure script.
> 
> Binaries generarted by directly through the platform dependent make file (e.g. makefile.mgw,
> makefile.dj2, and so on) seems to not be considered concerning the directry of 
> 
> 'canvastext.js'
> 
> I think that each makefile should be modified from this point
> 
> I have a look at canvas.trm
> 
> The below
> CANVAS_JSDIR
> CANVAS_ENH
> CANVAS_NOENH
> CANVAS_OTHER
> 
> should be defined in the makefile ? right
> 
> Can the 'CANVAS_JSDIR' be treat as that of GNUPLOT_PS_DIR?
> How other flags CANVAS_ENH, CANVAS_NOENH, CANVAS_OTHER be treated?
> 
> Regards
> 
> Tatsuro 
> 
> 
> --------------------------------------
> Power up the Internet with Yahoo! Toolbar.
> http://pr.mail.yahoo.co.jp/toolbar/
> 


--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: makefile modification for canvas.trm for gnuplot windows, djgpp and so son

[Tatsuro M. <tma...@ya...>]

Hello

--- Allin Cottrell wrote:

> 
> It's inevitably going to be terrible pain to keep these up to
> date.  Isn't there some way they could be auto-generated?
> 
If it is possible to do it, it will be better.
However it's difficult to do.

Other possibility is to use ./configure ; make ; process as possible, I think.

For mingw and mingw gcc on cygwin with option are able to treat in ./configure ; make process.

Unfortunately I have litte knowledge of auto tools.  

Regards

Tatsuro


 


--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: makefile modification for canvas.trm for gnuplot windows, djgpp and so son

[Tatsuro M. <tma...@ya...>]

Hello

--- Ethan wrote:
> Could you please open a bug report on the SourceForge tracker?

Done. Thank you for your suggestion.

Regards

Tatsuro

--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: makefile modification for canvas.trm for gnuplot windows, djgpp and so son

[Tatsuro M. <tma...@ya...>]

Hello

--- Ethan A Merritt  wrote:

> 
> Could you please open a bug report on the SourceForge tracker?
> 
> I hope that someone will volunteer to update the various Windows 
> makefiles.

I will now trying to fix makefile.mgw.  Perhaps I will able to fix makefile.dj2.

Unfortunately I cannot treat other make files.

Regards

Tatsuro   

--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: makefile modification for canvas.trm for gnuplot windows, djgpp and so son

[Allin C. <cot...@wf...>]

On Thu, 26 Feb 2009, Ethan A Merritt wrote:

> On Wednesday 25 February 2009, Tatsuro MATSUOKA wrote:
>
> > The html page links to a javascript library 'canvastext.js'.
> > By default this is a link to a local file,usually in directory
> > /usr/local/share/gnuplot/<version>/js...
>
> I hope that someone will volunteer to update the various Windows
> makefiles.

It's inevitably going to be terrible pain to keep these up to
date.  Isn't there some way they could be auto-generated?

Allin Cottrell

Re: makefile modification for canvas.trm for gnuplot windows, djgpp and so son

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

On Wednesday 25 February 2009, Tatsuro MATSUOKA wrote:

> The html page links to a javascript library 'canvastext.js'. By default this is a link to a local
> file,usually in directory /usr/local/share/gnuplot/<version>/js.
> 
> seems to be effective for binaries generated through configure script.
> 
> Binaries generarted by directly through the platform dependent make file (e.g. makefile.mgw,
> makefile.dj2, and so on) seems to not be considered concerning the directry of 
> 
> 'canvastext.js'
> 
> I think that each makefile should be modified from this point
> 
> I have a look at canvas.trm
> 
> The below
> CANVAS_JSDIR
> CANVAS_ENH
> CANVAS_NOENH
> CANVAS_OTHER
> 
> should be defined in the makefile ? right
> 
> Can the 'CANVAS_JSDIR' be treat as that of GNUPLOT_PS_DIR?
> How other flags CANVAS_ENH, CANVAS_NOENH, CANVAS_OTHER be treated?

Could you please open a bug report on the SourceForge tracker?

I hope that someone will volunteer to update the various Windows 
makefiles.

	Ethan

-- 
Ethan A Merritt

makefile modification for canvas.trm for gnuplot windows, djgpp and so son

[Tatsuro M. <tma...@ya...>]

Hello

In the gnuplot help,

The default standalonemode creates an html page containing javascript code that renders the plot using
the HTML 5 canvas element.The html page links to a javascript library 'canvastext.js'.By default this
is a link to a local file,usually in directory /usr/local/share/gnuplot/<version>/js.You can change
this by using the jsdiroption to set the directory to either a local file or a general URL.The latter
is usually appropriate if the plot is exported for viewing on remote client machines.

are described.

The above description : 

The html page links to a javascript library 'canvastext.js'. By default this is a link to a local
file,usually in directory /usr/local/share/gnuplot/<version>/js.

seems to be effective for binaries generated through configure script.

Binaries generarted by directly through the platform dependent make file (e.g. makefile.mgw,
makefile.dj2, and so on) seems to not be considered concerning the directry of 

'canvastext.js'

I think that each makefile should be modified from this point

I have a look at canvas.trm

The below
CANVAS_JSDIR
CANVAS_ENH
CANVAS_NOENH
CANVAS_OTHER

should be defined in the makefile ? right

Can the 'CANVAS_JSDIR' be treat as that of GNUPLOT_PS_DIR?
How other flags CANVAS_ENH, CANVAS_NOENH, CANVAS_OTHER be treated?

Regards

Tatsuro 


--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: enhancing image capabilities of postscript terminal

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

On Wednesday 25 February 2009 12:58:43 Benjamin Lindner wrote:
> Hello,
> 
> I am trying to enhance the image capabilities of the postscript terminal.
> 
> I'd like to add basically two new features
>   *) compression of image data for the /FlateDecode filter as avilable 

That sounds quite reasonable.
Note that the PDF terminal already does this by default.

> in PS Level 3 (using libz)
>   *) Binary enconding of image data

I don't know enough to offer an opinion on the feasibility of that one.
Is that something that is commonly done in the PostScript world?

> The objective is to significantly reduce the size of the output file 
> with image data in it.
>
> So I wanted to ask the developers here, if such additions would be of 
> interest to be added to the gnuplot sources?
> 
> Implementing these features would require quite some changes in the 
> current postscript image code, in order to disentangle the three steps
>   1) pack image data in a bit-tight manner
>   2) (possibly) compress the packed data
>   3) encode the (possibly) compressed data
> which are currently done all-in-one in PS_encode_image()
> 
> So instead of throwing around with large patches, I'd thought I'd ask 
> beforehand ...
> 
> My idea would be to add new options to the postscript terminal
>   ) "level2" to set PS level to 2 (the current default), an alias of 
> "leveldefault"
>   ) "level3" to enable PS Level 3 related features
>   ) "imgcompression" to define whether to compress the image data 
> (currently only inflate/deflate)
>   ) "imgencoding" to define which method of encoding should be used 
> (hex, ascii85 or binary)
> 
> The default settings should resemble the current behaviour, i.e. "level2 
> imgcomression none imgencoding ascii85"
> 
> I could provide currently an implementation for inflate/deflate image 
> compression and binary image encoding. By changing the postscript image 
> code structure it should then be relatively easy to later add different 
> compression methods or encoding methods (if of interest)
> 
> comments?

A Flate option sounds perfectly reasonable to me.
Would further binary compression offer any advantage over simply
compressing the resulting file with gzip or bzip2 (or rar or pkzip or ...)?

No matter what you do, PostScript will remain a poor choice for
storing pixel images.

-- 
Ethan A Merritt

enhancing image capabilities of postscript terminal

[Benjamin L. <lin...@gm...>]

Hello,

I am trying to enhance the image capabilities of the postscript terminal.

I'd like to add basically two new features
  *) compression of image data for the /FlateDecode filter as avilable 
in PS Level 3 (using libz)
  *) Binary enconding of image data

The objective is to significantly reduce the size of the output file 
with image data in it.

So I wanted to ask the developers here, if such additions would be of 
interest to be added to the gnuplot sources?

Implementing these features would require quite some changes in the 
current postscript image code, in order to disentangle the three steps
  1) pack image data in a bit-tight manner
  2) (possibly) compress the packed data
  3) encode the (possibly) compressed data
which are currently done all-in-one in PS_encode_image()

So instead of throwing around with large patches, I'd thought I'd ask 
beforehand ...

My idea would be to add new options to the postscript terminal
  ) "level2" to set PS level to 2 (the current default), an alias of 
"leveldefault"
  ) "level3" to enable PS Level 3 related features
  ) "imgcompression" to define whether to compress the image data 
(currently only inflate/deflate)
  ) "imgencoding" to define which method of encoding should be used 
(hex, ascii85 or binary)

The default settings should resemble the current behaviour, i.e. "level2 
imgcomression none imgencoding ascii85"

I could provide currently an implementation for inflate/deflate image 
compression and binary image encoding. By changing the postscript image 
code structure it should then be relatively easy to later add different 
compression methods or encoding methods (if of interest)

comments?

benjamin

Re: png: selecting builtin font impossible?

[Manfred S. <man...@gm...>]

-------- Original-Nachricht --------
> Datum: Mon, 23 Feb 2009 13:48:11 -0800
> Von: Ethan Merritt <merritt@u.washington.edu>
> An: "Manfred Schwarb" <man...@gm...>
> CC: gnu...@li...
> Betreff: Re: png: selecting builtin font impossible?

> On Monday 23 February 2009 08:38:40 Manfred Schwarb wrote:
> > 
> > > On Monday 23 February 2009, Manfred Schwarb wrote:
> > > > 
> > > > 
> > > > 
> > > > Before 20080916, I get angle=90, TEXT_VERTICAL=90 for
> > > > the vertical label in my example and therefore we get into the
> > > > first case: x += t->v_char;
> > > > 
> > > > After this date, I get angle=0, TEXT_VERTICAL=-270, and
> > > > we fall into case 3: y -= t->v_char;
> > > 
> > > What terminal are you using, that seems to think an angle of
> > > -270 is different from an angle of 90?   The ones I have tested
> > > here do not seem to have any problem with it.
> > >  
> > > > I will stop tracing this issue now, I hope someone can
> > > > pursue this some further.
> > > 
> > > We'll need a simple script that demonstrates the bug,
> > > and a note on which terminal type is affected.
> > > 
> > 
> > Is the script I have added to an earlier email enough, or do you
> > want me to reduce it some more?
> > 
> > Terminal: as I stated, pngcairo is OK, I see this effect only
> > with libgd ("set term png"). I did not test any other terminals.
> 
> OK, considering only the png terminal (gd.trm) it seems there may
> be a bug in some versions of libgd that causes the text alignment
> to behave badly if the angular setting is outside the range 
> -180 < angle < 180.
> 
> The following patch may improve things:
> 
> --- gnuplot/term/gd.trm 2008-12-01 11:33:06.000000000 -0800
> +++ gnuplot-cvs/term/gd.trm     2009-02-23 13:38:40.000000000 -0800
> @@ -1672,6 +1677,8 @@ PNG_put_text(unsigned int x, unsigned in
>  TERM_PUBLIC int
>  PNG_text_angle(int ang)
>  {
> +    while (ang < -180) ang += 360;
> +    while (ang >  180) ang -= 360;
>      png_state.angle = ang;
>      return TRUE;
>  }
> 
> Please let me know if that fixes your problem or not.


Yes, this fixes it.

Thanks,
Manfred

> 
> 
> -- 
> Ethan A Merritt

-- 
Computer Bild Tarifsieger! GMX FreeDSL - Telefonanschluss + DSL
für nur 17,95 ¿/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a

Re: key positioning problem

[<pl...@pi...>]

Ethan Merritt wrote:
> On Monday 23 February 2009 10:14:03 pl...@pi... wrote:
>> Ethan A Merritt wrote:
>>> On Monday 23 February 2009, pl...@pi... wrote:
>>>> Ethan A Merritt wrote:
>>>>> Gnuplot does not do any font handling on its own. It leaves this
>>>>> to the individual external devices or libraries.  The corresponding
>>>>> drivers are supposed to provide approximate information about the
>>>>> average character width in the fields term->h_char, but the 
>>>>> approximation can be pretty terrible depending on what font you pick.
>>>>> And anyhow, at best it contains the estimated width of an "average"
>>>>> character.  In your case the titles are in all caps, and these are
>>>>> wider characters than average.
>>>> that gives some kind of manual work around which is helpful but all this
>>>> seems rather unsatisfactory in this day and age. Are there really none
>>>> of these terminals that can correctly return the space needed to render
>>>> a character string? X11 must surely be able to give that. I'd be a
>>>> little surprised if cairo can't.
>>> Sure. You could write a cairo-based graphics program, or a libgd-based
>>> graphics program, that queried the libraries for exact character widths.
>>> But gnuplot is not such a program.  The core gnuplot code is separate
>>> from, and independent of, individual terminal drivers.
>> So the code snippet I posted could go in the cairopng terminal , others
>> would have simliar code where it can be supported.
> 
> Huh?
> I don't understand at all.
> There is already similar code in various terminal drivers, called when
> a new font is selected. For example, this bit from gd.trm:
> 
>     /* Find approximate character width and height of selected TTF font */
>     if (png_state.ttffont) {
>         int brect[8];
>         char *err;
>         err = gdImageStringFT(NULL, &brect[0], 0,
>                 png_state.ttffont, (double)png_state.ttfsize,
>                 0.0, 0, 0, "f00000000g");
>         if (!err) {
>             term->h_char = .11 * (float)(brect[2] - brect[0]) + 0.5;
>             term->v_char = 1.1 * (float)(brect[1] - brect[7]) + 0.5;
>         }
> 
> But there is no framework in place for the core code to invoke this for
> individual strings, nor make use of the result.  You would need to design
> such a framework.
> 

I thought I just did. If you don't understand maybe you missed what I
posted or I did not explain it clearly enough.


>>>> While separating out the rendering detail into different terminals has
>>>> advantages it should not end up reducing things to a lowest common
>>>> denominator. If some terminals can correctly calculate text extents it
>>>> would be nice to use that capability.
>>> So far as I can see, that would require major restructing of the program.
>>> If you want to work on it, I suggest that the first step is to block out
>>> what such a restructuring would look like.  Remember that some of the
>>> most capable terminal drivers, e.g. PostScript and svg, cannot know about
>>> font metrics at the time gnuplot is running.  How would you take that into
>>> account?
>>>
>> Well that's what I meant about not going for lowest common demoninator.
>> It does not make sense to limit all output to monochrome because some
>> terminals can't handle colour.
>>
>> Each terminal's capabilities are known.
>>
>> To take advantage of this capability, instead of relying on h_char and
>> v_char, it would need a new function like term_get_text_extent() . Those
>> that can't handle it return a zero or other flag and the main core code
>> calls the existing output. If a valid text extent is returned it gets used.
>>
>> That does not sound like a major rewrite. Probably a couple of lines in
>> core to clean up key formatting plus the extra function added to the
>> terminal interface.
>>
>> Maybe even svg and ps could provide a better estimation in this context.
> 
> I look forward to any code you care to prototype.
> 
> 

I don't know what you meant by framework if it was not that: a new
function in the terminal interface that can deliver the true text extent
of a given string as and when needed.

Each terminal capable of delivering a precise text extent will implement
its own low level function, eg. png_text_extent() , those that can't
will return a value indicating they can't.

Now, the key output in the core code can determine the correct text
extent where possible, where not it will fall back to the existing code
based on h_char.

Is that what you mean by a framework? does that approach make sense?

/Peter.

Re: png: selecting builtin font impossible?

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

On Monday 23 February 2009 08:38:40 Manfred Schwarb wrote:
> 
> > On Monday 23 February 2009, Manfred Schwarb wrote:
> > > 
> > > 
> > > 
> > > Before 20080916, I get angle=90, TEXT_VERTICAL=90 for
> > > the vertical label in my example and therefore we get into the
> > > first case: x += t->v_char;
> > > 
> > > After this date, I get angle=0, TEXT_VERTICAL=-270, and
> > > we fall into case 3: y -= t->v_char;
> > 
> > What terminal are you using, that seems to think an angle of
> > -270 is different from an angle of 90?   The ones I have tested
> > here do not seem to have any problem with it.
> >  
> > > I will stop tracing this issue now, I hope someone can
> > > pursue this some further.
> > 
> > We'll need a simple script that demonstrates the bug,
> > and a note on which terminal type is affected.
> > 
> 
> Is the script I have added to an earlier email enough, or do you
> want me to reduce it some more?
> 
> Terminal: as I stated, pngcairo is OK, I see this effect only
> with libgd ("set term png"). I did not test any other terminals.

OK, considering only the png terminal (gd.trm) it seems there may
be a bug in some versions of libgd that causes the text alignment
to behave badly if the angular setting is outside the range 
-180 < angle < 180.

The following patch may improve things:

--- gnuplot/term/gd.trm 2008-12-01 11:33:06.000000000 -0800
+++ gnuplot-cvs/term/gd.trm     2009-02-23 13:38:40.000000000 -0800
@@ -1672,6 +1677,8 @@ PNG_put_text(unsigned int x, unsigned in
 TERM_PUBLIC int
 PNG_text_angle(int ang)
 {
+    while (ang < -180) ang += 360;
+    while (ang >  180) ang -= 360;
     png_state.angle = ang;
     return TRUE;
 }

Please let me know if that fixes your problem or not.


-- 
Ethan A Merritt

Re: key positioning problem

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

On Monday 23 February 2009 13:37:22 pl...@pi... wrote:
> Ethan Merritt wrote:
> > On Monday 23 February 2009 10:14:03 pl...@pi... wrote:
> >> Ethan A Merritt wrote:
> >>> On Monday 23 February 2009, pl...@pi... wrote:
> >>>> Ethan A Merritt wrote:
> >>>>> Gnuplot does not do any font handling on its own. It leaves this
> >>>>> to the individual external devices or libraries.  The corresponding
> >>>>> drivers are supposed to provide approximate information about the
> >>>>> average character width in the fields term->h_char, but the 
> >>>>> approximation can be pretty terrible depending on what font you pick.
> >>>>> And anyhow, at best it contains the estimated width of an "average"
> >>>>> character.  In your case the titles are in all caps, and these are
> >>>>> wider characters than average.
> >>>> that gives some kind of manual work around which is helpful but all this
> >>>> seems rather unsatisfactory in this day and age. Are there really none
> >>>> of these terminals that can correctly return the space needed to render
> >>>> a character string? X11 must surely be able to give that. I'd be a
> >>>> little surprised if cairo can't.
> >>> Sure. You could write a cairo-based graphics program, or a libgd-based
> >>> graphics program, that queried the libraries for exact character widths.
> >>> But gnuplot is not such a program.  The core gnuplot code is separate
> >>> from, and independent of, individual terminal drivers.
> >> So the code snippet I posted could go in the cairopng terminal , others
> >> would have simliar code where it can be supported.
> > 
> > Huh?
> > I don't understand at all.
> > There is already similar code in various terminal drivers, called when
> > a new font is selected. For example, this bit from gd.trm:
> > 
> >     /* Find approximate character width and height of selected TTF font */
> >     if (png_state.ttffont) {
> >         int brect[8];
> >         char *err;
> >         err = gdImageStringFT(NULL, &brect[0], 0,
> >                 png_state.ttffont, (double)png_state.ttfsize,
> >                 0.0, 0, 0, "f00000000g");
> >         if (!err) {
> >             term->h_char = .11 * (float)(brect[2] - brect[0]) + 0.5;
> >             term->v_char = 1.1 * (float)(brect[1] - brect[7]) + 0.5;
> >         }
> > 
> > But there is no framework in place for the core code to invoke this for
> > individual strings, nor make use of the result.  You would need to design
> > such a framework.
> > 
> 
> I thought I just did. If you don't understand maybe you missed what I
> posted or I did not explain it clearly enough.
> 
> 
> >>>> While separating out the rendering detail into different terminals has
> >>>> advantages it should not end up reducing things to a lowest common
> >>>> denominator. If some terminals can correctly calculate text extents it
> >>>> would be nice to use that capability.
> >>> So far as I can see, that would require major restructing of the program.
> >>> If you want to work on it, I suggest that the first step is to block out
> >>> what such a restructuring would look like.  Remember that some of the
> >>> most capable terminal drivers, e.g. PostScript and svg, cannot know about
> >>> font metrics at the time gnuplot is running.  How would you take that into
> >>> account?
> >>>
> >> Well that's what I meant about not going for lowest common demoninator.
> >> It does not make sense to limit all output to monochrome because some
> >> terminals can't handle colour.
> >>
> >> Each terminal's capabilities are known.
> >>
> >> To take advantage of this capability, instead of relying on h_char and
> >> v_char, it would need a new function like term_get_text_extent() . Those
> >> that can't handle it return a zero or other flag and the main core code
> >> calls the existing output. If a valid text extent is returned it gets used.
> >>
> >> That does not sound like a major rewrite. Probably a couple of lines in
> >> core to clean up key formatting plus the extra function added to the
> >> terminal interface.
> >>
> >> Maybe even svg and ps could provide a better estimation in this context.
> > 
> > I look forward to any code you care to prototype.
> > 
> > 
> 
> I don't know what you meant by framework if it was not that: a new
> function in the terminal interface that can deliver the true text extent
> of a given string as and when needed.
> Each terminal capable of delivering a precise text extent will implement
> its own low level function, eg. png_text_extent() , those that can't
> will return a value indicating they can't.
> 
> Now, the key output in the core code can determine the correct text
> extent where possible, where not it will fall back to the existing code
> based on h_char.
> 
> Is that what you mean by a framework? does that approach make sense?

I agree that individual terminals could implement such a routine for
single fragments of text.  That has been discussed before.  But that only
gets you so far. 

What I meant by "framework" was a plan for how the core code would make
such a request and then make use of the result.  Enhanced text mode is
particularly problematic. You can wave your hands and say you will add
code everywhere that is needed, but where exactly is that?

Ideally you would create some single routine that would mediate calls to
the new terminal function, so it only has to be maintained in one place in
the code. Better yet would be if it could replace some existing single
piece of code. I suppose the starting point would be the routine
estimate_strlen() in term.c.  I looked into this once and decided that
it would be too difficult.  But maybe you will have a cleverer idea than I did.

Just how many terminals do you think could possibly support this?
Are cairo and gd the only ones?   If so, I am not sure it is worth doing,
because my guess is that the people who would care the most are the ones
who are going for publication-quality output.  And they are most likely
using one of the terminals based on PostScript or LaTeX, for which I see
no hope of making this work.


-- 
Ethan A Merritt

Re: key positioning problem

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

On Monday 23 February 2009 10:14:03 pl...@pi... wrote:
> Ethan A Merritt wrote:
> > On Monday 23 February 2009, pl...@pi... wrote:
> >> Ethan A Merritt wrote:
> >>> Gnuplot does not do any font handling on its own. It leaves this
> >>> to the individual external devices or libraries.  The corresponding
> >>> drivers are supposed to provide approximate information about the
> >>> average character width in the fields term->h_char, but the 
> >>> approximation can be pretty terrible depending on what font you pick.
> >>> And anyhow, at best it contains the estimated width of an "average"
> >>> character.  In your case the titles are in all caps, and these are
> >>> wider characters than average.
> >> that gives some kind of manual work around which is helpful but all this
> >> seems rather unsatisfactory in this day and age. Are there really none
> >> of these terminals that can correctly return the space needed to render
> >> a character string? X11 must surely be able to give that. I'd be a
> >> little surprised if cairo can't.
> > 
> > Sure. You could write a cairo-based graphics program, or a libgd-based
> > graphics program, that queried the libraries for exact character widths.
> > But gnuplot is not such a program.  The core gnuplot code is separate
> > from, and independent of, individual terminal drivers.
> 
> So the code snippet I posted could go in the cairopng terminal , others
> would have simliar code where it can be supported.

Huh?
I don't understand at all.
There is already similar code in various terminal drivers, called when
a new font is selected. For example, this bit from gd.trm:

    /* Find approximate character width and height of selected TTF font */
    if (png_state.ttffont) {
        int brect[8];
        char *err;
        err = gdImageStringFT(NULL, &brect[0], 0,
                png_state.ttffont, (double)png_state.ttfsize,
                0.0, 0, 0, "f00000000g");
        if (!err) {
            term->h_char = .11 * (float)(brect[2] - brect[0]) + 0.5;
            term->v_char = 1.1 * (float)(brect[1] - brect[7]) + 0.5;
        }

But there is no framework in place for the core code to invoke this for
individual strings, nor make use of the result.  You would need to design
such a framework.

> >> While separating out the rendering detail into different terminals has
> >> advantages it should not end up reducing things to a lowest common
> >> denominator. If some terminals can correctly calculate text extents it
> >> would be nice to use that capability.
> > 
> > So far as I can see, that would require major restructing of the program.
> > If you want to work on it, I suggest that the first step is to block out
> > what such a restructuring would look like.  Remember that some of the
> > most capable terminal drivers, e.g. PostScript and svg, cannot know about
> > font metrics at the time gnuplot is running.  How would you take that into
> > account?
> > 
> 
> Well that's what I meant about not going for lowest common demoninator.
> It does not make sense to limit all output to monochrome because some
> terminals can't handle colour.
> 
> Each terminal's capabilities are known.
> 
> To take advantage of this capability, instead of relying on h_char and
> v_char, it would need a new function like term_get_text_extent() . Those
> that can't handle it return a zero or other flag and the main core code
> calls the existing output. If a valid text extent is returned it gets used.
> 
> That does not sound like a major rewrite. Probably a couple of lines in
> core to clean up key formatting plus the extra function added to the
> terminal interface.
> 
> Maybe even svg and ps could provide a better estimation in this context.

I look forward to any code you care to prototype.


-- 
Ethan A Merritt

Re: key positioning problem

[<pl...@pi...>]

Ethan A Merritt wrote:
> On Monday 23 February 2009, pl...@pi... wrote:
>> Ethan A Merritt wrote:
>>> Gnuplot does not do any font handling on its own. It leaves this
>>> to the individual external devices or libraries.  The corresponding
>>> drivers are supposed to provide approximate information about the
>>> average character width in the fields term->h_char, but the 
>>> approximation can be pretty terrible depending on what font you pick.
>>> And anyhow, at best it contains the estimated width of an "average"
>>> character.  In your case the titles are in all caps, and these are
>>> wider characters than average.
>> that gives some kind of manual work around which is helpful but all this
>> seems rather unsatisfactory in this day and age. Are there really none
>> of these terminals that can correctly return the space needed to render
>> a character string? X11 must surely be able to give that. I'd be a
>> little surprised if cairo can't.
> 
> Sure. You could write a cairo-based graphics program, or a libgd-based
> graphics program, that queried the libraries for exact character widths.
> But gnuplot is not such a program.  The core gnuplot code is separate
> from, and independent of, individual terminal drivers.

So the code snippet I posted could go in the cairopng terminal , others
would have simliar code where it can be supported.

> 
>> While separating out the rendering detail into different terminals has
>> advantages it should not end up reducing things to a lowest common
>> denominator. If some terminals can correctly calculate text extents it
>> would be nice to use that capability.
> 
> So far as I can see, that would require major restructing of the program.
> If you want to work on it, I suggest that the first step is to block out
> what such a restructuring would look like.  Remember that some of the
> most capable terminal drivers, e.g. PostScript and svg, cannot know about
> font metrics at the time gnuplot is running.  How would you take that into
> account?
> 

Well that's what I meant about not going for lowest common demoninator.
It does not make sense to limit all output to monochrome because some
terminals can't handle colour.

Each terminal's capabilities are known.

To take advantage of this capability, instead of relying on h_char and
v_char, it would need a new function like term_get_text_extent() . Those
that can't handle it return a zero or other flag and the main core code
calls the existing output. If a valid text extent is returned it gets used.

That does not sound like a major rewrite. Probably a couple of lines in
core to clean up key formatting plus the extra function added to the
terminal interface.

Maybe even svg and ps could provide a better estimation in this context.

/Peter.

Re: png: selecting builtin font impossible?

[Manfred S. <man...@gm...>]

> On Monday 23 February 2009, Manfred Schwarb wrote:
> > 
> > 
> > 
> > Before 20080916, I get angle=90, TEXT_VERTICAL=90 for
> > the vertical label in my example and therefore we get into the
> > first case: x += t->v_char;
> > 
> > After this date, I get angle=0, TEXT_VERTICAL=-270, and
> > we fall into case 3: y -= t->v_char;
> 
> What terminal are you using, that seems to think an angle of
> -270 is different from an angle of 90?   The ones I have tested
> here do not seem to have any problem with it.
>  
> > I will stop tracing this issue now, I hope someone can
> > pursue this some further.
> 
> We'll need a simple script that demonstrates the bug,
> and a note on which terminal type is affected.
> 

Is the script I have added to an earlier email enough, or do you
want me to reduce it some more?

Terminal: as I stated, pngcairo is OK, I see this effect only
with libgd ("set term png"). I did not test any other terminals.


Manfred



> -- 
> Ethan A Merritt

-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01

Re: png: selecting builtin font impossible?

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

On Monday 23 February 2009, Manfred Schwarb wrote:
> 
> 
> 
> Before 20080916, I get angle=90, TEXT_VERTICAL=90 for
> the vertical label in my example and therefore we get into the
> first case: x += t->v_char;
> 
> After this date, I get angle=0, TEXT_VERTICAL=-270, and
> we fall into case 3: y -= t->v_char;

What terminal are you using, that seems to think an angle of
-270 is different from an angle of 90?   The ones I have tested
here do not seem to have any problem with it.
 
> I will stop tracing this issue now, I hope someone can
> pursue this some further.

We'll need a simple script that demonstrates the bug,
and a note on which terminal type is affected.

-- 
Ethan A Merritt

Re: key positioning problem

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

On Monday 23 February 2009, pl...@pi... wrote:
> Ethan A Merritt wrote:
> > 
> > Gnuplot does not do any font handling on its own. It leaves this
> > to the individual external devices or libraries.  The corresponding
> > drivers are supposed to provide approximate information about the
> > average character width in the fields term->h_char, but the 
> > approximation can be pretty terrible depending on what font you pick.
> > And anyhow, at best it contains the estimated width of an "average"
> > character.  In your case the titles are in all caps, and these are
> > wider characters than average.
> 
> that gives some kind of manual work around which is helpful but all this
> seems rather unsatisfactory in this day and age. Are there really none
> of these terminals that can correctly return the space needed to render
> a character string? X11 must surely be able to give that. I'd be a
> little surprised if cairo can't.

Sure. You could write a cairo-based graphics program, or a libgd-based
graphics program, that queried the libraries for exact character widths.
But gnuplot is not such a program.  The core gnuplot code is separate
from, and independent of, individual terminal drivers.

> While separating out the rendering detail into different terminals has
> advantages it should not end up reducing things to a lowest common
> denominator. If some terminals can correctly calculate text extents it
> would be nice to use that capability.

So far as I can see, that would require major restructing of the program.
If you want to work on it, I suggest that the first step is to block out
what such a restructuring would look like.  Remember that some of the
most capable terminal drivers, e.g. PostScript and svg, cannot know about
font metrics at the time gnuplot is running.  How would you take that into
account?

-- 
Ethan A Merritt

Re: png: selecting builtin font impossible?

[Manfred S. <man...@gm...>]

<snip>

> > > It seems clear to me from inspection of the "bad" ttf rotated text
> that
> > > the rotation angle is not truly 90.  Without seeing the command that
> > > generated this text, I cannot say why that would happen.
> > > 
> > > It is true that when you rotate text to an arbitrary angle, then the
> > > characters become somewhat distorted.  Then again, with the builtin
> fonts
> > > you cannot rotate text to arbitrary angles at all.
> > >  
> > 
> > 
> > I figured there are 2 separate issues:
> > 
> > 1) bad rendering which optically results skewed color gradients:
> >    This is purely my own fault, as the thing is a multiplot and
> >    with each additional "plot" command all label commands were 
> >    executed, which resulted in multiple overlaying labels. 
> >    And the labels seem to be additive in the color space, with the
> >    obvious result.
> >    I.e. I simply forgot to add some "unset label" commands after the
> >    "plot" command.
> >    Hmmm, actually an implicit "unset label" after every plot command
> >    would be more intuitive. And it is probably almost mandatory
> >    to "unset label" after an plot command, at least I don't see
> >    at the moment any usage of these already plotted labels after the
> >    "plot" command.
> > 
> > 
> > 2) As you correctly noted, the strings are somewhat slanted. This only
> >    happens with libgd, in cairo mode things are OK. And this issue
> >    is something different from issue 1).
> >    Interestingly this seems to happen only with recent gnuplot versions.
> >    I found a gnuplot 4.3 version of December 2007 on my disk, and this
> >    version does correct rendering, although it uses the very same
> >    shared libraries (i.e. same libgd.so) as the recent cvs-versions
> >    which show this strange slanting.
> >    The slanting only occurs in vertical orientation, horizontal strings
> >    are always OK.
> > 
> >    I will try to investigate this a bit further over the weekend, but at
> >    the moment I'm a bit clueless.
> > 
> >    A script which shows this issue (probably it could be reduced even
> >    more):
> > 
> > set encoding iso_8859_1
> > 
> > #set term pngcairo font 'arial,12' size 900,960
> > #set term png truecolor small size 900,960
> > set term png truecolor font 'arial,12' size 900,960
> > set out "demo.png"
> > 
> > set multiplot
> > set label "DEMO" at screen 0.5,0.98 center font "large"
> > set lmargin screen 0.1
> > set rmargin screen (1.0-0.1)
> > set tmargin screen (1.0-0.0708333-0.234375-0.0791667*4.0)
> > set bmargin screen (1.0-0.0708333-0.234375-0.0791667*5.0)
> > 
> > yoff=(1.0-0.0708333-0.234375-0.0791667*4.5)
> > set label "Atmosphärenquerschnitt [hPa]" at screen
> > (0.1-6.0*0.0133333),yoff \
> >   center rotate textcolor lt -1
> > plot [0:180][-15:10] sin(x) notitle with lines lc rgb "#A0A0A0"
> > 
> > unset multiplot
> > set output
> > 
> > 
> 
> 
> I did some binary search, an I got
> 20080915 good
> 20080916 bad
> 
> the offending patch is:
> 
> --- term.c	2008/09/07 04:13:02	1.179
> +++ term.c	2008/09/16 05:35:25	1.180
> @@ -1,5 +1,5 @@
>  #ifndef lint
> -static char *RCSid() { return RCSid("$Id: term.c,v 1.179 2008/09/07
> 04:13:02 sfeam Exp $"); }
> +static char *RCSid() { return RCSid("$Id: term.c,v 1.180 2008/09/16
> 05:35:25 sfeam Exp $"); }
>  #endif
>  
>  /* GNUPLOT - term.c */
> @@ -995,9 +995,9 @@
>  		    (*t->put_text) (x - fix, y, text);
>  	    }
>  	}
> -	if (angle == TEXT_VERTICAL)
> +	if (angle == 90 || angle == TEXT_VERTICAL)
>  	    x += t->v_char;
> -	else if (-angle == TEXT_VERTICAL)
> +	else if (angle == -90 || angle == -TEXT_VERTICAL)
>  	    x -= t->v_char;
>  	else
>  	    y -= t->v_char;
> 
> 
> 

Baa, I missed a hunk of this commit, here it is:

--- term_api.h	2008/07/09 16:39:50	1.74
+++ term_api.h	2008/09/16 05:35:25	1.75
@@ -1,5 +1,5 @@
 /*
- * $Id: term_api.h,v 1.74 2008/07/09 16:39:50 mikulik Exp $
+ * $Id: term_api.h,v 1.75 2008/09/16 05:35:25 sfeam Exp $
  */
 
 /* GNUPLOT - term_api.h */
@@ -59,9 +59,10 @@
 #define LT_DEFAULT    (-7)
 
 /* Constant value passed to (term->text_angle)(ang) to generate vertical
- * text. Current implementation has ang equal to rotation in degrees.
+ * text corresponding to old keyword "rotate", which produced the equivalent
+ * of "rotate by 90 right-justified".
  */
-#define TEXT_VERTICAL (90)
+#define TEXT_VERTICAL (-270)
 
 
 /* Type definitions */



Before 20080916, I get angle=90, TEXT_VERTICAL=90 for
the vertical label in my example and therefore we get into the
first case: x += t->v_char;

After this date, I get angle=0, TEXT_VERTICAL=-270, and
we fall into case 3: y -= t->v_char;


I will stop tracing this issue now, I hope someone can
pursue this some further.


Cheers,
Manfred

<snip>

-- 
Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL 
für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a

Re: key positioning problem

[<pl...@pi...>]

Ethan A Merritt wrote:
> On Sunday 22 February 2009, Allin Cottrell wrote:
>> Problem: with both the png (libgd) and cairopng terminals,
>> depending on the font selected the gnuplot "key" may overflow the
>> plot data region (even if the key terms are in no way excessive,
>> e.g. n <= 8 characters per term).
> 
> Gnuplot does not do any font handling on its own. It leaves this
> to the individual external devices or libraries.  The corresponding
> drivers are supposed to provide approximate information about the
> average character width in the fields term->h_char, but the 
> approximation can be pretty terrible depending on what font you pick.
> And anyhow, at best it contains the estimated width of an "average"
> character.  In your case the titles are in all caps, and these are
> wider characters than average.
> 
> So if you think that the png terminals *always* underestimate the
> font width, then you could multiply term->h_char by some constant
> everywhere that it is set in the driver.  But I find it more likely
> that some font widths will be underestimated and others will be
> overestimated, and there is not much we can do about it.
> 
> In other words,  I don't think this is fixable. 
> Not for png, and not for any other terminal unless it is using a
> monospaced font and correctly reports the corresponding fixed width.
> 
> This is why there are fudge factors for the key layout, so that you
> can tweak the layout if the automated estimation is failing.
> In the example you give, it is sufficient to reserve a little extra width:
> 
>   set key width 2
> 

Hi,

that gives some kind of manual work around which is helpful but all this
seems rather unsatisfactory in this day and age. Are there really none
of these terminals that can correctly return the space needed to render
a character string? X11 must surely be able to give that. I'd be a
little surprised if cairo can't.

A little googling came up with this which , on the face of it , seems to
be doing just that in order to produce rendered text for http images.

http://www.aeracode.org/2007/12/15/django-and-cairo-rendering-pretty-titles/

surface = cairo.ImageSurface(cairo.FORMAT_ARGB32, 1, 1)
context = cairo.Context(surface)
context.select_font_face(font, style, weight)
context.set_font_size(size)
width, height = context.text_extents(text)[2:4]

While separating out the rendering detail into different terminals has
advantages it should not end up reducing things to a lowest common
denominator. If some terminals can correctly calculate text extents it
would be nice to use that capability.

/Peter.


> 
>> Example:
>> set term pngcairo font "FreeSans,8" size 680,400
>> set output 'test.png'
>> set key left top
>> plot x title "PRIME" w lines , \
>>  2*x title "UNEMP" w lines
>>
>> In the resulting plot, the 'U' of "UNEMP" is vertically bisected
>> by the y axis.  The desired result is that all the key text
>> appears within the data area (i.e. to the right of the y axis);
>> and this is achieved if we change the first line of the plot file
>> to (for example)
>>
>> set term pngcairo font "Vera,8" size 680,400
>>
>> I'd be happy to try to work up a patch for this, but I'm having
>> difficulty figuring out where to start -- i.e., determining where
>> the left limit of the key block is computed, given the selected
>> font.
>>
>> P.S., on further investigation this does not seems to be very
>> terminal-specific: I'm getting the same issue with the pdf,
>> pdfcairo, and 'post eps' terminal types.
> 

makefile.mgw : Is not it necesary to add cp comand for js files?

[Tatsuro M. <tma...@ya...>]

Hello

Is not it necesary to add

GNUPLOT_JS_DIR

and 

cp ../term/js/*.* $(DESTDIR)/$(GNUPLOT_JS_DIR) ?

install: default
	mkdir -p $(DESTDIR)
	cp gnuplot.exe $(DESTDIR)/gnuplot.exe
	cp wgnuplot.exe $(DESTDIR)/wgnuplot.exe
	cp wgnuplot_pipes.exe $(DESTDIR)/wgnuplot_pipes.exe
	cp pgnuplot.exe $(DESTDIR)/pgnuplot.exe
	cp win/wgnuplot.mnu $(DESTDIR)/wgnuplot.mnu
	cp wgnuplot.hlp $(DESTDIR)/wgnuplot.hlp
	mkdir -p $(DESTDIR)/share/PostScript
	cp ../term/PostScript/*.ps $(DESTDIR)/$(GNUPLOT_PS_DIR)
	cp ../term/js/*.* $(DESTDIR)/$(GNUPLOT_JS_DIR) # <===Here!!

Regards

Tatsuro　

--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Enhanced text mode for the new HTML canvas terminal

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

I have added enhanced text support to the HTML canvas terminal
and created an alternative font file
	canvasmath.js
that extends the basic ascii character set in canvastext.js by 
adding Greek letters and math symbols.  
See, for example

  http://skuld.bmsc.washington.edu/~merritt/gnuplot/canvas_demos/approximate.html
  http://skuld.bmsc.washington.edu/~merritt/gnuplot/canvas_demos/enhanced_utf8.html

All characters are accessible using UTF-8 encoding.
I had to choose some set of characters to include, since including
absolutely everything would make for a very large file.
The current set is here:

  http://skuld.bmsc.washington.edu/~merritt/gnuplot/canvas_demos/utf8.html

If you notice a missing character that should be included, please speak up.
It's just a matter of hunting it down in the poorly-indexed Hershey font set.

-- 
Ethan A Merritt

Re: key positioning problem

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

On Sunday 22 February 2009, Allin Cottrell wrote:
> Problem: with both the png (libgd) and cairopng terminals,
> depending on the font selected the gnuplot "key" may overflow the
> plot data region (even if the key terms are in no way excessive,
> e.g. n <= 8 characters per term).

Gnuplot does not do any font handling on its own. It leaves this
to the individual external devices or libraries.  The corresponding
drivers are supposed to provide approximate information about the
average character width in the fields term->h_char, but the 
approximation can be pretty terrible depending on what font you pick.
And anyhow, at best it contains the estimated width of an "average"
character.  In your case the titles are in all caps, and these are
wider characters than average.

So if you think that the png terminals *always* underestimate the
font width, then you could multiply term->h_char by some constant
everywhere that it is set in the driver.  But I find it more likely
that some font widths will be underestimated and others will be
overestimated, and there is not much we can do about it.

In other words,  I don't think this is fixable. 
Not for png, and not for any other terminal unless it is using a
monospaced font and correctly reports the corresponding fixed width.

This is why there are fudge factors for the key layout, so that you
can tweak the layout if the automated estimation is failing.
In the example you give, it is sufficient to reserve a little extra width:

  set key width 2


> Example:
> set term pngcairo font "FreeSans,8" size 680,400
> set output 'test.png'
> set key left top
> plot x title "PRIME" w lines , \
>  2*x title "UNEMP" w lines
> 
> In the resulting plot, the 'U' of "UNEMP" is vertically bisected
> by the y axis.  The desired result is that all the key text
> appears within the data area (i.e. to the right of the y axis);
> and this is achieved if we change the first line of the plot file
> to (for example)
> 
> set term pngcairo font "Vera,8" size 680,400
> 
> I'd be happy to try to work up a patch for this, but I'm having
> difficulty figuring out where to start -- i.e., determining where
> the left limit of the key block is computed, given the selected
> font.
> 
> P.S., on further investigation this does not seems to be very
> terminal-specific: I'm getting the same issue with the pdf,
> pdfcairo, and 'post eps' terminal types.

-- 
Ethan A Merritt

key positioning problem

[Allin C. <cot...@wf...>]

Problem: with both the png (libgd) and cairopng terminals,
depending on the font selected the gnuplot "key" may overflow the
plot data region (even if the key terms are in no way excessive,
e.g. n <= 8 characters per term).

Example:
set term pngcairo font "FreeSans,8" size 680,400
set output 'test.png'
set key left top
plot x title "PRIME" w lines , \
 2*x title "UNEMP" w lines

In the resulting plot, the 'U' of "UNEMP" is vertically bisected
by the y axis.  The desired result is that all the key text
appears within the data area (i.e. to the right of the y axis);
and this is achieved if we change the first line of the plot file
to (for example)

set term pngcairo font "Vera,8" size 680,400

I'd be happy to try to work up a patch for this, but I'm having
difficulty figuring out where to start -- i.e., determining where
the left limit of the key block is computed, given the selected
font.

P.S., on further investigation this does not seems to be very
terminal-specific: I'm getting the same issue with the pdf,
pdfcairo, and 'post eps' terminal types.

-- 
Allin Cottrell
Department of Economics
Wake Forest University

recursive definition

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

shige 02/23 2009
----------------

The demo script demo/approximate.dem is the sample for the 
'filledcurve' and the pseudofile '+'. This treats the Taylor 
approximation of sin(x) and it defines them explicitly as

 approx_1(x) = x - x**3/6
 approx_2(x) = x - x**3/6 + x**5/120 
 approx_3(x) = x - x**3/6 + x**5/120 - x**7/5040

For the "Approximation demo", there is another way to define it 
by the recursive definition:

 set title "Taylor polynomial approximation of sin(x)"
 set zeroaxis
 # f(x,n) = (-1)^{n-1}*x^{2*n-1}/(2*n-1)!
 f(x,n) = (n>1)? (-f(x,n-1)*x*x/((2.0*n-1.0)*(2.0*n-2.0))) : x
 # sum_of_f(x,n) = f(x,1) + f(x,2) + ... + f(x,n)
 sum_of_f(x,n) = (n>0)? sum_of_f(x,n-1) + f(x,n) : 0
 plot [-8:8][-2:2] for [n=1:5] sum_of_f(x,n) \
  title sprintf("degree %d",2*n-1), sin(x)

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