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

Re: Cleanup list of patches and bug reports on sf.net

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

Daniel J Sebald wrote:

>>> Or maybe I'll code up a user preference setting for line spacing.
>>> That is, how much vertical space is implied by an embedded "\n"
>>> 'set line_spacing <foo>'
>>>     term.c (write_multiline):
>>>         y += user_prefs.line_spacing * t->v_char
>>> where right now line_spacing is always 1.0 
>>

Actually, this is a good idea, but as something independent from trying 
to control the spacing for non-90 degree rotated text.

Dan

Re: Cleanup list of patches and bug reports on sf.net

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

Harald Harders wrote:

>On Wed, 27 Oct 2004, Ethan Merritt wrote:
>
>  
>
>>On Wednesday 27 October 2004 01:32 pm, Harald Harders wrote:
>>    
>>
>>>>Well, not exactly nonsense.  For example, say I want to have my x-axis
>>>>tic titles at an angle, and I want the end of the words to line up right
>>>>below the tic marks.  I think that requires vertical alignment.
>>>>        
>>>>
>>>I did not mean that is was nonsense to have a vertical alignment when
>>>using rotated text. But it is surely nonsense if the text is rotated by an
>>>angle that leads to an overlap of these lines. Simply try this:
>>>  set label "first line\nsecond line" at 0,0 rotated by 85
>>>Don't you agree that this behaviour is bad?
>>>      
>>>
>>Not really. It just means you need more spacing between the lines.
>>OK, 85 degrees is a bit extreme.  But 60 degrees works just fine:
>>
>>	set label "first line\n\nsecond line" rotate by -60
>>
>>Or maybe I'll code up a user preference setting for line spacing.
>>That is, how much vertical space is implied by an embedded "\n"
>>'set line_spacing <foo>'
>>	term.c (write_multiline):
>>		y += user_prefs.line_spacing * t->v_char
>>where right now line_spacing is always 1.0
>>    
>>
>
>I think it is also important that the user gets control if he wants
>vertical or horizontal aligmnent resp. at which angle the axis switches.
>  
>

I think what I am seeing is a slightly different hybrid.  When rotating 
lines of text, I'm thinking you can either rotate each line 
individually, or you can rotate lines of text as a "block", i.e., 
imagine putting a box around all the lines of text indicated.

The 0 degrees rotation is obvious.  The 90 degree rotation looks as 
though the lines are treated as a block and rotated about a "left, 
center" anchor point.  And then, angles in between seem to be different, 
each line rotated individually about its own "left, center" anchor 
point.  I'd say treating the label as a block is the way to go because 
each line individually can be done with separate labels.

The user specified spacing isn't a good idea.  I suggest a sort of 
mathematical approach.  Build a "rotation matrix" for which to multiply 
the anchor points of each individual line of text.  That then should 
place both lines exactly where you want them.  (And no special case for 
the 0/90/180/270 because those will come out to the identity matrix, and 
such.)

In datafile.c of the latest CVS should now be a chunk of code that 
builds a 2D rotation matrix given an angle, that you may be able to make 
use of:

/* Construct 2D rotation matrix. */
/* R - Matrix to construct. */
/* alpha - Rotation angle. */
/* return - TRUE means a translation is required. */
TBOOLEAN
rotation_matrix_2D(double R[][2], double alpha)
{
    static double I[2][2] = {{1, 0},
                 {0, 1}};
#define ANGLE_TOLERANCE 0.001
    if (fabs(alpha) < ANGLE_TOLERANCE) {
    /* Zero angle.  Unity rotation. */
    memcpy(R, I, sizeof(I));
    return FALSE;
    } else {
    R[0][0] = cos(alpha);
    R[0][1] = -sin(alpha);
    R[1][0] = sin(alpha);
    R[1][1] = cos(alpha);
    return TRUE;
    }
}

If it returns TRUE, that means it is actually the identity matrix in 
case you want to break and not multiply.

So the idea would be to rotate the *block* of text about the anchor 
point for the *block*.  Let's call that C_b.  Let's call the anchor 
point for the individual lines C_l#, where # is the number of the line. 
 The formula would be:

C'_l# =  R  (C_l# - C_b) + C_b

where C' means the translated position of the anchor point.  Then just 
use those translated points in place of what is currently used.

Dan

Re: \ell in postscript enhanced

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

On Wednesday 27 October 2004 02:16 pm, Ethan Merritt wrote:
> By the way.  I think it would be nice if the PS_load_fontfile routine
> echoed the FontName of the font to the terminal.

Never mind.  

It already does, of course, but only if you are running interactively.
I was running   'gnuplot charset.dem' from the command line.

Sorry for the noise.

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Cleanup list of patches and bug reports on sf.net

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

On Wednesday 27 October 2004 01:57 pm, Harald Harders wrote:
> I think it is also important that the user gets control if he wants
> vertical or horizontal aligmnent resp. at which angle the axis switches.

OK.  But should this be specified in every individual "set <foo>"
command, or should it be some global preference that applies
to all strings? 
 
