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

Any last-minute fixes or requests for inclusion in 4.6.2?

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

Anyone know of an unresolved 4.6 bug that should be fixed before
releasing 4.6.2?   If not, I plan to put the usual source tarball
on SourceForge later this week.

Any volunteers to prepare a Windows install package?

	Ethan

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

NEWS file for 4.6.2

 New features, changes and fixes since gnuplot version 4.6.1
===========================================================

* NEW Allow the "bind" command to attach a user command to mouse button 1
* NEW hidden3d can handle occlusion by pm3d surfaces (as in hidden2.dem)
* NEW -d option from command line skips ~/.gnuplot initialization file
* NEW plot '<&N' plots from file descriptor N opened during shell invocation
* CHANGE "unset term" restores original default terminal (GNUTERM)
* CHANGE ignore extraneous trailing comma in a plot command
* CHANGE special case code for faster input of uniform binary matrix data
* CHANGE test for whether the session should be interactive or non-interactive
* CHANGE draw zeroaxis lines in the same layer as the grid and border
* CHANGE allow 2-column-only variant of yerrorbars (implicit x coord)
* FIX aquaterm rendering of rgbimage plot type
* FIX gd terminal fontsize change requested by set_font(",newsize")
* FIX qt terminal font metrics
* FIX qt terminal mouse tracking and resize events for persistent plots
* FIX x11 terminal sometimes failed to reset the line width
* FIX -persist mode continued mousing of 3D "set view map" plots
* FIX reset parsing state after error in parsing string input
* FIX buffer overflow from very long tic label formats
* FIX broken handling of formatted input via 'using 1:2 "<format>"'
* FIX exit current command file from inside bracketed clause
* FIX estimation of space required for rotated x-axis tic labels
* FIX partial axis ranges (e.g. xrange [*:MAX]) when refreshing volatile data
* FIX -persist option broken if configured without x11

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Re: Some ranging fixes for volatile data

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

On Thursday, 07 March 2013, Dima Kogan wrote:
> Hi.
> 
> Recently Ethan committed some fixes to make autoranging refreshes work
> for volatile data in commit titled
> 
>  Partial axis ranges, e.g. [*:MAX] or [MIN:*], were not being handled
>  correctly when refreshing volatile data.
> 
> Here are two patches to fix some more related issues. 
> The first patch applies similar logic to 3d plots.

> The second patch handles the case of degenerate ranges.

Applied. Thanks.

	Ethan

Re: [PATCH] x11 terminal is now less zealous about replotting

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

On Friday, 08 March 2013, Dima Kogan wrote:
> I'm attaching a patch to the x11 terminal to reduce the number of
> unneeded replot actions that happen with some window managers.
> 
> Some window managers (notion for instance) produce several
> ConfigureNotify events when a window is created. Some of these were
> mis-interpreted by gnuplot as a window manager refusing gnuplot's
> suggested resize, which resulted in extra, unneeded replot actions. This
> patch waits 0.1s for extra ConfigureNotify events before deciding that a
> resize was rejected. If a new ConfigureNotify is seen, we save a replot
> at the cost of 0.1s. If not, we proceed as before.


OK. Added to CVS for 4.7

	Ethan

Re: buggy behaviour of svg+splot with image

[Jonathan T. <jt...@as...>]

On Wed, 6 Mar 2013, Mojca Miklavec wrote:
> This would be problematic. Many people simply run the same plotting
> commands/scripts multiple times (either during development/improvement
> of graphs or to display measurement results for different data),
> *expecting* the files to be overwritten. I'm not using SVG, but for
> any format that I'm using, I would be annoyed if I would have to   
> confirm overwriting files.

*Very* emphatic agreement!

--
-- "Jonathan Thornburg [remove -animal to reply]" <jt...@as...-zebra.e$
   Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA
   on sabbatical in Canada starting August 2012
   "Washing one's hands of the conflict between the powerful and the
    powerless means to side with the powerful, not to be neutral."  
                                      -- quote by Freire / poster by Oxfam

