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

Re: extending pstricks terminal driver

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

On Thu, Dec 18, 2008 at 11:40 AM, Mojca Miklavec  wrote:
>
>> I get mixed results.
>> For instance, in processing transparent.dem it handles
>> μ (\mu) correctly, but throws an error on σ (\sigma).
>
> That's up to TeX, not up to the terminal.

I wanted to say: I don't consider it broken if σ fails to work and I
would not try to convert that to \sigma. When compiling the document
with XeTeX or when loading the right macros, σ should work just fine.

Mojca

Re: extending pstricks terminal driver

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

On Thu, Dec 18, 2008 at 7:02 AM, Ethan A Merritt wrote:
>
> I have another question from testing:
>
> Is it supposed to handle UTF8 characters?

Yes, to a certain extent.

> I get mixed results.
> For instance, in processing transparent.dem it handles
> μ (\mu) correctly, but throws an error on σ (\sigma).

That's up to TeX, not up to the terminal. The terminal should not
modify input (at least in my opinion). Users are supposed to either
use the right package in TeX to hadle the encoding or use whatever
character or command that works in TeX.

If one uses XeTeX, UTF-8 should work out-of-the-box. In pdflatex there
are several packages to handle UTF-8, but maybe they work slightly
differently.

Mojca

Re: extending pstricks terminal driver

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

On Wednesday 10 December 2008, Juergen Wieferink wrote:
> 
> Having an autoconfiscated version would really help in testing.

It's there now.  Let me know if it should go into CVS proper.

I have another question from testing:

Is it supposed to handle UTF8 characters?  I get mixed results.
For instance, in processing transparent.dem it handles
μ (\mu) correctly, but throws an error on σ (\sigma).

-- 
Ethan A Merritt

Re: extending pstricks terminal driver

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

I've uploaded a patchset to SourceForge that places the current contents
of your tarball into .../term/lua/ and .../term/,
and modifies thethe autoconf scripts to configure and install with no
additional intervention.

Comments:

- ./configure currently installs gnuplot-lua-tikz.sty to
/usr/local/share/gnuplot/<version>/ but of course TeX doesn't know to look
for it there.  Where is the proper place to install this style file?

- Tested using TeXLive:  
  pdflatex works great. dvi output is still useless. 

- dvips partially works, and may be fixable. It places 90% of the plot
  off the bottom of the page, and then clips it so you can't recover
  even by editing the BoundingBox.

- Tested using texmf:
  Works fine using pdflatex except that I had to hunt for a copy of
  ifxetex.sty

- I have not touched the code in lua.trm, but it needs a pass to remove
  these warnings:
  ../term/lua.trm:132: warning: ISO C90 forbids mixed declarations and code
  ../term/lua.trm:190: warning: ISO C90 forbids mixed declarations and code
  ../term/lua.trm:532: warning: implicit declaration of function ‘luaL_openlibs’
  ../term/lua.trm:533: warning: implicit declaration of function ‘luaopen_debug’
  ../term/lua.trm:561: warning: ISO C90 forbids mixed declarations and code
  ../term/lua.trm:1023: warning: ISO C90 forbids mixed declarations and code
  ../term/lua.trm:125: warning: ‘LUA_stack_dump’ defined but not used

- set term lua should accept at least the following options:
    size XX, YY    # units of inches or cm
    dashed/solid
    color/monochrome
  and it needs to echo back the options string to the user to confirm it
  was accepted

But that's all minor stuff, and can be fixed up after the code goes into
cvs.

What do you think - should the whole lot go into cvs more or less
immediately?


-- 
Ethan A Merritt

Re: gd.trm issue for mingw-gcc-4.3.0 building

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

Hello Ethan A Merritt

cc. Petr Mikulik  and Pierre Joye

Considering that the libfontconfig is not required for previous version of libgd and iconv is optional
for libdgd-2.0.36RC1, I have considered the following patch to  makefile.mgw. 

Regards

Tatsuro


*** makefile.mgw.orig	Tue Nov 25 16:46:59 2008
--- makefile.mgw	Thu Dec 18 09:03:32 2008
***************
*** 47,56 ****
  # If libgd has been compiled with TrueType font support, then you can use
  # scaled TrueType fonts. If not, then uncomment FREETYPE.
  # Requires GD, PNG and Z libraries, optionally libfreetype.
! #
  NEWGD=1
  JPEG=1
  FREETYPE=1
  
  # PDF device driver
  # Requires PNG and Z libraries based on particular PDF library used, and
--- 47,61 ----
  # If libgd has been compiled with TrueType font support, then you can use
  # scaled TrueType fonts. If not, then uncomment FREETYPE.
  # Requires GD, PNG and Z libraries, optionally libfreetype.
! # The recent GD requires libfontconfig, and optinally uses libiconv
! # If GD ilibraries requires either and both, uncomment FONTCONFIG
! # (and ICONV) suitably.
  NEWGD=1
  JPEG=1
  FREETYPE=1
+ #FONTCONFIG=1
+ #ICONV=1
+ 
  
  # PDF device driver
  # Requires PNG and Z libraries based on particular PDF library used, and
***************
*** 214,219 ****
--- 219,230 ----
    CFLAGS += -DHAVE_GD_TTF
    TERMLIBS += -lfreetype
  endif
+ ifdef FONTCONFIG
+   TERMLIBS += -lfontconfig
+ endif
+ ifdef ICONV
+   TERMLIBS += -liconv
+ endif
  endif
  
  ifdef PDF

# ****end of the patch *********

--- Ethan A Merritt <merritt@u.washington.edu> wrote:

> On Wednesday 17 December 2008, Tatsuro MATSUOKA wrote:
> > Hello Ethan and Petr
> > 
> > Thank you for your replies. 
> > 
> > From the config.log, the configure script of the gd-2.0.36RC1 searches both libiconv and
> fontconfig.
> > 
> > The gd-2.0.36RC1 is the latest gd source except for that on cvs-trees.
> 
> OK. I have now read the source files for gd-2.0.36RC1.
> I see that libiconv is optional, and used only by the file:
> 
> /* gdkanji.c (Kanji code converter)                            */
> /*                 written by Masahito Yamaga (ma...@ya...) */
> 
> I think this is only relevant if you need conversion from SJIS encoding,
> because kanji use works on my UTF8-based machines without using libiconv.
> The ./configure script for libgd searches for libiconv on your system
> when building libgd, and includes this optional code only if it is found.
> 
> 	Ethan


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

Re: gd.trm issue for mingw-gcc-4.3.0 building

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

On Wednesday 17 December 2008, Tatsuro MATSUOKA wrote:
> Hello Ethan and Petr
> 
> Thank you for your replies. 
> 
> From the config.log, the configure script of the gd-2.0.36RC1 searches both libiconv and fontconfig.
> 
> The gd-2.0.36RC1 is the latest gd source except for that on cvs-trees.

OK. I have now read the source files for gd-2.0.36RC1.
I see that libiconv is optional, and used only by the file:

/* gdkanji.c (Kanji code converter)                            */
/*                 written by Masahito Yamaga (ma...@ya...) */

I think this is only relevant if you need conversion from SJIS encoding,
because kanji use works on my UTF8-based machines without using libiconv.
The ./configure script for libgd searches for libiconv on your system
when building libgd, and includes this optional code only if it is found.

	Ethan



> ****************
> The configure and make were executed using gcc-3.4.5 with the latest mingw runtime and win32api.
> (mingw runtime 3.15.1 and w32api-3.13)
> 
> ./configure --prefix=/usr/local/gd-2.0.36RC1 --disable-shared
> 
> Here I refer small part of config.log for gd-2.0.36RC1
> 
> configure:21662: gcc -o conftest.exe -g -O2 -DNONDLL -I/mingw/include -I/GnuWin32/include
> -I/WinDevTools/include -L/mingw/lib -L/GnuWin32/lib -L/WinDevTools/lib conftest.c 
> /GnuWin32/lib/libiconv.dll.a -Wl,-rpath -Wl,/GnuWin32/lib >&5
> configure:21668: $? = 0
> configure:21689: result: yes
> 
> The libiconv used is libiconv-1.9.2 on GnuWin32.
> 
> configure:23234: checking for FcInit in -lfontconfig
> configure:23269: gcc -o conftest.exe -g -O2 -IC:/Programs/GnuWin32/include/freetype2
> -IC:/Programs/GnuWin32/include -DNONDLL -I/mingw/include -I/GnuWin32/include -I/WinDevTools/include
> -I/GnuWin32/include/libpng12  -LC:/Programs/GnuWin32/lib -LC:/Programs/GnuWin32/lib -Wl,-s
> -LD:/Progra~1/GnuWin32/lib  -L/GnuWin32/bin/lib -L/mingw/lib -L/GnuWin32/lib -L/WinDevTools/lib
> conftest.c -lfontconfig  -lfreetype -lpng12 -lz  >&5
> configure:23275: $? = 0
> configure:23293: result: yes
> 
> The fontconfig used is fontconfig-2.4.2 on the GTK web page.
> GTK+ for windows
> http://www.gtk.org/download-windows.html
> 
> Regards
> 
> Tatsuro
> 
> 
> --- Ethan A Merritt <merritt@u.washington.edu> wrote:
> 
> > On Tuesday 16 December 2008, Petr Mikulik wrote:
> > > > I have been struggling to build gd libraries for these days.  Today I have succeeded to
> > build
> > > > gd-2.0.36RC1 static library and get rid of the problem of mingw-gcc-4.3.0 building.
> > > > 
> > > > No modification has not been required for gd.trm.
> > > > 
> > > > However it is required to add '-lfontcongfig -liconv' to linker flag in makefile.mgw.
> > > > (This is required regardless gcc version.)
> > > >
> > > > Where is the suitable place to add the flags: '-lfontconfig -liconv' ?
> > > 
> > > I use an older static version of gd and these flags cannot be used (no 
> > > iconv.a).
> > >  
> > > > Temporary I modified  
> > > > 
> > > > ifdef FREETYPE
> > > >   CFLAGS += -DHAVE_GD_TTF
> > > >   TERMLIBS += -lfreetype
> > > > endif
> > > >  |
> > > >  V
> > > > ifdef FREETYPE
> > > >   CFLAGS += -DHAVE_GD_TTF
> > > >   TERMLIBS += -lfreetype -lfontconfig -liconv
> > > > endif
> > > > 
> > > > But it seem not so good to do it.
> > > 
> > > Aha, so you need them for your version of freetype, not for gd.
> > 
> > libgd requires freetype.
> > libgd also requires fontconfig.
> > 
> > I think it is correct to put them both in TERMLIBS as shown above.
> > 
> > > Where do fontconfig.a and iconv.a come from?
> > 
> > fontconfig is required by libgd directly
> > 
> > iconv is used for character encoding conversions and internationalization, 
> > but I don't know why there is a dependency in this case. In fact, I don't
> > even have a libiconv on my machines, it is a stand-alone utility.
> > 
> > 
> > -- 
> > Ethan A Merritt
> > Biomolecular Structure Center
> > University of Washington, Seattle 98195-7742
> > 
> 
> 
> --------------------------------------
> Power up the Internet with Yahoo! Toolbar.
> http://pr.mail.yahoo.co.jp/toolbar/
> 



-- 
Ethan A Merritt

Re: gd.trm issue for mingw-gcc-4.3.0 building

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