-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: \ell in postscript enhanced

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

On Wednesday 27 October 2004 01:36 pm, Harald Harders wrote:
> 
> See my other post. The \ell ist in the standard font cmmi10.pfb.

I didn't see it there.  I looked.
I attach the PostScript output of charset.dem run on this font.
The \ell glyph is not represented by any 8-bit character. 

Does one have to embed a re-encode command of some sort
in order to access additional glyphs?  If so, do we need to add
this to gnuplot as an adjunct to the fontfile processing?
 
> > But you would have to convert this from an *.afm file to a *.pfa or *.pfb
> > file in order for gnuplot to import it.
> That is not possible. You have to have either a pfb or a pfa of a font
> (or, or course ttf).

OK. I thought you could convert.

I forgot you could use ttf.  
In that case the easiest answer is probably to use the lower case "l" 
in   .../ttfonts/vladimir.ttf  
or  .../ttfonts/kunstler.ttf

By the way.  I think it would be nice if the PS_load_fontfile routine
echoed the FontName of the font to the terminal.  Even if you know the
file name of the font, you don't always know what to call it in your
text strings.   For example,  vladimir.ttf  is referred to as "VladimirScript", 
but I only know that because I looked for the FontName record 
in the output PostScript file from gnuplot.


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Cleanup list of patches and bug reports on sf.net

[Harald H. <h.h...@tu...>]

On Wed, 27 Oct 2004, Ethan Merritt wrote:

> On Wednesday 27 October 2004 01:32 pm, Harald Harders wrote:
> > > Well, not exactly nonsense.  For example, say I want to have my x-axis
> > > tic titles at an angle, and I want the end of the words to line up right
> > > below the tic marks.  I think that requires vertical alignment.
> >
> > I did not mean that is was nonsense to have a vertical alignment when
> > using rotated text. But it is surely nonsense if the text is rotated by an
> > angle that leads to an overlap of these lines. Simply try this:
> >   set label "first line\nsecond line" at 0,0 rotated by 85
> > Don't you agree that this behaviour is bad?
>
> Not really. It just means you need more spacing between the lines.
> OK, 85 degrees is a bit extreme.  But 60 degrees works just fine:
>
> 	set label "first line\n\nsecond line" rotate by -60
>
> Or maybe I'll code up a user preference setting for line spacing.
> That is, how much vertical space is implied by an embedded "\n"
> 'set line_spacing <foo>'
> 	term.c (write_multiline):
> 		y += user_prefs.line_spacing * t->v_char
> where right now line_spacing is always 1.0

I think it is also important that the user gets control if he wants
vertical or horizontal aligmnent resp. at which angle the axis switches.

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: \ell in postscript enhanced

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

Ethan Merritt wrote:

>Having said all that, I have to point out that so far as I know \ell is not
>defined here; it must be a special from one of the add-on LaTeX packages.
>

Looking in the LaTeX companion, I don't see any special symbol next to 
the \ell.  But this is a math font only character.  So to access it you 
must have some trick to get into the math environment.  I'm not sure how 
you are using this, but if it using the font directly, not via TeX or 
LaTeX, then you should use the symbol's definition, which can be found 
in fontmath.ltx as:

\DeclareSymbolFont{letters}     {OML}{cmm} {m}{it}
\DeclareMathSymbol{\ell}{\mathord}{letters}{"60}

(Note that LaTeX math fonts are not as flexible as the normal text font.)

Dan

Re: Cleanup list of patches and bug reports on sf.net

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

On Wednesday 27 October 2004 01:32 pm, Harald Harders wrote:
> > Well, not exactly nonsense.  For example, say I want to have my x-axis
> > tic titles at an angle, and I want the end of the words to line up right
> > below the tic marks.  I think that requires vertical alignment.
> 
> I did not mean that is was nonsense to have a vertical alignment when
> using rotated text. But it is surely nonsense if the text is rotated by an
> angle that leads to an overlap of these lines. Simply try this:
>   set label "first line\nsecond line" at 0,0 rotated by 85
> Don't you agree that this behaviour is bad?

Not really. It just means you need more spacing between the lines.
OK, 85 degrees is a bit extreme.  But 60 degrees works just fine:

	set label "first line\n\nsecond line" rotate by -60

Or maybe I'll code up a user preference setting for line spacing.
That is, how much vertical space is implied by an embedded "\n"
'set line_spacing <foo>'
	term.c (write_multiline):
		y += user_prefs.line_spacing * t->v_char
where right now line_spacing is always 1.0

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: \ell in postscript enhanced

[Harald H. <h.h...@tu...>]

On Wed, 27 Oct 2004, Ethan Merritt wrote:

> All of these are usable by gnuplot, with the caveat that the character
> encodings for the Computer Modern fonts are idiosynchratic in the extreme.
> You should probably test the font using the demo script  ..../demo/charset.dem
> which can help you figure out which character codes correspond to which
> glyphs.  So for example:
> 	set terminal postscript enhanced  "texsya" \
> 	fontfile /usr/share/texmf/fonts/type1/public/txfonts/txbsya.pfb
> 	set output 'texsya.ps'
> 	load 'charset.dem'
>
> Having said all that, I have to point out that so far as I know \ell is not
> defined here; it must be a special from one of the add-on LaTeX packages.

See my other post. The \ell ist in the standard font cmmi10.pfb.

> I believe the font you want is (on my machine anyhow)
> 	/usr/share/texmf/fonts/afm/yandy/mathtime/rmtmi.afm

This is only an Adobe Font Metric file which does not contain any glyph
information. It is part of the MathTime font by the company Y&Y (RIP).

> But you would have to convert this from an *.afm file to a *.pfa or *.pfb
> file in order for gnuplot to import it.

That is not possible. You have to have either a pfb or a pfa of a font
(or, or course ttf).

Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: Cleanup list of patches and bug reports on sf.net

[Harald H. <h.h...@tu...>]

On Tue, 26 Oct 2004, Daniel J Sebald wrote:

> Harald Harders wrote:

> >>>>>>This patch fixes bug #1000676  (Rotated multiline text misaligned).
> >>>>>>
> >>>>>>
> >>>I would also prefer an option. Maybe "rleft, rright, rcenter" for rotated-sth?
> >>>
> >>>
> >>Maybe an additional keyword "block" as a modifier to left/right/center
> >>
> >>
> >
> >I agree partially.
> >
> >
> >
> >>Rotate text but use current baseline for alignment:
> >>	set label ... rotate by 45 left
> >>
> >>
> >
> >I don't agree with "current". The alignment baseline should switch to
> >horizontal earlier than from 89 to 90 degree. Maybe above 45 degree. It's
> >nonsense to have a vertical alignment when using text that is rotated by,
> >for example, 60 degree.
> >
>
> Well, not exactly nonsense.  For example, say I want to have my x-axis
> tic titles at an angle, and I want the end of the words to line up right
> below the tic marks.  I think that requires vertical alignment.

I did not mean that is was nonsense to have a vertical alignment when
using rotated text. But it is surely nonsense if the text is rotated by an
angle that leads to an overlap of these lines. Simply try this:
  set label "first line\nsecond line" at 0,0 rotated by 85
Don't you agree that this behaviour is bad? I think when not rotating the
alignment axis with the text it should jump from vertical to horizontal
when exceeding 45 degree rotation angle.
Thus, "if (angle)" or "if (angle == TEXT_VERTICAL)" should be replaced by
"if (abs(angle) > 45)" in term.c. And also, text rotated by an angle
larger than 135 degree should be handled seperately.

Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: \ell in postscript enhanced

[Harald H. <h.h...@tu...>]

On Wed, 27 Oct 2004 Giu...@ct... wrote:

> Hi everybody,
>
> I would like to use a calligraphic lower-case l (LaTeX: \ell) in a label
> using gnuplot (set terminal postscript enhanced).
>
> It seems not listed among the available characters within the Symbol font.

If you have LaTeX installed gnuplot has normally has access to these
fonts. You just have to embed the font file and access the glyph by the
octal code. See ps_fontfile_doc.pdf that is included in gnuplot.

Here (untested):

set terminal postscript enhanced fontfile 'cmmi10.pfb'
set label "{/CMMI10 \140}" at 0,0

> What other relatively "standard" postscript font would you recommend me to
> use, hopefully containing also other relevant math characters?

In this way, you have access to all math characters LaTeX knows (that are
available as Type 1 fonts).

Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: \ell in postscript enhanced

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

On Wednesday 27 October 2004 06:41 am, Giu...@ct... wrote:
> 
> I would like to use a calligraphic lower-case l (LaTeX: \ell) in a label 
> using gnuplot (set terminal postscript enhanced).
> 
> It seems not listed among the available characters within the Symbol font.

Correct.
 
> What other relatively "standard" postscript font would you recommend me to 
> use, hopefully containing also other relevant math characters?

The only fonts promised [sort of] by the Adobe PostScript spec are
Times, Helvetica, Courier, and Symbol.  You are of course free to specify
any font you like, but you cannot count on it being present in the device you
are printing to, so you must embed it in your PostScript file.

If TeX is installed on your system then you probably have at least some
subset of the Computer Modern fonts used by TeX.  Probably they are in
/usr/share/texmf/fonts/type1/
or
/usr/local/share/texmf/fonts/type1/

All of these are usable by gnuplot, with the caveat that the character
encodings for the Computer Modern fonts are idiosynchratic in the extreme.
You should probably test the font using the demo script  ..../demo/charset.dem
which can help you figure out which character codes correspond to which
glyphs.  So for example:
	set terminal postscript enhanced  "texsya" \
	fontfile /usr/share/texmf/fonts/type1/public/txfonts/txbsya.pfb
	set output 'texsya.ps'
	load 'charset.dem'

Having said all that, I have to point out that so far as I know \ell is not
defined here; it must be a special from one of the add-on LaTeX packages.

I believe the font you want is (on my machine anyhow)
	/usr/share/texmf/fonts/afm/yandy/mathtime/rmtmi.afm
But you would have to convert this from an *.afm file to a *.pfa or *.pfb
file in order for gnuplot to import it.

	hope that helps

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Qt Wrapper for gnuplot

[Ian R. G. <ge...@kd...>]

Lutz Maibaum said:
>
> Hello Ian,
>
> I'm a frequent user of both gnuplot and KDE, and I was happy to read yo=
u
> email
> to the gnuplot development list. I have little programming experience
> though,
> and I'm not sure if I can offer any valuable help. I can always give it=
 a
> shot, though.
>
> At first sight, I didn't quite understand what you mean by a "KDE
> wrapper".
> From your example, it seems like you are not thinking about a gnuplot G=
UI
> frontend (if you do, you probably want to take a look at Xgfe and qgfe,
> which
> both use Qt), but some sort of plotting widget that uses gnuplot as its
> drawing engine (maybe something like Qwt?).
>
This is more like Xgfe/qgfe than Qwt, since I am using gnuplot via a chil=
d
process.  The difference over *gfe is that I am using bidirectional IO, s=
o
I can get feedback from gnuplot.  I am a big fan of the power of gnuplot,
but the API (or lack there of ;) ) is not so hot.