[PATCH] x11 terminal is now less zealous about replotting

[Dima K. <gn...@di...>]

I'm attaching a patch to the x11 terminal to reduce the number of
unneeded replot actions that happen with some window managers.

Some window managers (notion for instance) produce several
ConfigureNotify events when a window is created. Some of these were
mis-interpreted by gnuplot as a window manager refusing gnuplot's
suggested resize, which resulted in extra, unneeded replot actions. This
patch waits 0.1s for extra ConfigureNotify events before deciding that a
resize was rejected. If a new ConfigureNotify is seen, we save a replot
at the cost of 0.1s. If not, we proceed as before.

Prescaling fit parameters

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

Hi,

A couple of years ago (March 2011) I submitted a very small patch against fit.c 
to improve the way gnuplot's fit function works in cases where fit parameters 
vary in size dramatically. The problem is that if you are doing fits where some 
parameters are, say 10^7, but others are 10^-7, the fit routine basically 
collapses.

The patch does a trivial rescaling of the parameters by their initial guess 
values before the meat of the fitting routine is called. With this rescaling 
these cases don't cause any problems.

The patch and a description are here:
http://sourceforge.net/p/gnuplot/patches/507/
and this still applies cleanly to gnuplot 4.6.

After applying this patch, most of the examples in fit.dem actually converge in 
fewer iterations than without it.

Is there any hope of having this tiny patch (it touches a total of 20 lines) 
accepted?

Thanks,

Carl

Some ranging fixes for volatile data

[Dima K. <gn...@di...>]

Hi.

Recently Ethan committed some fixes to make autoranging refreshes work
for volatile data in commit titled

 Partial axis ranges, e.g. [*:MAX] or [MIN:*], were not being handled
 correctly when refreshing volatile data.

Here are two patches to fix some more related issues. The first patch
applies similar logic to 3d plots. A test script to show the behavior
being fixed:

 set zrange [:3.5]
 splot '-' using 1:1:1 with linespoints ps 3 pt 7
 0
 1
 2
 3
 4
 5
 e
 refresh


The second patch handles the case of degenerate ranges. Demo script for
2d plots:

 plot '-' with linespoints
 0 1
 0 2
 refresh

and 3d plots:

 splot '-' with linespoints ps 3 pt 7
 0 1 2
 0 3 4
 refresh

Re: Meaning of trange in parametric plots

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

On Thursday, March 07, 2013 11:41:44 am Dima Kogan wrote:
> Hans-Bernhard Bröker <HBB...@t-...> writes:
> 
> > On 06.03.2013 22:52, Dima Kogan wrote:
> >> Hans-Bernhard Bröker <HBB...@t-...> writes:
> >
> >>> They can't be, because there is nu such thing as a parametric plot from
> >>> a data file.  Parametric mode is a property of function plots.
> >
> >> Hmmm. You're right; this doesn't make sense. In that case, should
> >> gnuplot be plotting anything at all? Would it be more appropriate for it
> >> to simply emit and error message and refuse to plot anything?
> >
> > What on earth should it do _that_ for?  There's nothing wrong there. 
> > Having parametric mode and trange set while you doing a pure data plot 
> > is just _irrelevant_, but not wrong.
> 
> In cases when the user is trying to do something that doesn't make sense
> it's far better to throw an error (or warning) than to silently do the
> wrong thing. I am now clear on why 'set parametric' is not connected to
> plots from files, so I wouldn't benefit from an error message here, but
> a new user may. That's all I was suggesting.

There is not, and should not be, any warning for setting a parameter in
advance of using it.  E.g. there's nothing odd about a script that selects 
a palette but doesn't use it until several plots later.  In general there's
nothing odd about loading a file containing your preferred defaults even
if only some of them apply to the plot you are about to make.
Choosing a customized set of default ranges is simply an example of this.

	Ethan

Re: Meaning of trange in parametric plots

[Dima K. <gn...@di...>]