Hello Ethan and Petr

Thank you for your replies. 

>From the config.log, the configure script of the gd-2.0.36RC1 searches both libiconv and fontconfig.

The gd-2.0.36RC1 is the latest gd source except for that on cvs-trees.

****************
The configure and make were executed using gcc-3.4.5 with the latest mingw runtime and win32api.
(mingw runtime 3.15.1 and w32api-3.13)

./configure --prefix=/usr/local/gd-2.0.36RC1 --disable-shared

Here I refer small part of config.log for gd-2.0.36RC1

configure:21662: gcc -o conftest.exe -g -O2 -DNONDLL -I/mingw/include -I/GnuWin32/include
-I/WinDevTools/include -L/mingw/lib -L/GnuWin32/lib -L/WinDevTools/lib conftest.c 
/GnuWin32/lib/libiconv.dll.a -Wl,-rpath -Wl,/GnuWin32/lib >&5
configure:21668: $? = 0
configure:21689: result: yes

The libiconv used is libiconv-1.9.2 on GnuWin32.

configure:23234: checking for FcInit in -lfontconfig
configure:23269: gcc -o conftest.exe -g -O2 -IC:/Programs/GnuWin32/include/freetype2
-IC:/Programs/GnuWin32/include -DNONDLL -I/mingw/include -I/GnuWin32/include -I/WinDevTools/include
-I/GnuWin32/include/libpng12  -LC:/Programs/GnuWin32/lib -LC:/Programs/GnuWin32/lib -Wl,-s
-LD:/Progra~1/GnuWin32/lib  -L/GnuWin32/bin/lib -L/mingw/lib -L/GnuWin32/lib -L/WinDevTools/lib
conftest.c -lfontconfig  -lfreetype -lpng12 -lz  >&5
configure:23275: $? = 0
configure:23293: result: yes

The fontconfig used is fontconfig-2.4.2 on the GTK web page.
GTK+ for windows
http://www.gtk.org/download-windows.html

Regards

Tatsuro


--- Ethan A Merritt <merritt@u.washington.edu> wrote:

> On Tuesday 16 December 2008, Petr Mikulik wrote:
> > > I have been struggling to build gd libraries for these days.  Today I have succeeded to
> build
> > > gd-2.0.36RC1 static library and get rid of the problem of mingw-gcc-4.3.0 building.
> > > 
> > > No modification has not been required for gd.trm.
> > > 
> > > However it is required to add '-lfontcongfig -liconv' to linker flag in makefile.mgw.
> > > (This is required regardless gcc version.)
> > >
> > > Where is the suitable place to add the flags: '-lfontconfig -liconv' ?
> > 
> > I use an older static version of gd and these flags cannot be used (no 
> > iconv.a).
> >  
> > > Temporary I modified  
> > > 
> > > ifdef FREETYPE
> > >   CFLAGS += -DHAVE_GD_TTF
> > >   TERMLIBS += -lfreetype
> > > endif
> > >  |
> > >  V
> > > ifdef FREETYPE
> > >   CFLAGS += -DHAVE_GD_TTF
> > >   TERMLIBS += -lfreetype -lfontconfig -liconv
> > > endif
> > > 
> > > But it seem not so good to do it.
> > 
> > Aha, so you need them for your version of freetype, not for gd.
> 
> libgd requires freetype.
> libgd also requires fontconfig.
> 
> I think it is correct to put them both in TERMLIBS as shown above.
> 
> > Where do fontconfig.a and iconv.a come from?
> 
> fontconfig is required by libgd directly
> 
> iconv is used for character encoding conversions and internationalization, 
> but I don't know why there is a dependency in this case. In fact, I don't
> even have a libiconv on my machines, it is a stand-alone utility.
> 
> 
> -- 
> Ethan A Merritt
> Biomolecular Structure Center
> University of Washington, Seattle 98195-7742
> 


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

Re: gd.trm issue for mingw-gcc-4.3.0 building

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

On Tuesday 16 December 2008, Petr Mikulik wrote:
> > I have been struggling to build gd libraries for these days.  Today I have succeeded to build
> > gd-2.0.36RC1 static library and get rid of the problem of mingw-gcc-4.3.0 building.
> > 
> > No modification has not been required for gd.trm.
> > 
> > However it is required to add '-lfontcongfig -liconv' to linker flag in makefile.mgw.
> > (This is required regardless gcc version.)
> >
> > Where is the suitable place to add the flags: '-lfontconfig -liconv' ?
> 
> I use an older static version of gd and these flags cannot be used (no 
> iconv.a).
>  
> > Temporary I modified  
> > 
> > ifdef FREETYPE
> >   CFLAGS += -DHAVE_GD_TTF
> >   TERMLIBS += -lfreetype
> > endif
> >  |
> >  V
> > ifdef FREETYPE
> >   CFLAGS += -DHAVE_GD_TTF
> >   TERMLIBS += -lfreetype -lfontconfig -liconv
> > endif
> > 
> > But it seem not so good to do it.
> 
> Aha, so you need them for your version of freetype, not for gd.

libgd requires freetype.
libgd also requires fontconfig.

I think it is correct to put them both in TERMLIBS as shown above.

> Where do fontconfig.a and iconv.a come from?

fontconfig is required by libgd directly

iconv is used for character encoding conversions and internationalization, 
but I don't know why there is a dependency in this case. In fact, I don't
even have a libiconv on my machines, it is a stand-alone utility.


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

Re: gd.trm issue for mingw-gcc-4.3.0 building

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

> I have been struggling to build gd libraries for these days.  Today I have succeeded to build
> gd-2.0.36RC1 static library and get rid of the problem of mingw-gcc-4.3.0 building.
> 
> No modification has not been required for gd.trm.
> 
> However it is required to add '-lfontcongfig -liconv' to linker flag in makefile.mgw.
> (This is required regardless gcc version.)
>
> Where is the suitable place to add the flags: '-lfontconfig -liconv' ?