> If this is so, then maybe you could explain in a little more detail how
> you
> would like to accomplish this. How does the communication between the
> widget
> class and gnuplot work (maybe pipes)? How do you display gnuplot's outp=
ut
> in
> the calling application? I vaguely remember a discussion on the
> gnuplot-beta
> list about the feasibility of a Qt terminal type. Do you want to use
> gnuplot
> in it's interactive mode (zooming, data point labeling, etc.)? I'm sure
> the
> people on the gnuplot-beta list would be interested to know, and can
> probably
> give a lot of helpful tips.
Currently the X11 child window is quite impossible to work with, so I am
just dumping a png to a temp file and then drawing it on the widget.  I
will probably have to implement the zooming, data point labeling and such
manually.

>
> Other points I can think of right now:
>
> - gnuplot has a somewhat unusual license, make sure that it is compatib=
le
> with
> whatever it is you're trying to do.
I'm using it via a child process, but this widget is LGPL at this point.=20
I think that should be okay.
>
> - gnuplot allows execution of arbitrary shell commands within gnuplot
> scripts,
> which might cause security risks.
>
I am hiding this part, so this should not be an issue.

Cheers
   -ian reinhart geiser

--
KDE - Unix is ready for the desktop
http://www.kde.org

Re: Qt Wrapper for gnuplot

[Ian R. G. <ge...@kd...>]

Ethan Merritt said:
> On Wednesday 20 October 2004 05:38 pm, Ian Reinhart Geiser wrote:
>> Greetings,
>> I have been working on a KDE interface to Octave, when I found that
>> there
>> was no nice KDE wrapper around gnuplot.  So I started one.
>
> Great!
> I tried to drum up support for a Qt interface a year or so back, but no
> one
> on the development team (including me) has any experience there.
>
To be honest my wife put me up to this ;)

>> I am mostly looking for people who are interested in helping me that a=
re
>> familiar with gnuplot.  I only really know how to do pretty simple
>> things
>> with it, but I did most of the dirty work already, so anyone with mino=
r
>> C++ knowledge, and a good gnuplot background would work.
>
> I am not clear on exactly what level interface you are working on.
> Is the idea to generate plots through a Qt-based GUI, or is it to provi=
de
> a gnuplot module or driver that pipes output into a set of Qt/KDE
> widgets and windows rather than directly to X?  The latter is what I
> originally had in mind.  That way you could run gnuplot on top of Qt
> even in non-X environments.
>
The big problem I have currently is that I have a KDE application that I
want to have that will display gnuplot graphs, and manipulate them.  The
problem with the X11 interface is that it offers no ability to get the
WinID, so embedding is impossible, and there is no sane way to swallow
multiple plots.  So I dropped back and just dump to a temp png file, and
render that on the widget.

>> Currently line styles, arrows, and arrow styles are supported.  Fill i=
s
>> sort of supported, and plot for data or functions will work with most
>> simple cases.  I think the big issues that remain are the ones I am no=
t
>> aware of ;)
>
> Probably mousing feedback is the biggest issue.  Everything else is
> "more of the same" - more plot styles, more font and color control, etc=
.
> I guess there is also an obvious need to hook up a Print button that
> will trigger a replot in PostScript mode and pipe it to Kprinter.  But
> that is probaly trivial.
>
Oh yeah mouse ;)

I _think_ I can do about 99% of it in the QWidget.  I would have to
manually implement some of the nicer line following things, and selection
boxes though.  Hard, but not impossible from what I can tell.