Hans-Bernhard Bröker <HBB...@t-...> writes:

> On 06.03.2013 22:52, Dima Kogan wrote:
>> Hans-Bernhard Bröker <HBB...@t-...> writes:
>
>>> They can't be, because there is nu such thing as a parametric plot from
>>> a data file.  Parametric mode is a property of function plots.
>
>> Hmmm. You're right; this doesn't make sense. In that case, should
>> gnuplot be plotting anything at all? Would it be more appropriate for it
>> to simply emit and error message and refuse to plot anything?
>
> What on earth should it do _that_ for?  There's nothing wrong there. 
> Having parametric mode and trange set while you doing a pure data plot 
> is just _irrelevant_, but not wrong.

In cases when the user is trying to do something that doesn't make sense
it's far better to throw an error (or warning) than to silently do the
wrong thing. I am now clear on why 'set parametric' is not connected to
plots from files, so I wouldn't benefit from an error message here, but
a new user may. That's all I was suggesting.

dima

Re: buggy behaviour of svg+splot with image

[Sylwester A. <sa...@ig...>]

Dear All,

On 07/03/13 06:46, Daniel J Sebald wrote:
> On 03/06/2013 11:29 PM, sfeam (Ethan Merritt) wrote:
>> On Wednesday, 06 March 2013, Sylwester Arabas wrote:
>
>>> P.S. Is there any way to force gnuplot not to use external png files but
>>> instead draw the images pixel-by-pixel with svg rectangles as it was
>>> done in older versions of gnuplot?
>>
>> Yes.
>>      plot 'foo' with image failsafe

Thanks!

Best,
Sylwester

-- 
http://www.igf.fuw.edu.pl/~slayoo/

Re: buggy behaviour of svg+splot with image

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

On 03/06/2013 05:50 PM, Sylwester Arabas wrote:

> HTH,
> Sylwester
>
> P.S. Is there any way to force gnuplot not to use external png files but
> instead draw the images pixel-by-pixel with svg rectangles as it was
> done in older versions of gnuplot?

There may be something similar to what you are looking for, Sylwester. 
Browse these demos:

http://gnuplot.sourceforge.net/demo_4.6/pm3d.html

Dan

Re: buggy behaviour of svg+splot with image

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

On 03/06/2013 11:29 PM, sfeam (Ethan Merritt) wrote:
> On Wednesday, 06 March 2013, Sylwester Arabas wrote:

>> P.S. Is there any way to force gnuplot not to use external png files but
>> instead draw the images pixel-by-pixel with svg rectangles as it was
>> done in older versions of gnuplot?
>
> Yes.
>     plot 'foo' with image failsafe

I forgot about that.  Similar end result, easier syntax.

Dan

Re: buggy behaviour of svg+splot with image

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

On Wednesday, 06 March 2013, Sylwester Arabas wrote:
> Hi,
> 
> On 06/03/13 16:51, pl...@pi... wrote:
> > On 03/06/13 15:22, Mojca Miklavec wrote:
> >> On Wed, Mar 6, 2013 at 12:10 PM, Sylwester Arabas wrote:
> >>>
> >>> Then maybe issuing a warning before overwriting an existing png file
> >>> would be a solution?
> >>
> >> This would be problematic. Many people simply run the same plotting
> >> commands/scripts multiple times (either during development/improvement
> >> of graphs or to display measurement results for different data),
> >> *expecting* the files to be overwritten. I'm not using SVG, but for
> >> any format that I'm using, I would be annoyed if I would have to
> >> confirm overwriting files.
> 
> Wouldn't you be annoyed if you "simply run the same plotting 
> commands/scripts multiple times" with different data and different 
> output file specified, but get the data from just the last plot in all 
> of the output files? :)

Your complaint about incomplete documentation is reasonable.
The svg terminal should give an explanation for the 'name'
option similar to the one given by the canvas terminal.

> Basically, anything you plot with "splot with image" on an svg terminal 
> silently damages all svg files in the current directory previously 
> plotted "with image". Unfair.

