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

Re: flickering "allocating colors ..." message

[Ethan A M. <sf...@us...>]

On Wednesday, April 20, 2011 12:18:20 pm Daniel J Sebald wrote:
> 1)  Get rid of the note about "allocating colors..." if it is no longer 
> necessary.  (And search for any other similar notes...of which I doubt 
> there are any.)
> 

There are several others, but they are wrapped in:

#ifdef TITLE_BAR_DRAWING_MSG
... print annoying message ...
#endif

Let's do the same with this one.

Re: flickering "allocating colors ..." message

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

On 04/18/2011 05:50 AM, albert_a wrote:
>
> Hi All, I have experienced a problem on Octave painting dynamic signal in
> graphics window using plot(..) function.
> Octave uses Gnuplot as a back-end.
> Everything is fine except the window caption.
> Two titles compete all the time "Figure 1" and "Figure 1: allocating colors
> ...".
> This makes very irritating flickering effect.

I'm guessing that you are using Octave in a "real-time" fashion to 
monitor some data signal, i.e., refreshing the plot often.  Is this right?

The reason for the note about "allocating colors" was that for large 
palettes the color map could take a while to create and one might be 
left wondering what gnuplot was doing.  On the other hand, there has 
been a lot of development with palettes and it may be the case now that 
doesn't take so long.  I do recall writing some things that refresh 
palettes, etc. only when necessary.  Perhaps we should review that with 
some demos to see what the behavior of "allocating colors..." is like. 
If for large palettes it only is present for a fraction of a second or 
to a couple seconds, it makes no sense in having it.


> The problem resides in the file 'gplt_x11.c' line 3563 in the Gnuplot
> source.
> I have commented out the code that produces "allocating colors ..." message
> and recompiled Gnuplot.
> My appeal: Could Gnuplot developers find a better workaround to this
> problem.

Consider yourself a low ranking developer, I guess.  People can submit 
patches to the gnuplot SourceForge project.  But let's talk about the 
options:

1)  Get rid of the note about "allocating colors..." if it is no longer 
necessary.  (And search for any other similar notes...of which I doubt 
there are any.)

2)  If the palette is large (above 2048?) then indicate "allocating 
colors...", otherwise do not.

3)  If the user specifies a window title for the x11 plot, then do not 
append "allocating colors..." in any case.

Tell us something about your application Albert.  Are you working with a 
small enough palette that there is little delay between refresh, such 
that 2 above would solve things?  I think Octave has (or should have at 
this point) the ability to control the window title now.

Dan

Re: recent build breakage

[Hans-Bernhard B. <HBB...@t-...>]

On 18.04.2011 21:18, Hans-Bernhard Bröker wrote:
> On 18.04.2011 19:09, sfeam (Ethan Merritt) wrote:
>
>> I have updated the source tree using "cvs update -d", and yes there is a file
>> windows/doc2html.c in my starting source. The problem is that the new subdirectory
>> does not get included in the build package.
>
> I'm on it.  config/Makefile.am.in probably needs updating, too.

docs mostly works now.  The build check performed as part of distcheck 
now breaks at 'texi2dvi' (on Cygwin).

Re: recent build breakage

[Hans-Bernhard B. <HBB...@t-...>]

On 18.04.2011 19:09, sfeam (Ethan Merritt) wrote:

> I have updated the source tree using "cvs update -d", and yes there is a file
> windows/doc2html.c in my starting source. The problem is that the new subdirectory
> does not get included in the build package.

I'm on it.  config/Makefile.am.in probably needs updating, too.

recent build breakage

[sfeam (E. Merritt) <eam...@gm...>]

The rearrangement of windows documentation seems to have broken the
build scripts.  Here's what I get from "make distcheck"

make[2]: Entering directory `/home/merritt/cvs/gnuplot-cvs/gnuplot-4.5/_build/docs'
make[2]: *** No rule to make target `windows/doc2html.c', needed by `distdir'.  Stop.
make[2]: Leaving directory `/home/merritt/cvs/gnuplot-cvs/gnuplot-4.5/_build/docs'
make[1]: *** [distdir] Error 1
make[1]: Leaving directory `/home/merritt/cvs/gnuplot-cvs/gnuplot-4.5/_build'
make: *** [distcheck] Error 1

I have updated the source tree using "cvs update -d", and yes there is a file 
windows/doc2html.c in my starting source. The problem is that the new subdirectory
does not get included in the build package.

Makefile.in instead refers to a non-existent directory  .../docs/wxhelp
although it doesn't try to include this directory in the build package either.

So which is it - .../docs/windows or .../docs/wxhelp?   Or both?
In any case, the Makefile needs to be updated to know about this
new directory structure.

	Ethan

flickering "allocating colors ..." message

[albert_a <aaa...@ya...>]