Adding more styles and palettes are trivial.  Each object in the API
basicly has a method call QString commands() const; This method takes all
of the objects properties and outputs the gnuplot commands.  So adding ne=
w
options will be trivial.  Also for things that use the enumerated styles,
the offsets are stored in the object, so you can reference them from more
complex objects.


>> Currently there is a small dependency on KDE, but I have plans to remo=
ve
>> it, and the remainder works on Win32 or Unix.
>
> OK. Scratch Kprinter then.  But still we would want a Print button
> that generates PostScript output.  The pieces are already there inside
> gnuplot; they would just have to be hooked up to a widget.
>

Well, personally I would like the KDE API, since it makes things like
printing, copy/paste, IPC, and the general UI very trivial.  I only went
the pure Qt route, so I didn't scare off any anti-KDE folks.

If there is enough interest I can go both, but if there is more interest
for KDE, I wont complain.  KPrinter is QPrinter + Awesome config GUI.

I suppose next step is to get public CVS of this bugger up.

Cheers
    -ian reinhart geiser
--
KDE - Unix is ready for the desktop
http://www.kde.org

Re: Qt Wrapper for gnuplot

[Ian R. G. <ge...@kd...>]

Petr Mikulik said:
>> I have been working on a KDE interface to Octave, when I found that
>> there
>> was no nice KDE wrapper around gnuplot.  So I started one.
>>
>> I am mostly looking for people who are interested in helping me that a=
re
>> familiar with gnuplot.  I only really know how to do pretty simple
>> things
>> with it, but I did most of the dirty work already, so anyone with mino=
r
>> C++ knowledge, and a good gnuplot background would work.
>
> Look to gnuplot web page. There are some front-ends / wrappers lists. I=
t
> would be useful to use an already existing API rather than developing y=
our
> own.
>
Mainly because they where either not complete, C based, python based or
just plain not OO.

> BTW, you could not use one of the existings, and add a possibity to dra=
w
> into a KDE widget? Or even a "KE Widget" terminal for gnuplot?
>
>
Thats more or less what I did. I used the Qt process control object to
communicate with gnuplot and output to a temp file which is then rendered=
.

>> The following C++ code generates the graphic at
>> http://www.geiseri.com/kdevelop/gnuplot.png
>>
>>  KGNUPlotWidget *wid =3D new KGNUPlotWidget();
>
Yeah over the weekend I changed it to KGNUPlot::Widget() but i can make i=
t
KGnuplot::Widget() just as easy.

> not GNUPlot, see FAQ --> rather KGnuplot
>
>
>>  LineStyle line(2);
>
> rather prefixed: kgnuplotLineStyle
>
No C++ not C api please.

>
>>  wid->setXLabel("Test X Label");
>>  wid->setYLabel("Test Y Label");
>>  wid->setFormats(KGNUPlotWidget::X, "%g");
>>  wid->setFormats(KGNUPlotWidget::Y, "%.2f");
>
> That looks like reimplementation of gnuplot structure into you KDE. Wha=
t
> about just the similar thing as Octave does:
>  wid->raw("set mxtics 5");
>
> raw would do printf()+fflush()
It is. The only difference is I want a OO api, not subjecting the user to
more shell madness.

Cheers
   -ian reinhart geiser

--=20
KDE - Unix is ready for the desktop
http://www.kde.org

\ell in postscript enhanced

[<Giu...@ct...>]

Hi everybody,

I would like to use a calligraphic lower-case l (LaTeX: \ell) in a label 
using gnuplot (set terminal postscript enhanced).

It seems not listed among the available characters within the Symbol font.

What other relatively "standard" postscript font would you recommend me to 
use, hopefully containing also other relevant math characters?

Thank you in advance.

Giuseppe.

Re: Cleanup list of patches and bug reports on sf.net

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

Harald Harders wrote:

>On Mon, 25 Oct 2004, Ethan Merritt wrote:
>
>  
>
>>On Monday 25 October 2004 06:50 am, Petr Mikulik wrote:
>>    
>>
>>>>>>This patch fixes bug #1000676  (Rotated multiline text misaligned).
>>>>>>            
>>>>>>
>>>I would also prefer an option. Maybe "rleft, rright, rcenter" for rotated-sth?
>>>      
>>>
>>Maybe an additional keyword "block" as a modifier to left/right/center
>>    
>>
>
>I agree partially.
>
>  
>
>>Rotate text but use current baseline for alignment:
>>	set label ... rotate by 45 left
>>    
>>
>
>I don't agree with "current". The alignment baseline should switch to
>horizontal earlier than from 89 to 90 degree. Maybe above 45 degree. It's
>nonsense to have a vertical alignment when using text that is rotated by,
>for example, 60 degree.
>

Well, not exactly nonsense.  For example, say I want to have my x-axis 
tic titles at an angle, and I want the end of the words to line up right 
below the tic marks.  I think that requires vertical alignment.

Technically, there are two alignments with every block of text, or *any* 
object I guess.  (I'm talking 2D graphs now; I'd have to think what the 
consequences are in 3D.)