I use an older static version of gd and these flags cannot be used (no 
iconv.a).
 
> Temporary I modified  
> 
> ifdef FREETYPE
>   CFLAGS += -DHAVE_GD_TTF
>   TERMLIBS += -lfreetype
> endif
>  |
>  V
> ifdef FREETYPE
>   CFLAGS += -DHAVE_GD_TTF
>   TERMLIBS += -lfreetype -lfontconfig -liconv
> endif
> 
> But it seem not so good to do it.

Aha, so you need them for your version of freetype, not for gd.
Where do fontconfig.a and iconv.a come from?

---
PM

Re: gd.trm issue for mingw-gcc-4.3.0 building

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

Hello

I have been struggling to build gd libraries for these days.  Today I have succeeded to build
gd-2.0.36RC1 static library and get rid of the problem of mingw-gcc-4.3.0 building.

No modification has not been required for gd.trm.

However it is required to add '-lfontcongfig -liconv' to linker flag in makefile.mgw.
(This is required regardless gcc version.)

Where is the suitable place to add the flags: '-lfontconfig -liconv' ?

Temporary I modified  

ifdef FREETYPE
  CFLAGS += -DHAVE_GD_TTF
  TERMLIBS += -lfreetype
endif
 |
 V
ifdef FREETYPE
  CFLAGS += -DHAVE_GD_TTF
  TERMLIBS += -lfreetype -lfontconfig -liconv
endif

But it seem not so good to do it.

Any suggestions?

Regards

Tatsuro

--- Tatsuro MATSUOKA <tma...@ya...> wrote:

> Hello 
> 
> --- Pierre Joye <pie...@gm...> wrote:
> > 
> > Without having tested it recently under mingw, I would suggest to
> > first use a more recent version (.35 or .36-cvs).
> > 
> > Cheers,
> > -- 
> > Pierre
> 
> I will try and report you and gnuplot-beta/ML.
> However, I have caught a cold so that the trial will be delayed.
> 
> Thank for Ethan and Pierre for kind treatments of the matter.
> 
> BTW
> 
> //#if !defined(GD_NEED_LOCAL_FONT_POINTERS) 
> BGD_EXPORT_DATA_PROT gdFontPtr gdFontSmall;	/* 6x12 */
> BGD_EXPORT_DATA_PROT gdFontPtr gdFontLarge;	/* 8x16 */
> BGD_EXPORT_DATA_PROT gdFontPtr gdFontMediumBold;	/* 7x13 */
> BGD_EXPORT_DATA_PROT gdFontPtr gdFontGiant;  /* 9x15 */
> BGD_EXPORT_DATA_PROT gdFontPtr gdFontTiny;  /* 5x8 */
> //#else
> //static gdFontPtr gdFontSmall;	/* 6x12 */
> //static gdFontPtr gdFontLarge;	/* 8x16 */
> //static gdFontPtr gdFontMediumBold;	/* 7x13 */
> //static gdFontPtr gdFontGiant;  /* 9x15 */
> //static gdFontPtr gdFontTiny;  /* 5x8 */
> //#endif
> 
> Quick and dirty modification the above seemed to work well yesterday for gcc-4.3.0 (mingw)
> building.
> 
> **********************************************
> gnuplot> set term png small
> Terminal type set to 'png'
> Options are 'nocrop font arial 10 size 640,480 '
> gnuplot> set term png medium
> Terminal type set to 'png'
> Options are 'nocrop font arial 12 size 640,480 '
> gnuplot> set term png large
> Terminal type set to 'png'
> Options are 'nocrop font arial 14 size 640,480 '
> ***********************************************
> The above are the same as those by wgnuplot.exe build by Petr (gp43-Nov21_2008-winbin.zip)
> 
> However, the above modification of course is permitted only for personal purpose.
> 
> Anyway first I have to do is to get rid of the cold. :-)
> 
> Regards
> 
> Tatsuro 
> 
> --------------------------------------
> Power up the Internet with Yahoo! Toolbar.
> http://pr.mail.yahoo.co.jp/toolbar/
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 


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

Re: [RFC] Proposal to re-think binary file handling

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

Petr Mikulik <mikulik <at> physics.muni.cz> writes:

> 
> >    set binary datafile array=Infx5 format="%double%double"
> > 
> > Someone please remind me why we need oddball format specs like
> > 	format="%double%double"
> > rather than 
> > 	format="%lf%lf"
> > I'm sure I must have asked this before, when the code went into CVS,
> > but I have forgotten the answer.  Can we get rid of additional hundreds
> > of lines of obscure code simply by requiring that users provide
> > a valid C format statement for reading their own binary data files?
> 
> Implementation of general binary files comes from 2003. We exchanged a lot 
> of e-mails with Daniel Sebald. Nobody came with such a proposal as you have 
> now.
> 
> The main reason for format="%double%double" and not "%lf%lf" is that textual 
> headers of image or volume files have keywords like char, byte, double, int, 
> float, etc. That's why we had used the same keywords for "format" as well.
> 
> On the other hand, your proposal "%lf%lf" reflects the formating from 
> programmer's point of view. However, in C, there is no special formatting 
> for signed and unsigned char, so we are out of luck for this notation.

Hi Folks,

The bugs found by Shigeharu Takeno (I think there were two separate bugs)
seemed insignificant.  If they are still outstanding, point me to the bug
reports.

'set datafile binary format' was implemented from what I recall, but that
is where one of the bugs may lie.