Hi All, I have experienced a problem on Octave painting dynamic signal in
graphics window using plot(..) function.
Octave uses Gnuplot as a back-end.
Everything is fine except the window caption.
Two titles compete all the time "Figure 1" and "Figure 1: allocating colors
...".
This makes very irritating flickering effect.
The problem resides in the file 'gplt_x11.c' line 3563 in the Gnuplot
source.
I have commented out the code that produces "allocating colors ..." message
and recompiled Gnuplot.
My appeal: Could Gnuplot developers find a better workaround to this
problem.

-- 
View this message in context: http://old.nabble.com/flickering-%22allocating-colors-...%22-message-tp31422727p31422727.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: build files

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

Am 11.04.2011 11:26, schrieb Petr Mikulik:
>> Those have more recent versions, which build out-of-tree. But they may still be in use:
>>
>>    config/
>>    makefile.cyg: Cygwin, superseded by config/cygwin/Makefile
>>    makefile.mgw: MinGW, superseded by config/mingw/Makefile
>>    makefile.wc, config.wc, config.oww: Watcom, superseded by config/watcom/*
>
> I wonder about creation of the 3 new directores config/mingw/,
> config/cygwin/, config/watcom/ ... but not for all other makefiles. Until
> now all makefiles, including unixish ./configure + make, put all .o into
> src/, and nobody complains.
>
> Thus, either all supported makefiles should get their own directory, or no
> one.

Agreed. I am volunteering to update makefile.nt accordingly. I could
also provide a Visual C++ project file, if there's any interest.

I would like to stress that in my opinion out-of-tree builds are really
a worthwhile feature. This is especially true on Windows, where gnuplot
currently supports (at least) four different build systems (MinGW,
OpenWatcom, Visual C++ and Cygwin). Having each built in its own
directory makes life a lot easier.

  Bastian

Re: <DEL> revisited

[Hans-Bernhard B. <HBB...@t-...>]

On 13.04.2011 01:48, Ethan A Merritt wrote:
> New bug report on the tracker:
>     #3285571
>     Win32 binary on Windows 7 64-bit
>     crash program whenever hit "del" key at on new command line
>
> I seem to recall recent discussion that something, somewhere,
> was mis-interpreting<del>  as ^D.    Where was that?

Right here on the mailing list, unless memory fails me badly.

> Has it already been fixed?

I believe we concluded that this was working as designed, i.e. nothing 
broken, thus nothing to fix.

You added a bit to the docs about Ctrl-D yourself (gnuplot.doc, 2011-03-20).

Re: buggy rotation of non-scalable font

[Ethan A M. <sf...@us...>]

pl...@pi... wrote >
> Hi Ethan,
> 
> Thanks for sharing your deep understanding of all this and providing the 
> patch.
> 
> Gentoo devs have been very responsive and that patch is already in thier 
> ebuild system. (By default it is configured with the fontconfig option )
> 
> *however*,  even after a full reboot, if I unset GDFONTPATH I still get 
> the font fallback just as before.

I don't know whether the configuration layout is the same on Gentoo,
but on my systems the key thing in order for fontconfig to work
is to create and customize this file:

[1] cat /etc/fonts/local.conf
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
<dir>/home/local/share/ttfonts</dir>
</fontconfig>

	cheers,

		Ethan

Re: buggy rotation of non-scalable font

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

On 04/12/11 20:29, Ethan A Merritt wrote:
> On Tuesday, April 12, 2011 11:06:31 am pl...@pi... wrote:
>> On 04/12/11 19:02, Ethan Merritt wrote:
>>> On Tuesday, April 12, 2011 01:28:26 am pl...@pi... wrote:
>>>> Hi,
>>>>
>>>> I just tried outputting to png terminal and it failed to find a scalable
>>>> font. I have not found out why yet, but I don't recall this error last
>>>> time I did this a few months back.
>>>
>>> Sounds like a problem with libgd.
>>> Check your environmental variable GDFONTPATH.
>>
>> Correct , that is not set but apparently that was not needed a month or
>> so ago.
>>
>> My Xorg.0.log shows this, so clearly the fonts are available.
>
> No. That's a misunderstanding.
> libgd doesn't use X11 for anything.  It works perfectly well
> on a machine with no X font server at all (e.g. Windows).
> So the settings in Xorg are not relevant.
>
>> So is this a change in xorg, gdlib or the way I'm using gnuplot?
>>
>> Exporting GDFONTPATH fixed it but  I don't quite see why it is now
>> necessary to clutter my env even further .
>
> In versions of libgd through (I think) 2.0.34, the environmental variable
> was the only way to control font paths.  In 2.0.35 there is a second mechanism
> possible, using the fontconfig utility.   Shige Takeno added a fallback mechanism
> to gnuplot in Sep 2010 such that if no font is found using GDFONTPATH then
> it makes a second try using fontconfig.  But it's hard to see how that would
> explain your case.  In principle the difference should be that the new method
> has two chances to get it right, whereas before it only had one chance.
>
> Caveat:  It's slightly more complicated than that due to a bug in the
> released version of libgd 2.0.35/36.  If you want to try recompiling libgd,
> the patch is here:
> --- gd-2.0.36/gdft.c    2008-03-09 16:05:52.000000000 -0700
> +++ gd-2.0.36-mod/gdft.c        2009-05-20 20:22:13.000000000 -0700
> @@ -1661,7 +1661,7 @@ static char * font_path(char **fontpath,
>   BGD_DECLARE(int) gdFTUseFontConfig(int flag)
>   {
>   #ifdef HAVE_LIBFONTCONFIG
> -       fontConfigFlag = 1;
> +       fontConfigFlag = flag;
>          return 1;
>   #else
>          return 0;
>
> If your copy of libgd came via a linux distribution, it is possible that this
> patch has already been applied.  It's been circulating for a couple of years.
>
> But really the "normal" way of setting a font path for libgd is GDFONTPATH or,
> if you have a development version of libgd (2.0.36+ or 2.1.0) then your can
> alternatively use fontconfig.
>
> 	Ethan
>
>
>
>
>
>
>
>>
>>>
>>>> gnuplot>   load "foo.gnu
>>>> Could not find/open font when opening font "arial", using internal
>>>> non-scalable font
>>>>
>>>>
>>>> However, the result of this is text misplacement.
>>>>
>>>> set xtics out nomirror  rotate by -45
>>>>
>>>> Now it seems that 45-rotation is not possible with whatever font it
>>>> substituted but what it did output was the tick label going straight
>>>> upwards from the origin (close to the tick mark) where the rotated text
>>>> would have started.
>>>>
>>>> There seem to be two problems here.
>>>>
>>>> 1/ rotate -45 should slope down to the right. Here it IS rotated but +90
>>>> , no rotation or -90 would be a better fall-back.
>>>>
>>>> 2/ if it does rotate up the origin is totally wrong (ie not recalculated
>>>> for the actual rotation) and dumps all over the plot area.
>>>>
>>>>
>>>> My guess from the behaviour is that the actual rotation is a bug rather
>>>> than a fall-back , or at least a buggy fall-back.
>>>
>>> The fonts internal to libgd are non-rotatable, although the orientation of
>>> the pixel array can be transposed to give +/- 90 degree orientation.
>>> Given that rotatable fonts (ttf, otf, pfa, etc) are ubiquitous these days,
>>> I don't think it's worth much effort trying to figure out which emergency
>>> fallback orientation of a non-rotatable font is least wrong.
>>>
>>>> This was running std release version 4.2.2
>>>
>>> If that's not a typo for 4.4.2, you're talking about a ~5 year old version.
>>> No further releases in the 4.2 series are likely to happen,
>>> so bug reports should be made against 4.4 or 4.5.
>>
>> Yes , dyslexia rules, K.O !!
>>
>> regards. Peter.
>>
>>>
>>> 	Ethan
>>>
>>>
>>>>
>>>> regards. Peter.
>>>>
>>
>>
>
>

Hi Ethan,

Thanks for sharing your deep understanding of all this and providing the 
patch.

Gentoo devs have been very responsive and that patch is already in thier 
ebuild system. (By default it is configured with the fontconfig option )

*however*,  even after a full reboot, if I unset GDFONTPATH I still get 
the font fallback just as before.


:?

<DEL> revisited

[Ethan A M. <sf...@us...>]

New bug report on the tracker:
   #3285571
   Win32 binary on Windows 7 64-bit
   crash program whenever hit "del" key at on new command line

I seem to recall recent discussion that something, somewhere,
was mis-interpreting <del> as ^D.    Where was that?
Has it already been fixed?  

Re: buggy rotation of non-scalable font

[Ethan A M. <sf...@us...>]

On Tuesday, April 12, 2011 11:06:31 am pl...@pi... wrote:
> On 04/12/11 19:02, Ethan Merritt wrote:
> > On Tuesday, April 12, 2011 01:28:26 am pl...@pi... wrote:
> >> Hi,
> >>
> >> I just tried outputting to png terminal and it failed to find a scalable
> >> font. I have not found out why yet, but I don't recall this error last
> >> time I did this a few months back.
> >
> > Sounds like a problem with libgd.
> > Check your environmental variable GDFONTPATH.
> 
> Correct , that is not set but apparently that was not needed a month or 
> so ago.
> 
> My Xorg.0.log shows this, so clearly the fonts are available.

No. That's a misunderstanding.
libgd doesn't use X11 for anything.  It works perfectly well
on a machine with no X font server at all (e.g. Windows).
So the settings in Xorg are not relevant.

> So is this a change in xorg, gdlib or the way I'm using gnuplot?
> 
> Exporting GDFONTPATH fixed it but  I don't quite see why it is now 
> necessary to clutter my env even further .

In versions of libgd through (I think) 2.0.34, the environmental variable
was the only way to control font paths.  In 2.0.35 there is a second mechanism
possible, using the fontconfig utility.   Shige Takeno added a fallback mechanism
to gnuplot in Sep 2010 such that if no font is found using GDFONTPATH then
it makes a second try using fontconfig.  But it's hard to see how that would
explain your case.  In principle the difference should be that the new method
has two chances to get it right, whereas before it only had one chance.

Caveat:  It's slightly more complicated than that due to a bug in the 
released version of libgd 2.0.35/36.  If you want to try recompiling libgd,
the patch is here:
--- gd-2.0.36/gdft.c    2008-03-09 16:05:52.000000000 -0700
+++ gd-2.0.36-mod/gdft.c        2009-05-20 20:22:13.000000000 -0700
@@ -1661,7 +1661,7 @@ static char * font_path(char **fontpath,
 BGD_DECLARE(int) gdFTUseFontConfig(int flag)
 {
 #ifdef HAVE_LIBFONTCONFIG
-       fontConfigFlag = 1;
+       fontConfigFlag = flag;
        return 1;
 #else
        return 0;

If your copy of libgd came via a linux distribution, it is possible that this
patch has already been applied.  It's been circulating for a couple of years.

But really the "normal" way of setting a font path for libgd is GDFONTPATH or,
if you have a development version of libgd (2.0.36+ or 2.1.0) then your can
alternatively use fontconfig.

	Ethan






 
> 
> >
> >> gnuplot>  load "foo.gnu
> >> Could not find/open font when opening font "arial", using internal
> >> non-scalable font
> >>
> >>
> >> However, the result of this is text misplacement.
> >>
> >> set xtics out nomirror  rotate by -45
> >>
> >> Now it seems that 45-rotation is not possible with whatever font it
> >> substituted but what it did output was the tick label going straight
> >> upwards from the origin (close to the tick mark) where the rotated text
> >> would have started.
> >>
> >> There seem to be two problems here.
> >>
> >> 1/ rotate -45 should slope down to the right. Here it IS rotated but +90
> >> , no rotation or -90 would be a better fall-back.
> >>
> >> 2/ if it does rotate up the origin is totally wrong (ie not recalculated
> >> for the actual rotation) and dumps all over the plot area.
> >>
> >>
> >> My guess from the behaviour is that the actual rotation is a bug rather
> >> than a fall-back , or at least a buggy fall-back.
> >
> > The fonts internal to libgd are non-rotatable, although the orientation of
> > the pixel array can be transposed to give +/- 90 degree orientation.
> > Given that rotatable fonts (ttf, otf, pfa, etc) are ubiquitous these days,
> > I don't think it's worth much effort trying to figure out which emergency
> > fallback orientation of a non-rotatable font is least wrong.
> >
> >> This was running std release version 4.2.2
> >
> > If that's not a typo for 4.4.2, you're talking about a ~5 year old version.
> > No further releases in the 4.2 series are likely to happen,
> > so bug reports should be made against 4.4 or 4.5.
> 
> Yes , dyslexia rules, K.O !!
> 
> regards. Peter.
> 
> >
> > 	Ethan
> >
> >
> >>
> >> regards. Peter.
> >>
> 
> 

Re: buggy rotation of non-scalable font

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

On 04/12/11 19:02, Ethan Merritt wrote:
> On Tuesday, April 12, 2011 01:28:26 am pl...@pi... wrote:
>> Hi,
>>
>> I just tried outputting to png terminal and it failed to find a scalable
>> font. I have not found out why yet, but I don't recall this error last
>> time I did this a few months back.
>
> Sounds like a problem with libgd.
> Check your environmental variable GDFONTPATH.

Correct , that is not set but apparently that was not needed a month or 
so ago.

My Xorg.0.log shows this, so clearly the fonts are available.

[  1665.111] (**) FontPath set to:
   /usr/share/fonts/corefonts,
   /usr/share/fonts/100dpi:unscaled,
   /usr/share/fonts/75dpi:unscaled,
   /usr/share/fonts/TTF,

ls   /usr/share/fonts/corefonts/arial* -l
-rw-r--r-- 1 root root 286620 Jun 29  2010 
/usr/share/fonts/corefonts/arialbd.ttf
-rw-r--r-- 1 root root 224692 Jun 29  2010 
/usr/share/fonts/corefonts/arialbi.ttf
-rw-r--r-- 1 root root 206132 Jun 29  2010 
/usr/share/fonts/corefonts/ariali.ttf
-rw-r--r-- 1 root root 275572 Jun 29  2010 
/usr/share/fonts/corefonts/arial.ttf

So is this a change in xorg, gdlib or the way I'm using gnuplot?

Exporting GDFONTPATH fixed it but  I don't quite see why it is now 
necessary to clutter my env even further .


>
>> gnuplot>  load "foo.gnu
>> Could not find/open font when opening font "arial", using internal
>> non-scalable font
>>
>>
>> However, the result of this is text misplacement.
>>
>> set xtics out nomirror  rotate by -45
>>
>> Now it seems that 45-rotation is not possible with whatever font it
>> substituted but what it did output was the tick label going straight
>> upwards from the origin (close to the tick mark) where the rotated text
>> would have started.
>>
>> There seem to be two problems here.
>>
>> 1/ rotate -45 should slope down to the right. Here it IS rotated but +90
>> , no rotation or -90 would be a better fall-back.
>>
>> 2/ if it does rotate up the origin is totally wrong (ie not recalculated
>> for the actual rotation) and dumps all over the plot area.
>>
>>
>> My guess from the behaviour is that the actual rotation is a bug rather
>> than a fall-back , or at least a buggy fall-back.
>
> The fonts internal to libgd are non-rotatable, although the orientation of
> the pixel array can be transposed to give +/- 90 degree orientation.
> Given that rotatable fonts (ttf, otf, pfa, etc) are ubiquitous these days,
> I don't think it's worth much effort trying to figure out which emergency
> fallback orientation of a non-rotatable font is least wrong.
>
>> This was running std release version 4.2.2
>
> If that's not a typo for 4.4.2, you're talking about a ~5 year old version.
> No further releases in the 4.2 series are likely to happen,
> so bug reports should be made against 4.4 or 4.5.

Yes , dyslexia rules, K.O !!

regards. Peter.

>
> 	Ethan
>
>
>>
>> regards. Peter.
>>

Re: buggy rotation of non-scalable font

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

On Tuesday, April 12, 2011 01:28:26 am pl...@pi... wrote:
> Hi,
> 
> I just tried outputting to png terminal and it failed to find a scalable
> font. I have not found out why yet, but I don't recall this error last
> time I did this a few months back.

Sounds like a problem with libgd.  
Check your environmental variable GDFONTPATH.

> gnuplot> load "foo.gnu
> Could not find/open font when opening font "arial", using internal
> non-scalable font
> 
> 
> However, the result of this is text misplacement.
> 
> set xtics out nomirror  rotate by -45
> 
> Now it seems that 45-rotation is not possible with whatever font it
> substituted but what it did output was the tick label going straight
> upwards from the origin (close to the tick mark) where the rotated text
> would have started.
> 
> There seem to be two problems here.
> 
> 1/ rotate -45 should slope down to the right. Here it IS rotated but +90
> , no rotation or -90 would be a better fall-back.
> 
> 2/ if it does rotate up the origin is totally wrong (ie not recalculated
> for the actual rotation) and dumps all over the plot area.
> 
> 
> My guess from the behaviour is that the actual rotation is a bug rather
> than a fall-back , or at least a buggy fall-back.

The fonts internal to libgd are non-rotatable, although the orientation of
the pixel array can be transposed to give +/- 90 degree orientation.
Given that rotatable fonts (ttf, otf, pfa, etc) are ubiquitous these days,
I don't think it's worth much effort trying to figure out which emergency
fallback orientation of a non-rotatable font is least wrong. 

> This was running std release version 4.2.2

If that's not a typo for 4.4.2, you're talking about a ~5 year old version.
No further releases in the 4.2 series are likely to happen, 
so bug reports should be made against 4.4 or 4.5.

	Ethan


> 
> regards. Peter.
> 
> ------------------------------------------------------------------------------
> Forrester Wave Report - Recovery time is now measured in hours and minutes
> not days. Key insights are discussed in the 2010 Forrester Wave Report as
> part of an in-depth evaluation of disaster recovery service providers.
> Forrester found the best-in-class provider in terms of services and vision.
> Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
University of Washington, Seattle 98195-7742

Re: build files

[Ethan A M. <sf...@us...>]

On Tuesday, April 12, 2011 07:25:37 am Bastian Märkisch wrote:
> >
> > Btw. is there anyone who knows about the status of the Zortech (aka Digital Mars)
> > compiler support (makefile.ztc)? (There are also a few terminals
> > which require this compiler...)
> >
> 
> The Zortech (Digital Mars) only drivers in fg.trm (hercules, egamono, egalib, vgalib, vgamono, svgalib, ssvgalib) rely on a library named "Flash Graphics".

Zortech may well be dead, but note
  hercules - also supported by pc.trm
  vgalib - supported by linux.trm and ggi.trm
  svgalib - supported by ggi.trm

> I just checked the Digital Mars Forum at http://www.digitalmars.com/d/archives/c++/dos/32-bits/417.html
> There - and in other threads - I found the following statement:
> 
> "Flash Graphics was the graphics package for DOSX. Unfortunately, the authors of it have chosen to no longer make it available. There's nothing I can do about it."
> 
> The oldest such statement I could find is dated Jul 31 2003. This is probably an indication that the Digital Mars compiler has not been used to compile gnuplot since then. So I propose to remove the drivers and the support for the Zortech compiler (#idef __ZTC__).

Removing fg.trm, makefile.ztc, and code conditional on _ZTC_ sounds fine.

vgalib/svgalib are definitely still in use via the linux and ggi terminals.
hercules - I don't know. Is pc.trm also a candidate for removal?

	Ethan

Re: build files

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

>
> Btw. is there anyone who knows about the status of the Zortech (aka Digital Mars)
> compiler support (makefile.ztc)? (There are also a few terminals
> which require this compiler...)
>

The Zortech (Digital Mars) only drivers in fg.trm (hercules, egamono, egalib, vgalib, vgamono, svgalib, ssvgalib) rely on a library named "Flash Graphics".

I just checked the Digital Mars Forum at http://www.digitalmars.com/d/archives/c++/dos/32-bits/417.html
There - and in other threads - I found the following statement:

"Flash Graphics was the graphics package for DOSX. Unfortunately, the authors of it have chosen to no longer make it available. There's nothing I can do about it."

The oldest such statement I could find is dated Jul 31 2003. This is probably an indication that the Digital Mars compiler has not been used to compile gnuplot since then. So I propose to remove the drivers and the support for the Zortech compiler (#idef __ZTC__).
 
  Bastian

buggy rotation of non-scalable font

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

Hi,

I just tried outputting to png terminal and it failed to find a scalable
font. I have not found out why yet, but I don't recall this error last
time I did this a few months back.

gnuplot> load "foo.gnu
Could not find/open font when opening font "arial", using internal
non-scalable font


However, the result of this is text misplacement.

set xtics out nomirror  rotate by -45

Now it seems that 45-rotation is not possible with whatever font it
substituted but what it did output was the tick label going straight
upwards from the origin (close to the tick mark) where the rotated text
would have started.

There seem to be two problems here.

1/ rotate -45 should slope down to the right. Here it IS rotated but +90
, no rotation or -90 would be a better fall-back.

2/ if it does rotate up the origin is totally wrong (ie not recalculated
for the actual rotation) and dumps all over the plot area.


My guess from the behaviour is that the actual rotation is a bug rather
than a fall-back , or at least a buggy fall-back.


This was running std release version 4.2.2

regards. Peter.

Re: build files

[Hans-Bernhard B. <HBB...@t-...>]

On 11.04.2011 11:26, Petr Mikulik wrote:

> I wonder about creation of the 3 new directores config/mingw/,
> config/cygwin/, config/watcom/ ... but not for all other makefiles. Until
> now all makefiles, including unixish ./configure + make, put all .o into
> src/, and nobody complains.

I complained, by doing something about it.  If you're going to use the 
same source tree with multiple compilers, it's quite important that none 
of them clutters up the source tree itself.

And actually no, the autoconf build does not have to do that, either. 
It's quite standard procedure to build outside the source tree, i.e.

	cd /some/where/gnuplot
	[ -d cygwin ] || mkdir cygwin
	cd cygwin
	../configure && make install

It's wasteful to rebuild the entire program from scratch each time you 
switch target platform (think of an actual heterogeneous Unix 
environment with different hardware platforms, different OSes and 
compilers in play), just because the source is cluttered with object files.

Re: Revised SVG terminal supports mouse interaction

[Ethan A M. <sf...@us...>]

On Monday, April 11, 2011 12:09:19 am pl...@pi... wrote:

> Anyway , thanks for the extra effort on SVG, especially the mouse 
> coords, that is one thing I wanted to work on but never had time.
> 
> Does that give x1,x2,y1,y2 coords like the wxt terminal ?

At present it is echoing x1 y1 directly to the current mouse position.
You can see how it works at the demo page.  For polar mode plots it
instead echos the polar coordinates.  

I wasted a lot of time trying to make it write the coordinates to 
a separate optional HTML element as the canvas terminal does.  In the
end I concluded that there is no portable way to do this, if it is
even possible at all. 

An alternative that I did not pursue would be to reserve space at the
bottom of each SVG figure where mousing information is written, similar
to what you get on the x11 or wxt displays.  I don't actually like that
as well as either of the other two approaches, but it should be possible.

Someone with more SVG smarts than I could probably improve the
appearance of the mouse readout in the current scheme.  For instance,
it can be hard to read the coordinates when they appear on top of
a complicated plot or a filled area in a dark color.  There must be
some way to assign a background color to the bounding region of the
text, but I didn't figure out how.

Also it would be nice to allow a mouse click to leave the current
coordinates printed on the figure, as the other mousing terminals do.
I think I know how to do that, but I didn't work on it.


	Ethan

> 
> regards, Peter.

Re: build files

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

> Those have more recent versions, which build out-of-tree. But they may still be in use:
> 
>   config/
>   makefile.cyg: Cygwin, superseded by config/cygwin/Makefile
>   makefile.mgw: MinGW, superseded by config/mingw/Makefile
>   makefile.wc, config.wc, config.oww: Watcom, superseded by config/watcom/*

I wonder about creation of the 3 new directores config/mingw/, 
config/cygwin/, config/watcom/ ... but not for all other makefiles. Until 
now all makefiles, including unixish ./configure + make, put all .o into 
src/, and nobody complains.

Thus, either all supported makefiles should get their own directory, or no 
one.


BTW, other no longer updated files, are:

1.  makefile.g 

2.  makefile.unx
  It says it is for:
  # GNUPLOT 3.0 Makefile (Unix X11 support) for
  #  Apollo/Sun/Dec5000/IBM-RS6000/HP9000/SGI/3B1/386IX/Cray

3. makefile.vms
  Does gnuplot 4.x compiled under VMS?

---
PM

Re: Revised SVG terminal supports mouse interaction

[Mojca M. <moj...@gm...>]

On Mon, Apr 11, 2011 at 09:09,  <pl...@pi...> wrote:
>
> re the adblocker.  Though this special URI is a bit of an odd format it

It looks exactly the same as Java libraries to me. (It doesn't have to
be a valid URL, it just needs to be unique library indentifier.)

> looks like there's some client ID in there. My guess is that will be
> sufficient for someone having access to the attribution of these IDs to
> identify the "owner" of the apple licence on which this is running.
>
> Do I understand from Mojca's comment that this feature is there by
> default and active or is this like firefox add-ons that the user choses
> to install?

I probably installed it manually one day (and more or less forgot
about it). It is quite possible that there is a bug in addblocker, so
I wouldn't worry about the problem that I reported unless other people
observe it as well. (I'm not going to reinstall Safari. It is bad
enough that I cannot print anything since the 10.6.7 update, I don't
want to mess with the system even more.)

Mojca

Re: Revised SVG terminal supports mouse interaction

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

On 10/04/11 21:39, Mojca Miklavec wrote:
> On Sun, Apr 10, 2011 at 21:20, sfeam (Ethan Merritt) wrote:
>>
>> So the bottom line is still that SVG support in the various browsers
>> is unreliable.
>
> I thought that was clear from the beginning. It is not so much SVG as
> JavaScript though.
>
> When Taco was porting MetaPost output to SVG, he complained that no
> single SVG editor (including the most popular ones) was able to deal
> with most common situations (like figure origin not being at (0,0),
> but also many others).
>
>> Does Safari have a javascript error console?  If so, you might
>> find a message that hints at the cause of the lines/points problem.
>
> There is one. I first get:
>
> <table>  is not allowed inside<tbody>. Closing the current<table>  and
> inserting the new<table>  as a sibling. (dashcolor.html:98)
>
> and then all the following lines seem to come from
>      safari-extension://com.betafish.adblockforsafari-UAMUU4S2D9/dee0fbbe/jquery/jquery-1.4.2.min.js
> so maybe it would work without the addblocker. I'm only not sure how
> to disable the blocker in a reliable way.
>
> Mojca

Hi,

firstly thanks for the renewed interest in this feature, it's been a 
while since I submitted those original patches so I need to reload this 
from (mental) backup storage.


<OT>

re the adblocker.  Though this special URI is a bit of an odd format it 
looks like there's some client ID in there. My guess is that will be 
sufficient for someone having access to the attribution of these IDs to 
identify the "owner" of the apple licence on which this is running.

Do I understand from Mojca's comment that this feature is there by 
default and active or is this like firefox add-ons that the user choses 
to install?

Form http://safariadblock.com/update.plist

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
     <key>Extension Updates</key>
     <array>
         <dict>
             <key>CFBundleIdentifier</key>
             <string>com.betafish.adblockforsafari</string>
             <key>Developer Identifier</key>
             <string>UAMUU4S2D9</string>
             <key>CFBundleShortVersionString</key>
             <string>2.3.22</string>
             <key>CFBundleVersion</key>
             <string>102.3.22</string>
             <key>URL</key>
 
<string>http://safariadblock.com/AdBlockForSafari.safariextz</string>
         </dict>
     </array>
</dict>
</plist>
>

So it looks like part of it is "Developer Identifier" , the only google 
hit on "dee0fbbe" is an archive of this thread , so it looks like that 
may be a "user ID. "

Jquery looks a bit like a SQL lookup. Are they checking a database of 
known ads ? I would appear to be accessing betafish.com rather than a 
list local to the browser.

Just curious.
</OT>


Anyway , thanks for the extra effort on SVG, especially the mouse 
coords, that is one thing I wanted to work on but never had time.

Does that give x1,x2,y1,y2 coords like the wxt terminal ?

regards, Peter.

Re: build files

[sfeam (E. Merritt) <eam...@gm...>]

On Sunday, April 10, 2011, Bastian Märkisch wrote:
> Several build files in /config and /src/win/ are a bit outdated. I therefore propose to remove the following files from CVS. Please let me know what you think.

 > No longer supported platforms:
> 
>   config/
>   config.amg: Amiga
>   makefile.msc: Microsoft C v5: 16bit DOS compiler
>   makefile.msw: Microsoft C v7: 16bit Windows compiler
>   makefile.tc: Borland Turbo C++ v3: 16bit DOS compiler
>   makefile.win: Borland C++: 16/32bit Windows (see comment below)
>   term.pc.h: Intended for 16bit DOS.

I see no reason to keep files needed only for Amiga and 16-bit DOS.
These may have been overlooked in the general cleanup, or perhaps
it was unclear whether the 16/32bit Borland files were still useful.

I don't know enough to offer an opinion about the other files listed below.

	Ethan
   


>   src/win/
>   wgnupl32.def, wgnuplib.def: no longer required for Win32 builds




> 
> Those have more recent versions, which build out-of-tree. But they may still be in use:
> 
>   config/
>   makefile.cyg: Cygwin, superseded by config/cygwin/Makefile
>   makefile.mgw: MinGW, superseded by config/mingw/Makefile
>   makefile.wc, config.wc, config.oww: Watcom, superseded by config/watcom/*
> 
> Btw. is there anyone who knows about the status of the Zortech (aka Digital Mars) compiler support (makefile.ztc)? (There are also a few terminals which require this compiler...)
> 
> I do have a (sort of) working updated version of makefile.win, which supports the freely available Borland C++ 5.5 for Win32 builds. gnuplot  builds extremely fast with it. But it crashes when I try to plot something and there doesn't seem to be a debugger available. AFAIK, it does also not support 'long long', which is needed by gnuplot's binary datafile support. We should probably drop support for it, too.
> 
>   Bastian
> 

build files

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

Several build files in /config and /src/win/ are a bit outdated. I therefore propose to remove the following files from CVS. Please let me know what you think.

No longer supported platforms:

  config/
  config.amg: Amiga
  makefile.msc: Microsoft C v5: 16bit DOS compiler
  makefile.msw: Microsoft C v7: 16bit Windows compiler
  makefile.tc: Borland Turbo C++ v3: 16bit DOS compiler
  makefile.win: Borland C++: 16/32bit Windows (see comment below)
  term.pc.h: Intended for 16bit DOS.

  src/win/
  wgnupl32.def, wgnuplib.def: no longer required for Win32 builds

Those have more recent versions, which build out-of-tree. But they may still be in use:

  config/
  makefile.cyg: Cygwin, superseded by config/cygwin/Makefile
  makefile.mgw: MinGW, superseded by config/mingw/Makefile
  makefile.wc, config.wc, config.oww: Watcom, superseded by config/watcom/*

Btw. is there anyone who knows about the status of the Zortech (aka Digital Mars) compiler support (makefile.ztc)? (There are also a few terminals which require this compiler...)

I do have a (sort of) working updated version of makefile.win, which supports the freely available Borland C++ 5.5 for Win32 builds. gnuplot  builds extremely fast with it. But it crashes when I try to plot something and there doesn't seem to be a debugger available. AFAIK, it does also not support 'long long', which is needed by gnuplot's binary datafile support. We should probably drop support for it, too.

  Bastian

Re: Revised SVG terminal supports mouse interaction

[Mojca M. <moj...@gm...>]

On Sun, Apr 10, 2011 at 21:20, sfeam (Ethan Merritt) wrote:
>
> So the bottom line is still that SVG support in the various browsers
> is unreliable.

I thought that was clear from the beginning. It is not so much SVG as
JavaScript though.

When Taco was porting MetaPost output to SVG, he complained that no
single SVG editor (including the most popular ones) was able to deal
with most common situations (like figure origin not being at (0,0),
but also many others).

> Does Safari have a javascript error console?  If so, you might
> find a message that hints at the cause of the lines/points problem.

There is one. I first get:

<table> is not allowed inside <tbody>. Closing the current <table> and
inserting the new <table> as a sibling. (dashcolor.html:98)

and then all the following lines seem to come from
    safari-extension://com.betafish.adblockforsafari-UAMUU4S2D9/dee0fbbe/jquery/jquery-1.4.2.min.js
so maybe it would work without the addblocker. I'm only not sure how
to disable the blocker in a reliable way.

Mojca