Another example of this is the "key" patch where I changed the syntax

               {left | right | top | bottom | outside | below | <position>}

to

               {{inside | outside} | {<position>} | {above | below}}
               {left | right | center} {top | bottom | center}

There should be independent alignment in both directions for text as 
well, I'd argue.  Just precisely how it behaves for rotated text is 
slightly open for interpretation.  I.e., when we speak of 
left,right,center and top,bottom,center are we speaking of the text 
block or the graph?  That sort of thing.

Dan

Re: Cleanup list of patches and bug reports on sf.net

[Harald H. <h.h...@tu...>]

On Mon, 25 Oct 2004, Ethan Merritt wrote:

> On Monday 25 October 2004 06:50 am, Petr Mikulik wrote:
> > > > > This patch fixes bug #1000676 =A0(Rotated multiline text misalign=
ed).
> >
> > I would also prefer an option. Maybe "rleft, rright, rcenter" for rotat=
ed-sth?
>
> Maybe an additional keyword "block" as a modifier to left/right/center

I agree partially.

> Rotate text but use current baseline for alignment:
> =09set label ... rotate by 45 left

I don't agree with "current". The alignment baseline should switch to
horizontal earlier than from 89 to 90 degree. Maybe above 45 degree. It's
nonsense to have a vertical alignment when using text that is rotated by,
for example, 60 degree.

> Rotate text as a block
> =09set label ... rotate by 45 left block

That is okay.

Harald

--=20
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: crash bug in pdf terminal

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

Ethan Merritt wrote:

>On Tuesday 26 October 2004 12:30 pm, Daniel J Sebald wrote:
>  
>
>>I think I see the issue now... what you all were probably talking about 
>>but I paid no attention.  In the terminal directory, the .trm files all 
>>have "unsigned" for coordinates, e.g.,
>>    
>>
>
>It isn't just the *.trm files.
>In fact I think it is reasonable for the terminal drivers to receive
>unsigned coordinates.  The problem comes before that.
>
>Didn't we have this discussion already?
>

Probably did and it went right past me, sorry.

>All the internal routines convert coordinates to (unsigned int).
>Unfortunately sometimes they convert too soon, i.e. before clipping.
>Harald Harders and I have been slowly switching the lower-level
>routines over to use integer or double coordinates, and adding
>proper clipping code on top of them.  It should now be working
>for the newer plot styles (with labels, with filledcurves between,
>with vectors) but not yet for all of the older plot styles.
>
>  
>
>>OK.  I'm getting the feeling this is case of someone having to go 
>>through the pain of changing all those "unsigned" coordinate values 
>>inside the terminal drivers to "signed".  At least I don't think it 
>>should wreck any working behavior.  It can only make bad behavior better.
>>
>>    
>>
>
>It is messier than it ought to be because of the way that inverted
>axis ranges are implemented.  Every test for out-of-bounds has
>to allow for the possibility that the axes limits are stored in 
>reverse order.  I'm inclined to say it would be better to change that
>first, and only afterwards worry about adding clipping code
>everywhere.  But I am not familiar with the history of the axis code,
>so I don't know all the places that would be affected. 
>

Reminds me of the image stuff.  First I translated the orientation of 
the image (without moving data around) to just one orientation. 
 Sometimes one can write routines with absolute values and such to get 
proper behavior without "getting ones footing", but often it comes out 
so obfuscated that it's tedious to work with at a later time.  So yeah, 
picking an order early on is fine.  (But choose notation to reflect 
that, for example if order doesn't matter it might be x1, x2.  If it 
does, then perhaps xlow, xhigh.)

>>If people are happy with that as a fix, I'm fine with it too.  [Or it 
>>could be just
>>
>>    double h = (signed) x, v = (signed) y;
>>    
>>
>
>Doesn't work.  It only catches the cases that are out of bounds
>by virtue of having gone negative.  It doesn't catch all the other
>cases of improper clipping.  The proper fix lies in the clipping
>code, not the individual drivers.
>

Oh yeah, those situations where the lines go randomly off into space, 
often seen when zooming, right?

OK, I'm content to just kludge the above on my system and fix my 
immediate problem.  If later you want me to pick a few terminal drivers 
to fix up the unsigned/signed inconsistencies, let me know.

Dan

Re: crash bug in pdf terminal

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

On Tuesday 26 October 2004 12:30 pm, Daniel J Sebald wrote:
> 
> I think I see the issue now... what you all were probably talking about 
> but I paid no attention.  In the terminal directory, the .trm files all 
> have "unsigned" for coordinates, e.g.,

It isn't just the *.trm files.
In fact I think it is reasonable for the terminal drivers to receive
unsigned coordinates.  The problem comes before that.

Didn't we have this discussion already?

All the internal routines convert coordinates to (unsigned int).
Unfortunately sometimes they convert too soon, i.e. before clipping.
Harald Harders and I have been slowly switching the lower-level
routines over to use integer or double coordinates, and adding
proper clipping code on top of them.  It should now be working
for the newer plot styles (with labels, with filledcurves between,
with vectors) but not yet for all of the older plot styles.