Generally, I don't think the binary code is the awful mess claimed to be,
but sure the syntax and layout could perhaps use improvement.  I'm certain
I asked time and again for feedback five years ago, but Petr seemed the
only one to take interest.  In fact, I agreed it should be labeled
'EXPERIMENTAL', and I'm open for changes if others are.

Petr has described the reason for the more varied format specifiers; it's
for the programmer trying to communicate with gnuplot.  That is, 'double',
'uint', etc. is more the language of binary programming.  There are
machine independent and machine dependent sizes for various instances.
Anyway, parsing that code isn't too bad.  The '10x5' dimension specifier
is the inelegant one.

It wasn't fun to program the binary array specification, mostly because--
as Ethan pointed out--almost anything one can dream up causes confusion
with already-used tokens.  The comma, the colon, etc.  They cause the
parser to think it is an end-of-line, so on.  'Inf' isn't particularly
graceful, is it?  I suppose I chose that as a symbol because it was the
only thing I could think of to mean "indefinite".  However, how about a
syntax that is similar to the way variables are declared in C?

array [10][5]

Would that parse a little better?  That would be six tokens, I think, that
the parser would send back.  The syntax would allow for the 'indefinite'
dimension length

array [10][5][]

which has the look of C.

Dan

Re: Tweak for interactive SVGs?

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

On Sunday 14 December 2008, Bill Broadley wrote:
> 
> I've been generating some plots that get a bit busy, sometimes it's nice to be
> able to toggle what you see.  So I wrote a script to tweak the gnuplot output,
> and it generates:
>          http://cse.ucdavis.edu/bill/barc.svg
> 
> Try clicking on any of key titles like "1-thread add".  Currently it's a short
> perl script.  The changes are just things like adding a
> onclick=ToggleVisibilty call for each key text entry, adding a id= group for
> each line in the graph, and of course the small routine to actually toggle the
> visibility.
> 
> Any comments on how hard it would be to add to the gnuplot SVG output routine?
> How useful? 
> Would a reasonably written patch to do this be accepted?

That's very nice.

Please have a look at the patchset  #2172587  "Embedded hyperlinks"
https://sourceforge.net/tracker/index.php?func=detail&aid=2172587&group_id=2055&atid=302055

That patchset contains an extension to the svg terminal driver that does
something parallel to your idea. It wraps each plot (and key entry) in
a group with an attached xlink hyperref.   

It may be that you could re-use much of that code.
It may also be that you can see a cleaner way to do it, or better yet
propose an extension that handles both uses via the same mechanism.

As to the associated routine that does the toggling, here also I would 
very much encourage brainstorming about how this could be made as 
general as possible. My long-term vision for the svg terminal
(a goal that I keep trying to hand off to someone else :-)
is to  provide all the necessary infrastructure for a set of associated
scripts to carry out client-side mousing operations like the existing
interactive terminals.  I had been thinking mostly of mouse-tracking and
zoom, but your example makes me realize that other operations like 
toggling the grid or ruler bars are even easier.

-- 
Ethan A Merritt

Re: Tweak for interactive SVGs?

[Bill B. <bi...@br...>]

peter wrote:
> Bill Broadley wrote:
>> I've been generating some plots that get a bit busy, sometimes it's nice to be
>> able to toggle what you see.  So I wrote a script to tweak the gnuplot output,
>> and it generates:
>>          http://cse.ucdavis.edu/bill/barc.svg
>>
> Hi again,
> 
> quick after thought: could you extend it to having the line sample next
> to the title as part of the clickable?

That would be somewhat tricky.  Currently I have:
<text  onclick='ToggleVisibilty(evt, "1add")'>1-thread add</text>

Which is inside a <g> that sets the style, color, widget, font, stroke, etc.

The sample line is part of the entire path:
<path id='1add' d='M715.6,72.0 L757.8,72.0 M774.4,440.3 ...

The first M is the beginning of the sample, the next M is the start of the
graph.  So the quick easy thing to do is:
http://cse.ucdavis.edu/bill/out2.svg

I only fixed 1-thread add, notice that you can click on the graph for that
line, the sample, or the text.  But you can't unclick the sample once it
disappears.  Splitting out the sample so it doesn't disappear would be
somewhat harder, but possible.  There are two fixes for that, making the
sample not disappear, or making it clickable even when invisible... both possible.

> I find it more intuitive if I
> want to hide the dark blue line to click on the dark blue sample since
> that it what I have to identify first. Obviously when you are thinking
> in the other direction, removing "2-thread-add" you are more likely to
> click the text.

Indeed, I considered making the samples much thicker to make them easier to
click on.  Or maybe drawing an invisible but clickable box around the title
and sample so it's easier to click on.

Of course once you get used to this you start wishing that gnuplot's
x11/wxwidgets interface had similar functionality.  I looked around for other
solutions to something like this and found none.  Google Gadgets can do some
of this stuff, but seem toy like and not friendly to log/log graphs.  Open
Flash Chart seems like an interesting approach, they definitely do interactive
charts with tooltip/balloons for the values of the nearest datapoint and the
like, but again I didn't see an easy way to toggle data, nor do log/log
graphs.  So here I am with the best solution I've found so far.

> Both approaches are valid depending on why one wants to hide a line. For
> example if I want to see the detail of your "1-thread add" , I would
> identify the dark green line as the one masking what I want to see and
> it would be my instinct to click on the green line segment. (When I
> realise it does nothing I go for the text).

Indeed.

> The other question is discoverability in the svg graphic. There is no
> established token to indicate the titles are interactive. It may be
> worth adding a bullet or round button before each title as a visual key.
>  This may want to be optional since these titles can encroach on the data.

Indeed, I wasn't sure.  On one hand a traditional radio button and/or checkbox
would be the easiest for a user.  Then again I kinda like not changing the
look at all in case a user wants to use it to look just like it does now.

