Menu
▾
▴
gnuplot-beta
|
From: Benjamin L. <bj...@gm...> - 2011-02-04 09:17:43
|
Hello list, I ran into another strange behviour with the windows terminal and enhanced text. With a 4.5.0 CVS snapshot build, when I execute set term windows enhanced set ylabel "something in mm^2" plot [0:2*pi] sin(x) with linespoints the ylabel is placed horizontally at the top left corner, however if I do instead set tem windows enhanced plot [0:2*pi] sin(x) with linespoints set ylabel "something in mm^2" replot it works as expected. I tracked it down to do_plot() in graphics.c at line 1632 deciding that the terminal can't do rotated text. do_plot() decides so, because WIN_text_angle (in win.trm) returnes FALSE, because graphwin.rotate is FALSE. Now graphwin.rotate is set in MakeFonts() in wgraph.c, which determines, whether the font in question supports being rotated. MakeFonts() in turn is called (among others) by GraphChangeFont() which itself is called from drawgraph() with the OP Code W_font. Ok, so on startup, when the terminal is initialized, graphwin.rotate is set to TRUE (which is correct), but it gets reset to FALSE during execution. This happens, because GraphChangeFont() is called with an empty font name (not a NULL pointer, but the empty string ""). MakeFonts(), when presented with a font name which is empty, resets graphwin.rotate to FALSE. And at this point I got unsure as to what is the correct way to fix this problem. Solution 1) GraphChangeFont() should test whether the font name is not empty, and only then really change the font (i.e. silently ignore empty font names) Solution 2) drawgraph() should only call GraphChangeFont() if the font name is not empty (i.e. silently ignore W_font commands with empty font names) Solution 3) GraphChangeFont() should not be called with an empty font name in the first place. Such a call is found in WIN_set_font (win.trm) when the fontname is NULL. Is this correct? And WIN_set_font(NULL) is called from within WIN_options() with the remark "font initialization". Is this correct, too? Solution 4) deal with it in MakeFonts() directly. benjamin |
|
From: sfeam (E. Merritt) <eam...@gm...> - 2011-02-04 16:39:15
|
On Friday, February 04, 2011, Benjamin Lindner wrote: > Hello list, > > I ran into another strange behviour with the windows terminal and enhanced text. > With a 4.5.0 CVS snapshot build, when I execute > > set term windows enhanced > set ylabel "something in mm^2" > plot [0:2*pi] sin(x) with linespoints > > the ylabel is placed horizontally at the top left corner, however if I > do instead > > set tem windows enhanced > plot [0:2*pi] sin(x) with linespoints > set ylabel "something in mm^2" > replot > > it works as expected. > > I tracked it down to do_plot() in graphics.c at line 1632 deciding > that the terminal can't do rotated text. > do_plot() decides so, because WIN_text_angle (in win.trm) returnes > FALSE, because graphwin.rotate is FALSE. > Now graphwin.rotate is set in MakeFonts() in wgraph.c, which > determines, whether the font in question supports being rotated. > MakeFonts() in turn is called (among others) by GraphChangeFont() > which itself is called from drawgraph() with the OP Code W_font. > > Ok, so on startup, when the terminal is initialized, graphwin.rotate > is set to TRUE (which is correct), but it gets reset to FALSE during > execution. > This happens, because GraphChangeFont() is called with an empty font > name (not a NULL pointer, but the empty string ""). MakeFonts(), when > presented with a font name which is empty, resets graphwin.rotate to > FALSE. It should not do that. An empty string means "restore the default font". So unless the default font is for some reason non-rotatable, WIN_text_angle should always return TRUE. Ethan > And at this point I got unsure as to what is the correct way to fix > this problem. > > Solution 1) > GraphChangeFont() should test whether the font name is not empty, and > only then really change the font (i.e. silently ignore empty font > names) > > Solution 2) > drawgraph() should only call GraphChangeFont() if the font name is not > empty (i.e. silently ignore W_font commands with empty font names) > > Solution 3) > GraphChangeFont() should not be called with an empty font name in the > first place. > Such a call is found in WIN_set_font (win.trm) when the fontname is > NULL. Is this correct? > And WIN_set_font(NULL) is called from within WIN_options() with the > remark "font initialization". Is this correct, too? > > Solution 4) > deal with it in MakeFonts() directly. > > benjamin > > ------------------------------------------------------------------------------ > The modern datacenter depends on network connectivity to access resources > and provide services. The best practices for maximizing a physical server's > connectivity to a physical network are well understood - see how these > rules translate into the virtual world? > http://p.sf.net/sfu/oracle-sfdevnlfb > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > |
|
From: Benjamin L. <bj...@gm...> - 2011-02-07 08:07:58
|
>> This happens, because GraphChangeFont() is called with an empty font
>> name (not a NULL pointer, but the empty string ""). MakeFonts(), when
>> presented with a font name which is empty, resets graphwin.rotate to
>> FALSE.
>
> It should not do that.
> An empty string means "restore the default font".
> So unless the default font is for some reason non-rotatable,
> WIN_text_angle should always return TRUE.
Yes, on the high-level interface, true. But MakeFonts() is way down
low-level in the windows terminal.
WIN_set_text("") handles the reset-to-default-font action.
So actually MakeFonts() should never be presented with an empty font
name, only the terminal's default font name.
benjamin
|
|
From: Ethan A M. <sf...@us...> - 2011-02-04 17:53:38
|
On Friday, February 04, 2011 01:17:36 am Benjamin Lindner wrote: > Hello list, > > I ran into another strange behviour with the windows terminal and enhanced text. > With a 4.5.0 CVS snapshot build, when I execute > > set term windows enhanced > set ylabel "something in mm^2" > plot [0:2*pi] sin(x) with linespoints > > the ylabel is placed horizontally at the top left corner, however if I > do instead I should note that I cannot reproduce this bug using Tatsuro Matsuoka's CVS snapshot from 18-Jan-2011 running under wine. So it may or may not be an actual code problem as opposed to a configuration problem. Ethan > > set tem windows enhanced > plot [0:2*pi] sin(x) with linespoints > set ylabel "something in mm^2" > replot > > it works as expected. > |
|
From: Tatsuro M. <tma...@ya...> - 2011-02-05 17:07:19
|
Hello
--- Ethan A Merritt wrote:
> I should note that I cannot reproduce this bug using Tatsuro Matsuoka's CVS
> snapshot from 18-Jan-2011 running under wine. So it may or may not be an
> actual code problem as opposed to a configuration problem.
>
> Ethan
***********Benajamin wrote
For the windows terminal, when using rotated enhanced text (e.g. for
the ylabel) the text positioning is buggy.
This manifests itself with either sub/superscripts or font changes
(e.g. something like "pressure in N/mm^2" or "height in {/Symbol m}m")
- see the testcase below
**************************
I have confirmed what Benjamin suggested using my cvs binary (2011-01-25).
Regards
Tatsuro
--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/
|
|
From: sfeam (E. Merritt) <eam...@gm...> - 2011-02-05 18:46:47
|
On Saturday, February 05, 2011, Tatsuro MATSUOKA wrote:
> Hello
>
> --- Ethan A Merritt wrote:
> > I should note that I cannot reproduce this bug using Tatsuro Matsuoka's CVS
> > snapshot from 18-Jan-2011 running under wine. So it may or may not be an
> > actual code problem as opposed to a configuration problem.
> >
> > Ethan
> ***********Benajamin wrote
> For the windows terminal, when using rotated enhanced text (e.g. for
> the ylabel) the text positioning is buggy.
> This manifests itself with either sub/superscripts or font changes
> (e.g. something like "pressure in N/mm^2" or "height in {/Symbol m}m")
> - see the testcase below
> **************************
>
> I have confirmed what Benjamin suggested using my cvs binary (2011-01-25).
>
> Regards
>
> Tatsuro
OK. So I will have to leave it to you guys to figure out what the problem
is, since it doesn't show up on my linux+wine setup.
Does any recent MSWindows version ever provide a font that truly cannot
be rotated? It may be that test and the flag for rotatable fonts is
obsolete, and the corrsponding section of code in the routine MakeFonts()
is no longer needed.
If that is true, the simplest fix may be to change the first line of
MakeFonts() so that it always sets lpgw->rotate = TRUE;
|
|
From: Tatsuro M. <tma...@ya...> - 2011-02-05 19:31:54
|
Hello
What Bejhamin suggested is not rotation it self. Relative positioning enhanced text.
In the example script,
position of {/Symbol m} relative position to other text strange. Relative position of {/Symbol m} to
other text item is changed when resizing plot windows in y direction.
Please see
http://www.geocities.jp/tmgpltwin/Files/Files.html#0052
0052 20110206_01.png
0053 20110206_02.png
For the label in x direction does not suffer from such error.
Regards
Tatsuro
> On Saturday, February 05, 2011, Tatsuro MATSUOKA wrote:
> > Hello
> >
> > --- Ethan A Merritt wrote:
> > > I should note that I cannot reproduce this bug using Tatsuro Matsuoka's CVS
> > > snapshot from 18-Jan-2011 running under wine. So it may or may not be an
> > > actual code problem as opposed to a configuration problem.
> > >
> > > Ethan
> > ***********Benajamin wrote
> > For the windows terminal, when using rotated enhanced text (e.g. for
> > the ylabel) the text positioning is buggy.
> > This manifests itself with either sub/superscripts or font changes
> > (e.g. something like "pressure in N/mm^2" or "height in {/Symbol m}m")
> > - see the testcase below
> > **************************
> >
> > I have confirmed what Benjamin suggested using my cvs binary (2011-01-25).
> >
> > Regards
> >
> > Tatsuro
>
> OK. So I will have to leave it to you guys to figure out what the problem
> is, since it doesn't show up on my linux+wine setup.
>
> Does any recent MSWindows version ever provide a font that truly cannot
> be rotated? It may be that test and the flag for rotatable fonts is
> obsolete, and the corrsponding section of code in the routine MakeFonts()
> is no longer needed.
>
> If that is true, the simplest fix may be to change the first line of
> MakeFonts() so that it always sets lpgw->rotate = TRUE;
>
--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/
|
|
From: Tatsuro M. <tma...@ya...> - 2011-02-05 19:50:54
|
Hello
Sorry.
What I saw is not the same as the Beenjamin.
Relative position problem also occur in x axis.
Anyway there are some problems in enhaced text in the windows terminal.
Regards
Tatsuro
--- Tatsuro MATSUOKA wrote:
> Hello
>
> What Bejhamin suggested is not rotation it self. Relative positioning enhanced text.
>
> In the example script,
> position of {/Symbol m} relative position to other text strange. Relative position of {/Symbol
> m} to
> other text item is changed when resizing plot windows in y direction.
>
> Please see
>
> http://www.geocities.jp/tmgpltwin/Files/Files.html#0052
> 0052 20110206_01.png
> 0053 20110206_02.png
>
> For the label in x direction does not suffer from such error.
>
> Regards
>
> Tatsuro
>
> > On Saturday, February 05, 2011, Tatsuro MATSUOKA wrote:
> > > Hello
> > >
> > > --- Ethan A Merritt wrote:
> > > > I should note that I cannot reproduce this bug using Tatsuro Matsuoka's CVS
> > > > snapshot from 18-Jan-2011 running under wine. So it may or may not be an
> > > > actual code problem as opposed to a configuration problem.
> > > >
> > > > Ethan
> > > ***********Benajamin wrote
> > > For the windows terminal, when using rotated enhanced text (e.g. for
> > > the ylabel) the text positioning is buggy.
> > > This manifests itself with either sub/superscripts or font changes
> > > (e.g. something like "pressure in N/mm^2" or "height in {/Symbol m}m")
> > > - see the testcase below
> > > **************************
> > >
> > > I have confirmed what Benjamin suggested using my cvs binary (2011-01-25).
> > >
> > > Regards
> > >
> > > Tatsuro
> >
> > OK. So I will have to leave it to you guys to figure out what the problem
> > is, since it doesn't show up on my linux+wine setup.
> >
> > Does any recent MSWindows version ever provide a font that truly cannot
> > be rotated? It may be that test and the flag for rotatable fonts is
> > obsolete, and the corrsponding section of code in the routine MakeFonts()
> > is no longer needed.
> >
> > If that is true, the simplest fix may be to change the first line of
> > MakeFonts() so that it always sets lpgw->rotate = TRUE;
> >
>
>
> --------------------------------------
> Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
> http://pr.mail.yahoo.co.jp/ie8/
>
> ------------------------------------------------------------------------------
> The modern datacenter depends on network connectivity to access resources
> and provide services. The best practices for maximizing a physical server's
> connectivity to a physical network are well understood - see how these
> rules translate into the virtual world?
> http://p.sf.net/sfu/oracle-sfdevnlfb
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>
--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/
|
|
From: Tatsuro M. <tma...@ya...> - 2011-02-05 20:04:12
|
Sorry I have confused the thread. http://old.nabble.com/Enhanced-rotated-text-incorrectly-positioned-for-windows-terminal-td30835684.html The problem I found is same as that pointed the above. The problem seemed to be solved the above problem. For, http://old.nabble.com/ylabel-not-rotated-for-enhanced-windows-terminal-td30842940.html I have confirmed that no rotation problems occured. Sorry for the noise. Regards --- Tatsuro MATSUOKA wrote: > Hello > > Sorry. > What I saw is not the same the Beenjamin. > Relative position problem also occur in x axis. > > Anyway there are some problems in enhaced text in the windows terminal. > > Regards > > Tatsuro > > --- Tatsuro MATSUOKA wrote: > > > Hello > > > > What Bejhamin suggested is not rotation it self. Relative positioning enhanced text. > > > > In the example script, > > position of {/Symbol m} relative position to other text strange. Relative position of > {/Symbol > > m} to > > other text item is changed when resizing plot windows in y direction. > > > > Please see > > > > http://www.geocities.jp/tmgpltwin/Files/Files.html#0052 > > 0052 20110206_01.png > > 0053 20110206_02.png > > > > For the label in x direction does not suffer from such error. > > > > Regards > > > > Tatsuro > > > > > On Saturday, February 05, 2011, Tatsuro MATSUOKA wrote: > > > > Hello > > > > > > > > --- Ethan A Merritt wrote: > > > > > I should note that I cannot reproduce this bug using Tatsuro Matsuoka's CVS > > > > > snapshot from 18-Jan-2011 running under wine. So it may or may not be an > > > > > actual code problem as opposed to a configuration problem. > > > > > > > > > > Ethan > > > > ***********Benajamin wrote > > > > For the windows terminal, when using rotated enhanced text (e.g. for > > > > the ylabel) the text positioning is buggy. > > > > This manifests itself with either sub/superscripts or font changes > > > > (e.g. something like "pressure in N/mm^2" or "height in {/Symbol m}m") > > > > - see the testcase below > > > > ************************** > > > > > > > > I have confirmed what Benjamin suggested using my cvs binary (2011-01-25). > > > > > > > > Regards > > > > > > > > Tatsuro > > > > > > OK. So I will have to leave it to you guys to figure out what the problem > > > is, since it doesn't show up on my linux+wine setup. > > > > > > Does any recent MSWindows version ever provide a font that truly cannot > > > be rotated? It may be that test and the flag for rotatable fonts is > > > obsolete, and the corrsponding section of code in the routine MakeFonts() > > > is no longer needed. > > > > > > If that is true, the simplest fix may be to change the first line of > > > MakeFonts() so that it always sets lpgw->rotate = TRUE; > > > > > > > > > -------------------------------------- > > Get the new Internet Explorer 8 optimized for Yahoo! JAPAN > > http://pr.mail.yahoo.co.jp/ie8/ > > > > ------------------------------------------------------------------------------ > > The modern datacenter depends on network connectivity to access resources > > and provide services. The best practices for maximizing a physical server's > > connectivity to a physical network are well understood - see how these > > rules translate into the virtual world? > > http://p.sf.net/sfu/oracle-sfdevnlfb > > _______________________________________________ > > gnuplot-beta mailing list > > gnu...@li... > > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > > > > > -------------------------------------- > Get the new Internet Explorer 8 optimized for Yahoo! JAPAN > http://pr.mail.yahoo.co.jp/ie8/ > -------------------------------------- Get the new Internet Explorer 8 optimized for Yahoo! JAPAN http://pr.mail.yahoo.co.jp/ie8/ |
|
From: Benjamin L. <bj...@gm...> - 2011-02-07 08:22:44
|
>
> OK. So I will have to leave it to you guys to figure out what the problem
> is, since it doesn't show up on my linux+wine setup.
Here we go:
The offending command happens in WIN_set_text(NULL), which places a
W_font command in the queue with an empty font name. Removing this one
solves the problem
diff --git a/src/term/win.trm b/src/term/win.trm
--- a/src/term/win.trm
+++ b/src/term/win.trm
@@ -730,7 +730,6 @@
int fontsize;
if (font == NULL) {
- GraphOp(&graphwin, W_font, 0, 0, "");
strcpy(WIN_font, graphwin.deffontname);
WIN_fontsize = graphwin.deffontsize;
return TRUE;
I am not sure this command should be there anyway, I don't really see
its purpose.
Tatsuro can you check if this also fixes the problem for you?
Second proposal:
Make GraphChangeFonts() more robust like:
diff --git a/src/src/win/wgraph.c b/src/src/win/wgraph.c
--- a/src/src/win/wgraph.c
+++ b/src/src/win/wgraph.c
@@ -2613,9 +2613,10 @@
{
int newfontsize;
bool remakefonts = FALSE;
+ bool font_is_not_empty = (font != NULL) && (font[0] != '\0');
newfontsize = (fontsize != 0) ? fontsize : lpgw->deffontsize;
- if (font != NULL) {
+ if (font_is_not_empty) {
remakefonts = (strcmp(lpgw->fontname, font) != 0) ||
(newfontsize != lpgw->fontsize);
} else {
remakefonts = (strcmp(lpgw->fontname, lpgw->deffontname) != 0)
|| (newfontsize != lpgw->fontsize);
@@ -2623,7 +2624,7 @@
if (remakefonts) {
lpgw->fontsize = newfontsize;
- strcpy(lpgw->fontname, (font) ? font : lpgw->deffontname);
+ strcpy(lpgw->fontname, font_is_not_empty ? font : lpgw->deffontname);
DestroyFonts(lpgw);
MakeFonts(lpgw, &rect, hdc);
This would ensure the behaviour of "" meaning "the default font" on
the low level terminal code.
Could you check this also Tatsuro?
I'm inclined to the first solution, but I'd like a second opinion on this.
> Does any recent MSWindows version ever provide a font that truly cannot
> be rotated? It may be that test and the flag for rotatable fonts is
> obsolete, and the corrsponding section of code in the routine MakeFonts()
> is no longer needed.
>
> If that is true, the simplest fix may be to change the first line of
> MakeFonts() so that it always sets lpgw->rotate = TRUE;
I honestly couldn't tell about window's fonts. The default font
certainly is rotatable, I guess all truetype/outline fonts are. I
don't know about monospaced bitmap fonts. I'd say: keep the test in
MakeFonts().
benjamin
|
|
From: Tatsuro M. <tma...@ya...> - 2011-02-07 23:49:34
|
Hello
--- Benjamin Lindner wrote:
> >
> > OK. So I will have to leave it to you guys to figure out what the problem
> > is, since it doesn't show up on my linux+wine setup.
>
> Here we go:
> The offending command happens in WIN_set_text(NULL), which places a
> W_font command in the queue with an empty font name. Removing this one
> solves the problem
>
> diff --git a/src/term/win.trm b/src/term/win.trm
> --- a/src/term/win.trm
> +++ b/src/term/win.trm
> @@ -730,7 +730,6 @@
> int fontsize;
>
> if (font == NULL) {
> - GraphOp(&graphwin, W_font, 0, 0, "");
> strcpy(WIN_font, graphwin.deffontname);
> WIN_fontsize = graphwin.deffontsize;
> return TRUE;
>
> I am not sure this command should be there anyway, I don't really see
> its purpose.
> Tatsuro can you check if this also fixes the problem for you?
The patch cannot be applied to the source that I have so that I manually attached it.
--- wgraph.orig.c 2011-01-25 06:52:59 +0900
+++ wgraph.c 2011-02-08 08:35:31 +0900
@@ -2632,9 +2632,10 @@
{
int newfontsize;
bool remakefonts = FALSE;
+ bool font_is_not_empty = (font != NULL) && (font[0] != '\0');
newfontsize = (fontsize != 0) ? fontsize : lpgw->deffontsize;
- if (font != NULL) {
+ if (font_is_not_empty) {
remakefonts = (strcmp(lpgw->fontname, font) != 0) || (newfontsize != lpgw->fontsize);
} else {
remakefonts = (strcmp(lpgw->fontname, lpgw->deffontname) != 0) || (newfontsize != lpgw->fontsize);
@@ -2642,7 +2643,7 @@
if (remakefonts) {
lpgw->fontsize = newfontsize;
- strcpy(lpgw->fontname, (font) ? font : lpgw->deffontname);
+ strcpy(lpgw->fontname, font_is_not_empty ? font : lpgw->deffontname);
DestroyFonts(lpgw);
MakeFonts(lpgw, &rect, hdc);
With the patch above,
set term windows enhanced
plot [0:2*pi] sin(x) with linespoints
set ylabel "something in mm^2"
replot
The relative position superscript '2' still changed when windows size changed.
> Second proposal:
> Make GraphChangeFonts() more robust like:
>
> diff --git a/src/src/win/wgraph.c b/src/src/win/wgraph.c
> --- a/src/src/win/wgraph.c
> +++ b/src/src/win/wgraph.c
> @@ -2613,9 +2613,10 @@
> {
> int newfontsize;
> bool remakefonts = FALSE;
> + bool font_is_not_empty = (font != NULL) && (font[0] != '\0');
>
> newfontsize = (fontsize != 0) ? fontsize : lpgw->deffontsize;
> - if (font != NULL) {
> + if (font_is_not_empty) {
> remakefonts = (strcmp(lpgw->fontname, font) != 0) ||
> (newfontsize != lpgw->fontsize);
> } else {
> remakefonts = (strcmp(lpgw->fontname, lpgw->deffontname) != 0)
> || (newfontsize != lpgw->fontsize);
> @@ -2623,7 +2624,7 @@
>
> if (remakefonts) {
> lpgw->fontsize = newfontsize;
> - strcpy(lpgw->fontname, (font) ? font : lpgw->deffontname);
> + strcpy(lpgw->fontname, font_is_not_empty ? font : lpgw->deffontname);
>
> DestroyFonts(lpgw);
> MakeFonts(lpgw, &rect, hdc);
>
>
> This would ensure the behaviour of "" meaning "the default font" on
> the low level terminal code.
> Could you check this also Tatsuro?
With the patch above,
set term windows enhanced
plot [0:2*pi] sin(x) with linespoints
set ylabel "something in mm^2"
replot
The relative position superscript '2' also still changed when windows size changed.
Regards
Tatsuro
--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/
|
|
From: Benjamin L. <bj...@gm...> - 2011-02-08 06:39:33
|
>> The offending command happens in WIN_set_text(NULL), which places a >> W_font command in the queue with an empty font name. Removing this one >> solves the problem > > With the patch above, > > set term windows enhanced > plot [0:2*pi] sin(x) with linespoints > set ylabel "something in mm^2" > replot > > The relative position superscript '2' still changed when windows size changed. >> Second proposal: > > The relative position superscript '2' also still changed when windows size changed. No you misunderstood. The problem is that the ylabel is not printed rotated by 90 degrees, but simply horizontally, and *this* should be fixed with either one of these patches. The fact that the relative positioning changes if you change the graph window's size is inherent to the way gnuplot works. To fix this you'd have to change the design of how gnuplot handles text output, and that's not the topic of this patch. The bug about that I reported in a differnet thread is that it at the moment the positioning is wrong even for the initial graph window - and that is fixed with the proposed patch in the respective thread. Changing the graph window size manually will still distort the whole plot (not only the relative positioning of the text). benjamin |
|
From: Tatsuro M. <tma...@ya...> - 2011-02-09 04:40:43
|
Hello Sorry for misunderstood. I will check initial position of superscript at various windows size like set term win enh size 600, 300 plot [0:2*pi] sin(x) with linespoints set ylabel "something in mm^2" replot set term win enh size 600, 400 plot [0:2*pi] sin(x) with linespoints set ylabel "something in mm^2" replot set term win enh size 600, 500 plot [0:2*pi] sin(x) with linespoints set ylabel "something in mm^2" replot set term win enh size 600, 600 plot [0:2*pi] sin(x) with linespoints set ylabel "something in mm^2" replot Am I right? Regards Tatsuro --- Benjamin Lindner wrote: > >> The offending command happens in WIN_set_text(NULL), which places a > >> W_font command in the queue with an empty font name. Removing this one > >> solves the problem > > > > With the patch above, > > > > set term windows enhanced > > plot [0:2*pi] sin(x) with linespoints > > set ylabel "something in mm^2" > > replot > > > > The relative position superscript '2' still changed when windows size changed. > > > >> Second proposal: > > > > The relative position superscript '2' also still changed when windows size changed. > > No you misunderstood. The problem is that the ylabel is not printed > rotated by 90 degrees, but simply horizontally, and *this* should be > fixed with either one of these patches. > > The fact that the relative positioning changes if you change the graph > window's size is inherent to the way gnuplot works. To fix this you'd > have to change the design of how gnuplot handles text output, and > that's not the topic of this patch. > The bug about that I reported in a differnet thread is that it at the > moment the positioning is wrong even for the initial graph window - > and that is fixed with the proposed patch in the respective thread. > Changing the graph window size manually will still distort the whole > plot (not only the relative positioning of the text). > > benjamin > -------------------------------------- Get the new Internet Explorer 8 optimized for Yahoo! JAPAN http://pr.mail.yahoo.co.jp/ie8/ |
|
From: Benjamin L. <bj...@gm...> - 2011-02-10 12:18:12
|
> Am I right? Correct. I got myself a CVS 2011-01-25 snapshot from https://github.com/gnuplot/gnuplot and tested against it, and it works for me (i.e. solves the problem). So I'd like to propose the following patch to fix the ylabel-not-rotated problem. diff --git a/src/win/wgraph.c b/src/win/wgraph.c --- a/src/win/wgraph.c +++ b/src/win/wgraph.c @@ -2613,9 +2613,10 @@ { int newfontsize; bool remakefonts = FALSE; + bool font_is_not_empty = (font != NULL) && (font[0] != '\0'); newfontsize = (fontsize != 0) ? fontsize : lpgw->deffontsize; - if (font != NULL) { + if (font_is_not_empty) { remakefonts = (strcmp(lpgw->fontname, font) != 0) || (newfontsize != lpgw->fontsize); } else { remakefonts = (strcmp(lpgw->fontname, lpgw->deffontname) != 0) || (newfontsize != lpgw->fontsize); @@ -2623,7 +2624,7 @@ if (remakefonts) { lpgw->fontsize = newfontsize; - strcpy(lpgw->fontname, (font) ? font : lpgw->deffontname); + strcpy(lpgw->fontname, font_is_not_empty ? font : lpgw->deffontname); DestroyFonts(lpgw); MakeFonts(lpgw, &rect, hdc); diff --git a/term/win.trm b/term/win.trm --- a/term/win.trm +++ b/term/win.trm @@ -730,7 +730,6 @@ int fontsize; if (font == NULL) { - GraphOp(&graphwin, W_font, 0, 0, ""); strcpy(WIN_font, graphwin.deffontname); WIN_fontsize = graphwin.deffontsize; return TRUE; The problem of the enhanced text positioning is fixed with the patch suggested at http://article.gmane.org/gmane.comp.graphics.gnuplot.devel/9905 which still applies for the 2011-01-25 CVS snapshot. benjamin |