> OK.  I'm getting the feeling this is case of someone having to go 
> through the pain of changing all those "unsigned" coordinate values 
> inside the terminal drivers to "signed".  At least I don't think it 
> should wreck any working behavior.  It can only make bad behavior better.
> 

It is messier than it ought to be because of the way that inverted
axis ranges are implemented.  Every test for out-of-bounds has
to allow for the possibility that the axes limits are stored in 
reverse order.  I'm inclined to say it would be better to change that
first, and only afterwards worry about adding clipping code
everywhere.  But I am not familiar with the history of the axis code,
so I don't know all the places that would be affected. 

> If people are happy with that as a fix, I'm fine with it too.  [Or it 
> could be just
> 
>     double h = (signed) x, v = (signed) y;

Doesn't work.  It only catches the cases that are out of bounds
by virtue of having gone negative.  It doesn't catch all the other
cases of improper clipping.  The proper fix lies in the clipping
code, not the individual drivers.


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: crash bug in pdf terminal

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

Daniel J Sebald wrote:

>> Another possible ingredient to this is the infamous signed vs. unsigned
>> confusion that infests practically all of gnuplot. 
>
>
> makes me wonder now.  They wouldn't say "too large" if in fact they 
> meant "negative" as the source of the problem.  So I think you are right.


I suspect that may be it.  The PDF library seems to be robust on the 
placement of text partially off the top of the canvas.  Also, the 
placement of tics far off the top:

set xtics offset 0,graph 10

causes no problems for PDFlib.

I think I see the issue now... what you all were probably talking about 
but I paid no attention.  In the terminal directory, the .trm files all 
have "unsigned" for coordinates, e.g.,

TERM_PUBLIC void
PDF_put_text (unsigned int x, unsigned int y, const char *str)

So, the question is, how is it that the PostScript terminal *works 
properly*?  Because it shouldn't.  It works because it is printing the 
unsigned numbers as signed:

    sprintf(abso, "%d %d M\n", x, y);
    sprintf(rel, "%d %d R\n", dx, dy);

So, the importance of the signed/unsigned issue isn't until its use. 
 (Conversion from signed int to unsigned int or vice versa doesn't do 
anything.  Only when it is interpretted is it important.)  The 
PDF_put_text fails because it has to do the conversion:

    double h = x, v = y;

near the top.


OK.  I'm getting the feeling this is case of someone having to go 
through the pain of changing all those "unsigned" coordinate values 
inside the terminal drivers to "signed".  At least I don't think it 
should wreck any working behavior.  It can only make bad behavior better.

If that's the case.  I'd suggest someone announce "I'm going to do this 
huge patch today, so nobody change anything in CVS for the day".  Then 
after that, we'll all shake the bugs out of the thing.

...

And I just tried a fix that sort of confirms the problem.  Inside the 
PDF terminal driver, I made the following change to the first few lines 
and the PDFlib abort goes away:

TERM_PUBLIC void
PDF_put_text (unsigned int ux, unsigned int uy, const char *str)
{
    char *alignment = NULL;
    int x = ux, y = uy;
    double h = x, v = y;

If people are happy with that as a fix, I'm fine with it too.  [Or it 
could be just

    double h = (signed) x, v = (signed) y;

if x and y are used no further down the road.]  Whether it says "signed" 
or "unsigned" in the function, no big deal to me.  However, who knows if 
all compilers behave the same regarding the signed/unsigned conversion.

Dan

Re: crash bug in pdf terminal

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

Hans-Bernhard Broeker wrote:

> Daniel J Sebald wrote:
>
>> things work fine.  And using "set xtics offset 0,graph -0.5" in the 
>> above (which should result in the tic text off the PDF plot area) 
>> causes the same crash with pdf_ftoa.  So the problem may be placing 
>> text partially or fully off the screen...
>
>
> Exactly.  PDFlib refuses to have coordinates outside the output page
> boundaries.  Part of the problem is that gnuplot doesn't always clip to
> the page.  Now, in some terminals, notable PostScript, it actually makes
> sense to do have elements outside the "page", so maybe gnuplot shouldn't
> do that.  But in that case, terminal drivers like pdf.trm and those
> writing bitmap files will have to do their own clipping.


Nice routines do the clipping at the lowest levels.  (Perhaps there is a 
compilation flag in the PDF libraries that control ignore/abort...)

>   Maybe yet
> another terminal driver flag bit for "coordinates must be clipped to 
> page"?


Not a great solution.

> Another possible ingredient to this is the infamous signed vs. unsigned
> confusion that infests practically all of gnuplot. 


That is what first came to mind for me.  I'll take a look this evening 
and see if I can identify just exactly what's going on.  Looking closely 
at that error message:

PDFlib value error: floating point value too large in pdf_ftoa

makes me wonder now.  They wouldn't say "too large" if in fact they 
meant "negative" as the source of the problem.  So I think you are right.