> consider a small red square with a 1px black outline in front of
> "1-thread add". May be helpful.

Navigating a datafile without any metadata via regular expressions is
definitely not the way to do this.  But if it's done in the SVG output driver
anything along these lines should be possible.

Re: Tweak for interactive SVGs?

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

Bill Broadley wrote:
> I've been generating some plots that get a bit busy, sometimes it's nice to be
> able to toggle what you see.  So I wrote a script to tweak the gnuplot output,
> and it generates:
>          http://cse.ucdavis.edu/bill/barc.svg
> 
> Try clicking on any of key titles like "1-thread add".  Currently it's a short
> perl script.  The changes are just things like adding a
> onclick=ToggleVisibilty call for each key text entry, adding a id= group for
> each line in the graph, and of course the small routine to actually toggle the
> visibility.
> 
> Any comments on how hard it would be to add to the gnuplot SVG output routine?
> 
> How useful?
> 
> Would a reasonably written patch to do this be accepted?
> 
> It interactive toggle is responsible to around 1400 bytes of that 55kb file.
> 
> In any case I find it rather useful, especially when comparing two different
> datasets.
> 

Hi Bill,

from a user's point of view I love it. I have several cases where this
would be useful including my current main use for gnuplot on an embedded
system.

In view of the relatively light overhead it seems like a very good feature.

I would imagine that the biggest problem would be defining the syntax
for the commands to integrate this idea rather than the implementation
itself. I'll let the core devs reply on that issue.

Are you willing to send me your perl script? I may well implement the
same idea in awk rather than waiting for an eventual integration of this
feature in gnuplot (the embedded does not have perl)


Best regards, Peter.

Tweak for interactive SVGs?

[Bill B. <bi...@br...>]

I've been generating some plots that get a bit busy, sometimes it's nice to be
able to toggle what you see.  So I wrote a script to tweak the gnuplot output,
and it generates:
         http://cse.ucdavis.edu/bill/barc.svg

Try clicking on any of key titles like "1-thread add".  Currently it's a short
perl script.  The changes are just things like adding a
onclick=ToggleVisibilty call for each key text entry, adding a id= group for
each line in the graph, and of course the small routine to actually toggle the
visibility.

Any comments on how hard it would be to add to the gnuplot SVG output routine?

How useful?

Would a reasonably written patch to do this be accepted?

It interactive toggle is responsible to around 1400 bytes of that 55kb file.

In any case I find it rather useful, especially when comparing two different
datasets.

Re: extending pstricks terminal driver

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

> > popen() works on Windows, but wgnuplot_pipes.exe binary has to be run 
> > instead of wgnuplot.exe
> 
> Why would you ever want to run a version that deliberately omits support 
> for popen()?

Because it needs to open an additional (usually empty) console window.

---
PM

Re: extending pstricks terminal driver

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

On Thursday 11 December 2008 14:49:55 Petr Mikulik wrote:
> > > > > >>     plot '<convert table.png avs:-' binary filetype=avs with rgbimage
> > > > > >>
> > > > > >> Nowadays gnuplot is typically compiled with the gd library. Therefore it
> > > > > >> should be pretty easy to use the gd-library to load png/gif/jpg images
> > > > > >> directly. I think it may not be too much code in breaders.c. Could somebody
> > > > > >> contribute this feature?
> > > > > >
> > > > > > I honestly don't see quite how that would work.
> > > > > > Using libgd, or libpng for that matter, will result in an in-memory copy
> > > > > > of the bitmap image.  But that's not exactly what the binary file input code
> > > > > > wants; it expects to read a stream of binary data on the input fd, so that it
> > > > > > can filter, re-map, combine fields, etc.  It seems to me that one would
> > > > > > have to write a new input layer that dummies up access to an in-memory
> > > > > > bitmap as successive reads to a fake pipe.
> > > 
> > > The abstraction layer ... cannot be this done in some easy way? Currently 
> > > there are fread(f, ..., bytes) ... so instead of fread() there would be 
> > > memcpy().
> > > 
> > > The gain would be portability and speed. We could put lena.png and lena.jpg 
> > > into demos/ and be sure that these demos can be run by Windows executables 
> > > as well.
> > 
> > I don't see how requiring ImageMagick limits the portability, and it is
> > a much more general solution than one that accommodates only png images.
> > I am dubious that the speed is enough different to notice.
> >
> > As to Windows, it would be of far more value to get the popen() filter
> > mechanism working under Windows than it would be to add large chunks of
> > code to make up for various individual things you can't do because of this
> > shared fundamental flaw.
> 
> ImageMagick is no problem for Linux users. It is problem for Windows people. 
> We cannot expect them to install any other tool. Gnuplot should not depend 
> on outside filters, if we can organize it within gnuplot.

That's nonsense.  If they can install gnuplot, they can also install
ImageMagick.  Probably more easily, since we don't have a one-click 
Windows installer :-)

Gnuplot already makes good use of external filters and tools including
ghostscript, LaTeX, Fig, and lots of locally tailored scripts requiring
perl, python, tcl, etc.  Gnuplot's strength is the extent to which it
complements and extends existing tools.  The ability to pipe data in and
out through filters is a key part of this. We should not re-invent the
wheel, badly, rather than playing to our strength.
 
> popen() works on Windows, but wgnuplot_pipes.exe binary has to be run 
> instead of wgnuplot.exe

I understand that stdin/stdout are problematic if the program is run
without a console window, but that is a different issue than reading
data via a call to popen().  Why would you ever want to run a version
that deliberately omits support for popen()?

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

Re: extending pstricks terminal driver

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

