5:54 p.m.
I'm seeing clipping of the y-axis label in my graphs.
Known problem?
Thanks,
Alan Isaac
1:48 p.m.
On Fri, 30 Oct 2009, Alan G Isaac wrote:
> I'm seeing clipping of the y-axis label in my graphs.
> Known problem?
On 10/30/2009 2:25 PM, Allin Cottrell wrote:
I've noticed that in some plots. Perhaps I should file a bug
report with gnuplot; that's not something that gretl itself
controls.
On the one hand, that makes sense to me.
Otoh, I'm not seeing this behavior in gnuplot...
(I have 4.2.6.)
Alan
5:58 p.m.
> On Fri, 30 Oct 2009, Alan G Isaac wrote:
> > I'm seeing clipping of the y-axis label in my graphs.
> > Known problem?
On 10/30/2009 2:25 PM, Allin Cottrell wrote:
> I've noticed that in some plots. Perhaps I should file a bug
> report with gnuplot; that's not something that gretl itself
> controls.
On 10/31/2009 9:48 AM, Alan G Isaac wrote:
On the one hand, that makes sense to me.
Otoh, I'm not seeing this behavior in gnuplot...
(I have 4.2.6.)
OK, this *is* at least partly gretl.
Apparently gretl has a short limit on string length
when using setinfo. So part of my ylabel string (which
I was setting with setinfo) is not being passed to
gnuplot. That explains the clipping on the right.
Can you provide a longer string?
But I still sometimes lose a one (?) pixel band
at the very left of the label.
I've checked that the pixels are really missing (that
it's not just a screen resolution issue) by saving the
file as PNG and resizing it. They are missing.
It is also not a font problem bc it happens only at
the beginning of the label. (E.g., I can get rid
of it by adding a space.)
Here is the more puzzling thing. Suppose I see this problem
(missing pixels) in a graph I have saved as a graph obejct.
Now I go to the icon view, pick Edit Plot Commands, and
without changing anything, I run the commands: I do not
see the problem! (Can I be sure this is using the version
of gnuplot that comes with gretl?)
Finally, I uncovered what I consider a bug. (?) If I use
setinfo to set a name, it is used as my ylabel, **even if**
I explicitly set a ylabel. This violates the specificity
principle, which should give priority to the most specific
request (the ylabel I set in a specific graph).
Thanks,
Alan
7:13 p.m.
On Sat, 31 Oct 2009, Alan G Isaac wrote:
Apparently gretl has a short limit on string length
when using setinfo.
32 characters including the terminating NUL.
So part of my ylabel string (which I was setting with setinfo)
is not being passed to gnuplot. That explains the clipping on
the right. Can you provide a longer string?
Will consider.
But I still sometimes lose a one (?) pixel band
at the very left of the label.
I've checked that the pixels are really missing (that
it's not just a screen resolution issue) by saving the
file as PNG and resizing it. They are missing.
It is also not a font problem bc it happens only at
the beginning of the label. (E.g., I can get rid
of it by adding a space.)
Here is the more puzzling thing. Suppose I see this problem
(missing pixels) in a graph I have saved as a graph obejct.
Now I go to the icon view, pick Edit Plot Commands, and
without changing anything, I run the commands: I do not
see the problem!
This is on Windows? The drivers are different in the two cases.
The cairo-based driver is used for gretl's PNG plots, but if you
send the plot commands to gnuplot that will be using the Windows
GDI driver. So if it's a gnuplot problem it looks like it's the
pngcairo driver.
(Can I be sure this is using the version
of gnuplot that comes with gretl?)
Yes, I think so.
Finally, I uncovered what I consider a bug. (?) If I use
setinfo to set a name, it is used as my ylabel, **even if**
I explicitly set a ylabel. This violates the specificity
principle, which should give priority to the most specific
request (the ylabel I set in a specific graph).
I'd agree that sounds like a bug. Are you setting the ylabel via
the GUI, or via extra commands passed to gretl's "gnuplot"
command?
Allin.
7:28 p.m.
On Sat, 31 Oct 2009, Allin Cottrell wrote:
On Sat, 31 Oct 2009, Alan G Isaac wrote:
> But I still sometimes lose a one (?) pixel band
> at the very left of the label.
>
> I've checked that the pixels are really missing (that
> it's not just a screen resolution issue) by saving the
> file as PNG and resizing it.
I said earlier that I'd seen some clipping of text myself, but now
that I sit down to try to replicate the problem, I can't. Could
you give an example?
Allin Cottrell
8:58 p.m.
New subject: missing pixels in ylabel
On 10/31/2009 3:28 PM, Allin Cottrell wrote:
I said earlier that I'd seen some clipping of text myself, but
now
that I sit down to try to replicate the problem, I can't. Could
you give an example?
Yes, I have actually had some trouble with replicability.
Try this.
nulldata 300
series s = normal()
setinfo s -n "Q"
wn1_l <- gnuplot s time -o {set title "Test"; }
wn1_l.show
I see missing pixels on the left side of the Q.
Interestingly, when I run this, I also see some
missing pixels at the bottom of the graph title.
Do you see what I see?
Alan
9:07 p.m.
New subject: missing pixels in ylabel
On Sat, 31 Oct 2009, Alan G Isaac wrote:
On 10/31/2009 3:28 PM, Allin Cottrell wrote:
> I said earlier that I'd seen some clipping of text myself, but now
> that I sit down to try to replicate the problem, I can't. Could
> you give an example?
>
Yes, I have actually had some trouble with replicability.
Try this.
nulldata 300
series s = normal()
setinfo s -n "Q"
wn1_l <- gnuplot s time -o {set title "Test"; }
wn1_l.show
I see missing pixels on the left side of the Q.
Interestingly, when I run this, I also see some
missing pixels at the bottom of the graph title.
Do you see what I see?
On linux, no, I can't see anything wrong with the plot.
I'll have to try testing on Windows.
Allin.
8:35 p.m.
On Sat, 31 Oct 2009, Alan G Isaac wrote:
> Apparently gretl has a short limit on string length
> when using setinfo.
On 10/31/2009 3:13 PM, Allin Cottrell wrote:
32 characters including the terminating NUL.
On Sat, 31 Oct 2009, Alan G Isaac wrote:
> So part of my ylabel string (which I was setting with setinfo)
> is not being passed to gnuplot. That explains the clipping on
> the right. Can you provide a longer string?
On 10/31/2009 3:13 PM, Allin Cottrell wrote:
Will consider.
OK, thanks. I'd say I want a longer ylabel than
32 characters about half the time, but almost
never more than 64 characters.
Cheers,
Alan
8:43 p.m.
New subject: missing pixels at beginning of ylabel
On Sat, 31 Oct 2009, Alan G Isaac wrote:
> Here is the more puzzling thing. Suppose I see this problem
> (missing pixels) in a graph I have saved as a graph obejct.
> Now I go to the icon view, pick Edit Plot Commands, and
> without changing anything, I run the commands: I do not
> see the problem!
On 10/31/2009 3:13 PM, Allin Cottrell wrote:
This is on Windows? The drivers are different in the two cases.
The cairo-based driver is used for gretl's PNG plots, but if you
send the plot commands to gnuplot that will be using the Windows
GDI driver. So if it's a gnuplot problem it looks like it's the
pngcairo driver.
OK, let me try to be a bit more careful.
I am running gretl 1.8.4 under Vista (64bit).
I do not use the snapshots because I want to
be sure I see what my students see.
When I create a gretl graph object and "show" it,
I see the missing pixels problem. (If I then save
the graph in PNG format and view that, then I *still*
see the missing pixels.) However if I open the
graph object code (menu: Edit Plot Commands) and
click the "run" icon, the gnuplot graph displays
without the lost pixels! So what is different
between the two gnuplot windows?
Thanks,
Alan
9:18 p.m.
New subject: missing pixels at beginning of ylabel
On Sat, 31 Oct 2009, Alan G Isaac wrote:
I am running gretl 1.8.4 under Vista (64bit).
I do not use the snapshots because I want to
be sure I see what my students see.
1.8.5 is the most recent release, and it incorporates an update to
the included version of CVS gnuplot (several months' worth of
fixes, as I recall), so it might be worth re-trying using that.
When I create a gretl graph object and "show" it,
I see the missing pixels problem.
"show" -> gretl-controlled GTK window holding a PNG graphic
created by gnuplot's PNG driver. There's more than one gnuplot
driver that can do PNG, in general, but the wgnuplot.exe supplied
with gretl for Windows always uses the newer cairo-based PNG
driver.
However if I open the graph object code (menu: Edit Plot
Commands) and click the "run" icon...
"run" -> the display of the graph is handed off to gnuplot itself,
and on MS Windows this means that the Windows GDI driver gets
used. Such a graph window is not controlled by gretl and doesn't
offer the gretl graph-editing "extras".
Allin
3:28 a.m.
New subject: missing pixels at beginning of ylabel
On 10/31/2009 5:18 PM, Allin Cottrell wrote:
1.8.5 is the most recent release, and it incorporates an update to
the included version of CVS gnuplot (several months' worth of
fixes, as I recall), so it might be worth re-trying using that.
No change.
Cheers,
Alan
3:45 p.m.
New subject: missing pixels at beginning of ylabel
1. I'm having a some trouble replicating this problem on a recent
gnuplot download,
and I'm wondering if the gretl version of gnuplot (for Windows) compiles
in support
for pngcairo and if that takes over as the PNG backend for the gretl
version?
(If I use a downloaded gretl, the PNG back end does not give me the problem,
but if I change pngcairo to png I still get the problem with gretl.)
2. Just out of curiosity, how did you get the help to work in gretl's
gnuplot
(I'm on Vista), and is that something you could give back to gnuplot?
Alan
4:20 p.m.
New subject: missing pixels at beginning of ylabel
On Sun, 1 Nov 2009, Alan G Isaac wrote:
1. I'm having a some trouble replicating this problem on a
recent gnuplot download, and I'm wondering if the gretl version
of gnuplot (for Windows) compiles in support for pngcairo and if
that takes over as the PNG backend for the gretl version? (If I
use a downloaded gretl, the PNG back end does not give me the
problem, but if I change pngcairo to png I still get the problem
with gretl.)
This can get a bit confusing. Historically, there are two
back-ends for producing PNG in gnuplot (maybe 3 if you go back far
enough?). One uses the libgd graphics library, and one (a newer
addition) uses the pango and cairo libraries. The wgnuplot.exe
that ships with gretl uses the cairo-based PNG writer exclusively.
(It does not support libgd, which is a mess code-wise and has poor
support for font selection.)
If you have a build of gnuplot that includes libgd support then
the gnuplot command "set term png" uses the libgd-based writer,
and "set term pngcairo" uses the cairo-based one, if available. If
libgd support is not present but cairo support is, then both "set
term png" and "set term pngcairo" have the same effect: use the
cairo driver.
2. Just out of curiosity, how did you get the help to work in
gretl's gnuplot (I'm on Vista), and is that something you could
give back to gnuplot?
Hmm, I wasn't aware of doing anything special. I just built the
help using the tools in the gnuplot source tree (slightly adapted
for a cross-build on Linux), plus Microsoft's hcw.exe (running
under wine) to compile the final .hlp file.
Allin
4:29 p.m.
New subject: missing pixels at beginning of ylabel
On 11/1/2009 11:20 AM, Allin Cottrell wrote:
does not support libgd ... If
libgd support is not present but cairo support is, then both "set
term png" and "set term pngcairo" have the same effect: use the
cairo driver.
So it is looking likely that there is a bug in the cairo driver,
if I understand you correctly.
Alan
12:26 a.m.
New subject: missing pixels at beginning of ylabel
As I said previously (and as I now confirm after more
experimentation), I'm not able to detect any missing pixels in
gretl-gnuplot PNG plots on Linux (this is using the pngcairo
terminal with gnuplot 4.3 CVS).
But I've now done some testing on Windows (Vista) and can see a
little clipping of text here and there, partly depending on the
font selected. For example, I run a trimmed version of the script
I cited earlier:
nulldata 300
series s = normal()
gfoo <- gnuplot s time -o {set ylabel "My Y Label";}
gfoo.show
When using the Verdana font at 8 points, there's a slight
glitch in the "150" tic-mark on the x-axis: the right extremity of
the '0' in "150" is missing. This corrects itself if I choose
Verdana 9 or Tahoma 8.
Then if I add a title at the top of the graph including the letter
'Q', the tail of the Q is truncated (the last row of pixels seems
to be lopped off).
I'm not sure if this is really worth bothering about -- since PNG
is not the format of choice for "production quality" graphics --
but it does appear that there's a teensy bug somewhere in the
implementations of pango and/or cairo for MS Windows, with respect
to font-handling.
Allin.
1:52 a.m.
New subject: missing pixels at beginning of ylabel
On 11/1/2009 7:26 PM, Allin Cottrell wrote:
I'm not sure if this is really worth bothering about -- since
PNG
is not the format of choice for "production quality" graphics --
but it does appear that there's a teensy bug somewhere in the
implementations of pango and/or cairo for MS Windows, with respect
to font-handling.
Hi Allin,
I would urge a different perspective. Here is why.
This is not just one possible back end. This is the back end that
gretl uses to display it graphical output. Thus the default face
of gretl to the Windows world looks less than professional when
it comes to the graphics. I think that is more than unfortunate
for such a fine package.
I realize that this bug seems to lead outside of gretl, but I would
hope that it would at least produce a bug report that leads to
eventual action. I've done about what I'm capable of in tracking
this, but I'm willing to follow other paths if you have suggestions.
Hope that makes sense,
Alan
11:29 a.m.
New subject: missing pixels at beginning of ylabel
Hi,
I haven't followed the details of this thread, I just want to confirm
that I have seen this "clipping" problem myself quite often. Since I use
gretl both on Linux and Windows I can't remember on which platform that was.
One of the reasons why I didn't report it earlier was that with the
problems that gretl had producing good pdf and eps files, this problem
was second-order to me. (Now that gretl does a much better job at pdf
and eps, maybe that's become different.)
I agree with Allin it's not a show-stopper. But I also agree with Alan
it's a bug. (hey your names together are a bit confusing, will you have
more list discussions like that? maybe we should give you aliases then :-)
If I can help with the diagnosis or testing (cross-platform maybe or
whatever) I'm happy to do it.
cheers,
sven
Alan G Isaac schrieb:
On 11/1/2009 7:26 PM, Allin Cottrell wrote:
> I'm not sure if this is really worth bothering about -- since PNG
> is not the format of choice for "production quality" graphics --
> but it does appear that there's a teensy bug somewhere in the
> implementations of pango and/or cairo for MS Windows, with respect
> to font-handling.
>
Hi Allin,
I would urge a different perspective. Here is why.
This is not just one possible back end. This is the back end that
gretl uses to display it graphical output. Thus the default face
of gretl to the Windows world looks less than professional when
it comes to the graphics. I think that is more than unfortunate
for such a fine package.
I realize that this bug seems to lead outside of gretl, but I would
hope that it would at least produce a bug report that leads to
eventual action. I've done about what I'm capable of in tracking
this, but I'm willing to follow other paths if you have suggestions.
Hope that makes sense,
Alan
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
2 p.m.
New subject: pdfcairo
On Mon, 2 Nov 2009, Alan G Isaac wrote:
On 11/2/2009 6:29 AM, Sven Schreiber wrote:
> pdf and eps files
That reminds me of another question: if I use
gretl's gnuplot and use
set terminal pdfcairo
I get no usuable output. Should this work?
Yes, of course. What's wrong with the output? And what happens
if you click on a graph, select "Save as PDF", and try previewing
the output? Or if you do, in gretl,
gnuplot <whatever> --output=foo.pdf
Allin.
2:30 p.m.
New subject: pdfcairo
On 11/2/2009 9:00 AM, Allin Cottrell wrote:
And what happens
if you click on a graph, select "Save as PDF", and try previewing
the output?
Perfect output, including all fonts.
If I understand you, this is alos using cairo, right?
(This should be a clue about the PNG bug.)
So I must be misunderstanding something. If I try to produce
PDF as follows, it fails. (White background, nothing else is viewable.)
I go to the icon view to edit the graph and change
#set term pngcairo font "verdana,8" size 680,400
to
set term pdfcairo font "verdana,8" size 680,400
set output 'c:\temp\temp.pdf'
Unfortunately, the pdfcairo terminal is not documented
in the help, so I'm suppose I have the wrong syntax.
Alan
3:21 p.m.
New subject: pdfcairo
On Mon, 2 Nov 2009, Alan G Isaac wrote:
On 11/2/2009 9:00 AM, Allin Cottrell wrote:
> And what happens
> if you click on a graph, select "Save as PDF", and try previewing
> the output?
Perfect output, including all fonts.
If I understand you, this is alos using cairo, right?
(This should be a clue about the PNG bug.)
So I must be misunderstanding something. If I try to produce
PDF as follows, it fails. (White background, nothing else is viewable.)
I go to the icon view to edit the graph and change
#set term pngcairo font "verdana,8" size 680,400
to
set term pdfcairo font "verdana,8" size 680,400
Ah, that calls for a plot that is 680 inches by 400 inches.
PDF and EPS don't go by pixels for sizing.
Allin.
3:47 p.m.
New subject: pdfcairo
On 11/2/2009 10:21 AM, Allin Cottrell wrote:
Ah, that calls for a plot that is 680 inches by 400 inches.
PDF and EPS don't go by pixels for sizing.
Aha, ok, I had guessed it would use points, not inches.
(Inches!?) So using a reasonable value, I get perfect output
using the pdfcairo terminal.
I took this problem onto the gnuplot newsgroup and got the
following question/suggestion.
Is your executable linked against shared libraries (*.dll) for pango
and pangocairo? If so, I'd try looking for other versions. If it is
a statically linked executable built by someone else, then I think you
will need to involve them in the debugging.
Thanks,
Alan
1:56 p.m.
New subject: missing pixels at beginning of ylabel
On Mon, 2 Nov 2009, Sven Schreiber wrote:
I haven't followed the details of this thread, I just want to
confirm
that I have seen this "clipping" problem myself quite often. Since I use
gretl both on Linux and Windows I can't remember on which
platform that was...
I agree with Allin it's not a show-stopper. But I also agree
with Alan it's a bug.
Yes. I'll try following this up. It's tricky because I don't know
where in the stack of gnuplot/pango/cairo the issue lies, but I
guess the gnuplot list is the place to start.
If I can help with the diagnosis or testing (cross-platform maybe or
whatever) I'm happy to do it.
Thanks. If I can come up with a good test rig maybe I'll ask
people to try generating some PNGs on Windows.
Allin.
8:47 p.m.
On Sat, 31 Oct 2009, Alan G Isaac wrote:
> If I use
> setinfo to set a name, it is used as my ylabel, **even if**
> I explicitly set a ylabel. This violates the specificity
> principle, which should give priority to the most specific
> request (the ylabel I set in a specific graph).
On 10/31/2009 3:13 PM, Allin Cottrell wrote:
I'd agree that sounds like a bug. Are you setting the ylabel
via
the GUI, or via extra commands passed to gretl's "gnuplot"
command?
The latter.
I use setinfo right after I create the variable.
This gives me what I consider to be a "default" ylabel.
In the case under discussion, I later create a graph where
I want a different label, so I add
{set ylabel "My New Label";}
to my gnuplot command, but it fails to override that "default".
Hope that's clearer,
Alan
4:50 p.m.
New subject: setting ylabel (was Re: unwanted clipping)
On Sat, 31 Oct 2009, Alan G Isaac wrote:
> On Sat, 31 Oct 2009, Alan G Isaac wrote:
> > If I use setinfo to set a name, it is used as my ylabel,
> > **even if** I explicitly set a ylabel. This violates the
> > specificity principle, which should give priority to the
> > most specific request (the ylabel I set in a specific
> > graph).
On 10/31/2009 3:13 PM, Allin Cottrell wrote:
> I'd agree that sounds like a bug. Are you setting the ylabel via
> the GUI, or via extra commands passed to gretl's "gnuplot"
> command?
The latter.
I use setinfo right after I create the variable.
This gives me what I consider to be a "default" ylabel.
In the case under discussion, I later create a graph where
I want a different label, so I add
{set ylabel "My New Label";}
to my gnuplot command, but it fails to override that "default".
Hmm, if I run this script:
nulldata 300
series s = normal()
setinfo s -n "Q"
g1 <- gnuplot s time -o
g2 <- gnuplot s time -o {set ylabel "My New Label";}
g1.show
g2.show
then the y-axis labels I see are "Q" and "My New Label" in g1 and
g2 respectively.
Allin
6031
days inactive
6034
days old
25 comments
3 participants
participants (3)
-
Alan G Isaac -
Allin Cottrell -
Sven Schreiber