Thanks,

Dan

Re: crash bug in pdf terminal

[Hans-Bernhard B. <br...@ph...>]

Daniel J Sebald wrote:

[...]

> PDFlib runtime error: Must call PDF_get_buffer() after PDF_close()
> 
> Obviously, what I've done above is an incorrect procedure.

Not necessarily.  It's perfectly feasible to run

	gnuplot some_script > output.pdf

so you shouldn't be forced to use 'set output'.  The error in this case
is in pdf.trm.  It's apparently unaware of this limitation of PDFlib.

> However, it would be nice if gnuplot not crash after issuing an 
> appropriate error message.

That's not gnuplot's decision, I'm afraid.  The crash happens
deliberately, and inside PDFlib: it calls abort().

[...]

> things work fine.  And using "set xtics offset 0,graph -0.5" in the 
> above (which should result in the tic text off the PDF plot area) 
> causes the same crash with pdf_ftoa.  So the problem may be placing 
> text partially or fully off the screen...

Exactly.  PDFlib refuses to have coordinates outside the output page
boundaries.  Part of the problem is that gnuplot doesn't always clip to
the page.  Now, in some terminals, notable PostScript, it actually makes
sense to do have elements outside the "page", so maybe gnuplot shouldn't
do that.  But in that case, terminal drivers like pdf.trm and those
writing bitmap files will have to do their own clipping.  Maybe yet
another terminal driver flag bit for "coordinates must be clipped to page"?

Another possible ingredient to this is the infamous signed vs. unsigned
confusion that infests practically all of gnuplot.

> and that fails too, so the "bmargin 0" has nothing to do with the 
> problem.

It does indirectly, by pushing the xtics to a place outside the page.

Re: crash bug in pdf terminal

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

On Tuesday 26 October 2004 01:31 am, Daniel J Sebald wrote:
> I'm running into some quirks with the pdf terminal that I can't recall 
> in the past.  I returned to some octave code and got some crashes where 
> there were none before.  The PostScript and X11 terminals still work 
> fine with the script in question.

Please see also bug #1039296 "PDFlib Lite 6 output is broken for pipes, stdout"

The problem is that PDFlib changed substantially from version 5
to version 6.  In an attempt to satisfy both, Hans-Bernhard changed pdf.trm

2004-07-08  Hans-Bernhard Broeker  <br...@ph...>
        * term/pdf.trm (PDF_init): Call PDF_open_file() instead of 
        no longer existing function PDF_open_fp().

But at the current state of the code, neither version of PDFlib is
entirely happy.

 
> Here is one that I discovered in playing around with gnuplot.  Generate 
> a plot to the PDF terminal without having defined the output file:
> 
> gnuplot> set terminal pdf
> Terminal type set to 'pdf'
> Options are 'noenhanced fname 'Helvetica'  fsize 6 linewidth 1.0 '
> gnuplot> plot x
> gnuplot> set output
> PDFlib runtime error: Must call PDF_get_buffer() after PDF_close()
> 
> Obviously, what I've done above is an incorrect procedure.  However, it 
> would be nice if gnuplot not crash after issuing an appropriate error 
> message.
> 
> 
> I get a different PDFlib error in Octave.  Think I've found the problem 
> with a few number of gnuplot commands:
> 
> gnuplot> set terminal pdf
> Terminal type set to 'pdf'
> Options are 'noenhanced fname 'Helvetica'  fsize 6 linewidth 1.0 '
> gnuplot> set output 'junk.pdf'
> gnuplot> set bmargin 0
> gnuplot> plot x
> PDFlib value error: floating point value too large in pdf_ftoa
> 
> (Setting bmargin to zero makes sense in multiplot mode.)  Now, if I try:
> 
> set term pdf
> set output 'junk.pdf'
> set bmargin 0
> set xtics offset 0,graph 0.5
> plot x
> set output
> 
> things work fine.  And using "set xtics offset 0,graph -0.5" in the 
> above (which should result in the tic text off the PDF plot area) causes 
> the same crash with pdf_ftoa.  So the problem may be placing text 
> partially or fully off the screen... or perhaps not the screen, but the 
> graph area... not sure.
> 
> Ethan, it has been several months since I've used the particular Octave 
> script that leads to this problem, so I'm sure there've been many 
> changes since that time and likely won't recall anything having changed, 
> but any thoughts?  Can I help pin this down?
> 
> I just tried:
> 
> set term pdf
> set output 'junk.pdf'
> set xtics offset 0,graph -0.5
> plot x
> set output
> 
> and that fails too, so the "bmargin 0" has nothing to do with the problem.
> 
> Dan
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: [ gnuplot-Bugs-1046521 ] [Mac] installer failure

[Hans-Bernhard B. <br...@ph...>]

Per Persson wrote:

> I could create a new installer, and someone with the appropriate powers  
> could then put it on the d/l site.

Please do.  You know the drill: you upload to SF's upload server, then 
inform me, and I'll put it through the file release system.