Not really.  You just have to give a unique name to each
plot.  See, for example, the image demo:

   http://gnuplot.sourceforge.net/demo_svg_4.7/image.html

> P.S. Is there any way to force gnuplot not to use external png files but 
> instead draw the images pixel-by-pixel with svg rectangles as it was 
> done in older versions of gnuplot?

Yes.
   plot 'foo' with image failsafe

Re: buggy behaviour of svg+splot with image

[Sylwester A. <sa...@ig...>]

Hi,

On 06/03/13 16:51, pl...@pi... wrote:
> On 03/06/13 15:22, Mojca Miklavec wrote:
>> On Wed, Mar 6, 2013 at 12:10 PM, Sylwester Arabas wrote:
>>>
>>> Then maybe issuing a warning before overwriting an existing png file
>>> would be a solution?
>>
>> This would be problematic. Many people simply run the same plotting
>> commands/scripts multiple times (either during development/improvement
>> of graphs or to display measurement results for different data),
>> *expecting* the files to be overwritten. I'm not using SVG, but for
>> any format that I'm using, I would be annoyed if I would have to
>> confirm overwriting files.

Wouldn't you be annoyed if you "simply run the same plotting 
commands/scripts multiple times" with different data and different 
output file specified, but get the data from just the last plot in all 
of the output files? :)

$ cat full.gpi
set term svg
set palette negative
set view map
set output "full.svg"
splot '-' matrix with image notitle
1 1 1 1
1 1 1 1
1 1 1 1
1 1 1 1
e

$ cat half.gpi
set term svg
set palette negative
set view map
set output "half.svg"
splot '-' matrix with image notitle
0 0 0 0
0 0 0 0
1 1 1 1
1 1 1 1
e

$ gnuplot full.gpi
$ gnuplot half.gpi

Now both full.svg and half.svg contain the same image (half) even though 
the input data was different, and the output file was different!

Basically, anything you plot with "splot with image" on an svg terminal 
silently damages all svg files in the current directory previously 
plotted "with image". Unfair.

HTH,
Sylwester

P.S. Is there any way to force gnuplot not to use external png files but 
instead draw the images pixel-by-pixel with svg rectangles as it was 
done in older versions of gnuplot?

-- 
http://www.igf.fuw.edu.pl/~slayoo/

Re: Meaning of trange in parametric plots

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

On 06.03.2013 22:52, Dima Kogan wrote:
> Hans-Bernhard Bröker <HBB...@t-...> writes:

>> They can't be, because there is nu such thing as a parametric plot from
>> a data file.  Parametric mode is a property of function plots.

> Hmmm. You're right; this doesn't make sense. In that case, should
> gnuplot be plotting anything at all? Would it be more appropriate for it
> to simply emit and error message and refuse to plot anything?

What on earth should it do _that_ for?  There's nothing wrong there. 
Having parametric mode and trange set while you doing a pure data plot 
is just _irrelevant_, but not wrong.

Re: Meaning of trange in parametric plots

[Dima K. <gn...@di...>]

Hans-Bernhard Bröker <HBB...@t-...> writes:

> On 06.03.2013 22:27, Dima Kogan wrote:
>
>> I'm observing that trange settings are ignored when making parametric
>> plots from data files.
>
> They can't be, because there is nu such thing as a parametric plot from 
> a data file.  Parametric mode is a property of function plots.

Hmmm. You're right; this doesn't make sense. In that case, should
gnuplot be plotting anything at all? Would it be more appropriate for it
to simply emit and error message and refuse to plot anything?

dima

Re: Meaning of trange in parametric plots

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

On 06.03.2013 22:27, Dima Kogan wrote:

> I'm observing that trange settings are ignored when making parametric
> plots from data files.

They can't be, because there is nu such thing as a parametric plot from 
a data file.  Parametric mode is a property of function plots.