> > > > >>     plot '<convert table.png avs:-' binary filetype=avs with rgbimage
> > > > >>
> > > > >> Nowadays gnuplot is typically compiled with the gd library. Therefore it
> > > > >> should be pretty easy to use the gd-library to load png/gif/jpg images
> > > > >> directly. I think it may not be too much code in breaders.c. Could somebody
> > > > >> contribute this feature?
> > > > >
> > > > > I honestly don't see quite how that would work.
> > > > > Using libgd, or libpng for that matter, will result in an in-memory copy
> > > > > of the bitmap image.  But that's not exactly what the binary file input code
> > > > > wants; it expects to read a stream of binary data on the input fd, so that it
> > > > > can filter, re-map, combine fields, etc.  It seems to me that one would
> > > > > have to write a new input layer that dummies up access to an in-memory
> > > > > bitmap as successive reads to a fake pipe.
> > 
> > The abstraction layer ... cannot be this done in some easy way? Currently 
> > there are fread(f, ..., bytes) ... so instead of fread() there would be 
> > memcpy().
> > 
> > The gain would be portability and speed. We could put lena.png and lena.jpg 
> > into demos/ and be sure that these demos can be run by Windows executables 
> > as well.
> 
> I don't see how requiring ImageMagick limits the portability, and it is
> a much more general solution than one that accommodates only png images.
> I am dubious that the speed is enough different to notice.
>
> As to Windows, it would be of far more value to get the popen() filter
> mechanism working under Windows than it would be to add large chunks of
> code to make up for various individual things you can't do because of this
> shared fundamental flaw.

ImageMagick is no problem for Linux users. It is problem for Windows people. 
We cannot expect them to install any other tool. Gnuplot should not depend 
on outside filters, if we can organize it within gnuplot.

popen() works on Windows, but wgnuplot_pipes.exe binary has to be run 
instead of wgnuplot.exe

---
PM

Re: extending pstricks terminal driver

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

On Thursday 11 December 2008 12:07:12 Petr Mikulik wrote:
> > > >>     plot '<convert table.png avs:-' binary filetype=avs with rgbimage
> > > >>
> > > >> Nowadays gnuplot is typically compiled with the gd library. Therefore it
> > > >> should be pretty easy to use the gd-library to load png/gif/jpg images
> > > >> directly. I think it may not be too much code in breaders.c. Could somebody
> > > >> contribute this feature?
> > > >
> > > > I honestly don't see quite how that would work.
> > > > Using libgd, or libpng for that matter, will result in an in-memory copy
> > > > of the bitmap image.  But that's not exactly what the binary file input code
> > > > wants; it expects to read a stream of binary data on the input fd, so that it
> > > > can filter, re-map, combine fields, etc.  It seems to me that one would
> > > > have to write a new input layer that dummies up access to an in-memory
> > > > bitmap as successive reads to a fake pipe.
> 
> The abstraction layer ... cannot be this done in some easy way? Currently 
> there are fread(f, ..., bytes) ... so instead of fread() there would be 
> memcpy().
> 
> 
> > > > What would we gain by adding all this extra code? Isn't it much better to let
> > > > an external utility do this for us, as in the example you quote?
> > > 
> > > One would gain readability. I would never have come to idea to use so
> > > complicated code to be able to read PNG images.
> 
> The gain would be portability and speed. We could put lena.png and lena.jpg 
> into demos/ and be sure that these demos can be run by Windows executables 
> as well.

I don't see how requiring ImageMagick limits the portability, and it is
a much more general solution than one that accommodates only png images.
I am dubious that the speed is enough different to notice.

As to Windows, it would be of far more value to get the popen() filter
mechanism working under Windows than it would be to add large chunks of
code to make up for various individual things you can't do because of this
shared fundamental flaw.


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

Re: extending pstricks terminal driver

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

> > >>     plot '<convert table.png avs:-' binary filetype=avs with rgbimage
> > >>
> > >> Nowadays gnuplot is typically compiled with the gd library. Therefore it
> > >> should be pretty easy to use the gd-library to load png/gif/jpg images
> > >> directly. I think it may not be too much code in breaders.c. Could somebody
> > >> contribute this feature?
> > >
> > > I honestly don't see quite how that would work.
> > > Using libgd, or libpng for that matter, will result in an in-memory copy
> > > of the bitmap image.  But that's not exactly what the binary file input code
> > > wants; it expects to read a stream of binary data on the input fd, so that it
> > > can filter, re-map, combine fields, etc.  It seems to me that one would
> > > have to write a new input layer that dummies up access to an in-memory
> > > bitmap as successive reads to a fake pipe.

The abstraction layer ... cannot be this done in some easy way? Currently 
there are fread(f, ..., bytes) ... so instead of fread() there would be 
memcpy().


> > > What would we gain by adding all this extra code? Isn't it much better to let
> > > an external utility do this for us, as in the example you quote?
> > 
> > One would gain readability. I would never have come to idea to use so
> > complicated code to be able to read PNG images.

The gain would be portability and speed. We could put lena.png and lena.jpg 
into demos/ and be sure that these demos can be run by Windows executables 
as well.

---
PM

Re: extending pstricks terminal driver

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

On Thursday 11 December 2008 10:26:24 Mojca Miklavec wrote:
> On Thu, Dec 11, 2008 at 6:56 PM, Ethan Merritt wrote:
> > On Wednesday 10 December 2008 08:42:21 Petr Mikulik wrote:
> >> >
> >> > One question: is "with image" already able to read png images? I had
> >> > an impression that it was only able to read some
> >> > unusual binary formats (3 bytes per pixel).
> >>
> >> Ethan has shown it works this way:
> >>
> >>     plot '<convert table.png avs:-' binary filetype=avs with rgbimage
> >>
> >> Nowadays gnuplot is typically compiled with the gd library. Therefore it
> >> should be pretty easy to use the gd-library to load png/gif/jpg images
> >> directly. I think it may not be too much code in breaders.c. Could somebody
> >> contribute this feature?
> >
> > I honestly don't see quite how that would work.
> > Using libgd, or libpng for that matter, will result in an in-memory copy
> > of the bitmap image.  But that's not exactly what the binary file input code
> > wants; it expects to read a stream of binary data on the input fd, so that it
> > can filter, re-map, combine fields, etc.  It seems to me that one would
> > have to write a new input layer that dummies up access to an in-memory
> > bitmap as successive reads to a fake pipe.
> >
> > What would we gain by adding all this extra code? Isn't it much better to let
> > an external utility do this for us, as in the example you quote?
> 
> One would gain readability. I would never have come to idea to use so
> complicated code to be able to read PNG images.