>   plot 'dat'
>
> with 'dat' containing
>
>   0 0
>   1 1
>   2 4
>   3 9
>   4 16
>   5 25

That file has two columns: one full of 'x' values, the other full of 'y' 
values.  What on earth would the t range have to do with plotting it?

> Here I see all the points being plotted, not limited at t=3, as I
> expected.

Your expectation is at odds with the meaning of the commands you're using.

Meaning of trange in parametric plots

[Dima K. <gn...@di...>]

Hi.

I'm observing that trange settings are ignored when making parametric
plots from data files.

This works as expected:

 set parametric
 set trange [-5:3]
 plot t,t*t

I see a parabola with x=[-5..3]


This is suprising, however:

 set parametric
 set trange [-5:3]
 plot 'dat'

with 'dat' containing

 0 0
 1 1
 2 4
 3 9
 4 16
 5 25

Here I see all the points being plotted, not limited at t=3, as I
expected. Is this intended behavior or a bug? If it's correct, then the
documentation should be expanded a bit to mention this detail. Should I
add this to the docs?

dima

Re: buggy behaviour of svg+splot with image

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

On 03/06/13 15:22, Mojca Miklavec wrote:
> On Wed, Mar 6, 2013 at 12:10 PM, Sylwester Arabas wrote:
>>
>> Then maybe issuing a warning before overwriting an existing png file
>> would be a solution?
>
> This would be problematic. Many people simply run the same plotting
> commands/scripts multiple times (either during development/improvement
> of graphs or to display measurement results for different data),
> *expecting* the files to be overwritten. I'm not using SVG, but for
> any format that I'm using, I would be annoyed if I would have to
> confirm overwriting files.
>
> Mojca
>

Agreed. No "are you sure" for God's sake.

and... yes I am sure that I'm sure that I don't want to be asked.

:)

Re: buggy behaviour of svg+splot with image

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

On Wed, Mar 6, 2013 at 12:10 PM, Sylwester Arabas wrote:
>
> Then maybe issuing a warning before overwriting an existing png file
> would be a solution?

This would be problematic. Many people simply run the same plotting
commands/scripts multiple times (either during development/improvement
of graphs or to display measurement results for different data),
*expecting* the files to be overwritten. I'm not using SVG, but for
any format that I'm using, I would be annoyed if I would have to
confirm overwriting files.

Mojca

Re: buggy behaviour of svg+splot with image

[Sylwester A. <sa...@ig...>]

Hi,

On 06/03/13 11:51, Christoph Bersch wrote:
> Am 06.03.2013 11:16, schrieb Sylwester Arabas:
>> Also, why not make it a default behaviour? It's quite tricky to find out
>> why you get same plots with different data :)
>
> the 'name' parameter is primarily used to name the plots in a svg file.
>
> If one would make this default behaviour (like it is done e.g. in lua
> terminal), one must also take care to encode the URI of the image file
> in the xlink:href part properly.

Then maybe issuing a warning before overwriting an existing png file 
would be a solution?

>>    >   I replaced the : by _ in the filename, because 'name' takes only
>>    >   alphanumeric characters and _. (Don't know why)
>>
>> While gnuplot does warn about e.g. a dot in the value of "name", it in
>> fact proceeds with creating the file correctly!:
>
> For me it does not (4.6.0 and CVS).

I'm using 4.6 patchlevel 0 from the Debian 4.6.0-8 package.

Best regards,
Sylwester

-- 
http://www.igf.fuw.edu.pl/~slayoo/

Re: buggy behaviour of svg+splot with image

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

Hi,

Am 06.03.2013 11:16, schrieb Sylwester Arabas:
>
> Also, why not make it a default behaviour? It's quite tricky to find out
> why you get same plots with different data :)

the 'name' parameter is primarily used to name the plots in a svg file.

If one would make this default behaviour (like it is done e.g. in lua 
terminal), one must also take care to encode the URI of the image file 
in the xlink:href part properly.