Well, it is documented. And it is quite general. The same command works for
any image type that ImageMagick knows about. There is nothing special about
*.png in this regard.

> It's perfectly OK if external tools are being used, but it would help
> a lot if calling external tools would happen automatically for
> specific types of images.

Do you mean that a command like
   plot 'imagefile' binary filetype=auto with rgbimage
should always be expanded to the equivalent
   plot  '<convert imagefile avs:-' binary filetype=avs with rgbimage
if there is no special rule for the filetype extension?

That would work OK on any unix-ish system that has ImageMagick installed,
but would fail for other configurations.

Or are you suggesting that gnuplot should have a plugin mechanism of some sort,
that would be locally configured to invoke an appropriate external converter?
I have no objection to that, but I don't have the expertise to write one.


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

Re: extending pstricks terminal driver

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

On Thu, Dec 11, 2008 at 6:56 PM, Ethan Merritt wrote:
> On Wednesday 10 December 2008 08:42:21 Petr Mikulik wrote:
>> >
>> > One question: is "with image" already able to read png images? I had
>> > an impression that it was only able to read some
>> > unusual binary formats (3 bytes per pixel).
>>
>> Ethan has shown it works this way:
>>
>>     plot '<convert table.png avs:-' binary filetype=avs with rgbimage
>>
>> Nowadays gnuplot is typically compiled with the gd library. Therefore it
>> should be pretty easy to use the gd-library to load png/gif/jpg images
>> directly. I think it may not be too much code in breaders.c. Could somebody
>> contribute this feature?
>
> I honestly don't see quite how that would work.
> Using libgd, or libpng for that matter, will result in an in-memory copy
> of the bitmap image.  But that's not exactly what the binary file input code
> wants; it expects to read a stream of binary data on the input fd, so that it
> can filter, re-map, combine fields, etc.  It seems to me that one would
> have to write a new input layer that dummies up access to an in-memory
> bitmap as successive reads to a fake pipe.
>
> What would we gain by adding all this extra code? Isn't it much better to let
> an external utility do this for us, as in the example you quote?

One would gain readability. I would never have come to idea to use so
complicated code to be able to read PNG images.

It's perfectly OK if external tools are being used, but it would help
a lot if calling external tools would happen automatically for
specific types of images.

Mojca

Re: extending pstricks terminal driver

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

On Wednesday 10 December 2008 08:42:21 Petr Mikulik wrote:
> > 
> > One question: is "with image" already able to read png images? I had
> > an impression that it was only able to read some
> > unusual binary formats (3 bytes per pixel).
> 
> Ethan has shown it works this way:
> 
>     plot '<convert table.png avs:-' binary filetype=avs with rgbimage
> 
> Nowadays gnuplot is typically compiled with the gd library. Therefore it 
> should be pretty easy to use the gd-library to load png/gif/jpg images 
> directly. I think it may not be too much code in breaders.c. Could somebody 
> contribute this feature?

I honestly don't see quite how that would work.
Using libgd, or libpng for that matter, will result in an in-memory copy
of the bitmap image.  But that's not exactly what the binary file input code
wants; it expects to read a stream of binary data on the input fd, so that it
can filter, re-map, combine fields, etc.  It seems to me that one would
have to write a new input layer that dummies up access to an in-memory
bitmap as successive reads to a fake pipe.  

What would we gain by adding all this extra code? Isn't it much better to let
an external utility do this for us, as in the example you quote?

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

Re: extending pstricks terminal driver

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

> >> I wish there was a way to plot with bitmap terminal and use TeX labels
> >> over it.
> >
> > That you can do. Use "set term png", unset border and tics, save the plot
> > and then "plot with image" with additional labels.
> 
> One question: is "with image" already able to read png images? I had
> an impression that it was only able to read some
> unusual binary formats (3 bytes per pixel).

Ethan has shown it works this way:

    plot '<convert table.png avs:-' binary filetype=avs with rgbimage

Actually, I have never met an .avs file in reality.

Nowadays gnuplot is typically compiled with the gd library. Therefore it 
should be pretty easy to use the gd-library to load png/gif/jpg images 
directly. I think it may not be too much code in breaders.c. Could somebody 
contribute this feature?

---
PM

Re: extending pstricks terminal driver

[Christoph B. <us...@be...>]

Mojca Miklavec schrieb:
> On Mon, Dec 8, 2008 at 9:38 AM, Christoph Bersch wrote:
>
>> And again: it shouldn't be a developer decision which terminal the users
>> 'want' to use.
> 
> Definitely not. But it helps to get a hint. I probably needed a year
> to discover other terminals besides "latex", and I was fighting with
> getting some outdated TeX-like terminals to work properly when they
> were actually using tricks that don't work in TeX packages any more or
> were using packages that are no longer part of TeX distributions.)

Right! I think it would be nice to have something like a gnuplot-*TeX 
tutorial which aims exactly at this point. I don't know if I can find 
some time to write a quick overview on the *TeX-suited terminals, their 
advantages and disadvantages. But I could try :-)


Christoph