>
>   >  I replaced the : by _ in the filename, because 'name' takes only
>   >  alphanumeric characters and _. (Don't know why)
>
> While gnuplot does warn about e.g. a dot in the value of "name", it in
> fact proceeds with creating the file correctly!:

For me it does not (4.6.0 and CVS).

Best regards,
Christoph

Re: buggy behaviour of svg+splot with image

[Sylwester A. <sa...@ig...>]

Hi Christoph

On 06/03/13 09:47, Christoph Bersch wrote:
> Am 05.03.2013 22:04, schrieb Sylwester Arabas:
>> The problem is that both 21:55:23.svg and 21:55:26.svg include the same
>> gp_image_01.png file, while the plotted data could in principle be
>> different in the two svg files. Changing the prefix of the png file from
>> gp_image_ to something like 21:55:23.svg_image_ would fix the problem.
>
> you can use the 'name' option of the svg terminal:

Thanks a lot!

Perhaps it's worth discussing it in the help section in term/svg.trm.

Also, why not make it a default behaviour? It's quite tricky to find out 
why you get same plots with different data :)

 > I replaced the : by _ in the filename, because 'name' takes only
 > alphanumeric characters and _. (Don't know why)

While gnuplot does warn about e.g. a dot in the value of "name", it in 
fact proceeds with creating the file correctly!:

gnuplot> filename = 'figure_pc_tht_0.svg'
gnuplot> set term svg dynamic name filename
Terminal type set to 'svg'
                                    ^
          name must contain only alphanumerics or _
...

gnuplot> !ls *.png
...
figure_pc_tht_0.svg_image_03.png
...

Best,
Sylwester

-- 
http://www.igf.fuw.edu.pl/~slayoo/

Re: buggy behaviour of svg+splot with image

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

Hi,

Hi,

Am 05.03.2013 22:04, schrieb Sylwester Arabas:
>
> The problem is that both 21:55:23.svg and 21:55:26.svg include the same
> gp_image_01.png file, while the plotted data could in principle be
> different in the two svg files. Changing the prefix of the png file from
> gp_image_ to something like 21:55:23.svg_image_ would fix the problem.

you can use the 'name' option of the svg terminal:

filename = system("date +%X | tr : _")
set term svg name filename
set view map
set output filename.".svg"
splot '-' matrix with image notitle
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 1 1 0 0 0 2 0 0 0 3 3 0 0
0 0 1 0 1 0 2 0 2 0 3 0 3 0 0
0 0 1 1 0 0 2 0 2 0 3 0 0 0 0
0 0 1 0 1 0 2 0 2 0 3 0 0 0 0
0 0 1 1 0 0 2 0 2 0 0 3 3 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
e

I replaced the : by _ in the filename, because 'name' takes only 
alphanumeric characters and _. (Don't know why)

Christoph

buggy behaviour of svg+splot with image

[Sylwester A. <sa...@ig...>]

Hello,

The commands below exemplify a buggy behaviour of the svg terminal:


$ cat bug.gpi
set term svg
set view map
set output system("date +%X").".svg"
splot '-' matrix with image notitle
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 1 1 0 0 0 2 0 0 0 3 3 0 0
0 0 1 0 1 0 2 0 2 0 3 0 3 0 0
0 0 1 1 0 0 2 0 2 0 3 0 0 0 0
0 0 1 0 1 0 2 0 2 0 3 0 0 0 0
0 0 1 1 0 0 2 0 2 0 0 3 3 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
e
$ gnuplot bug.gpi
$ gnuplot bug.gpi
$ ls -1 *
21:55:23.svg
21:55:26.svg
bug.gpi
gp_image_01.png


The problem is that both 21:55:23.svg and 21:55:26.svg include the same 
gp_image_01.png file, while the plotted data could in principle be 
different in the two svg files. Changing the prefix of the png file from 
gp_image_ to something like 21:55:23.svg_image_ would fix the problem.

HTH,
Thanks,
Sylwester

-- 
http://www.igf.fuw.edu.pl/~slayoo/