Menu
▾
▴
gnuplot-beta
|
From: Harald H. <h.h...@tu...> - 2004-10-23 20:55:27
|
I have seen some old patches on sf.net that may have to change the status. For example, the patch #982765, "Patch for AI (Adobe Illustrator) term", has been discussed here. Since the whole AI terminal is outdated and postscript is understood by Adobe Illustrator, this patch could be rejected and closed. Or patch #743667, "Epslatex term merged w/ pslatex/pstex", is superseeded by #1040192, "Merge post, epslatex, pslatex, pstex terminals", and could also be closed. And isn't the bug report #963176, "wish: only create docs for available terminals", solved? This could shorten the lists and maybe help the writers of the patches to know if their idea is just ignored or rejected. If rejecting such a patch a cause should be given. Harald -- Harald Harders h.h...@tu... http://www.harald-harders.de |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-10-24 00:24:41
|
On Saturday 23 October 2004 01:55 pm, Harald Harders wrote: > I have seen some old patches on sf.net that may have to change the status. > > For example, the patch #982765, "Patch for AI (Adobe Illustrator) term", > has been discussed here. Since the whole AI terminal is outdated and > postscript is understood by Adobe Illustrator, this patch could be > rejected and closed. > Or patch #743667, "Epslatex term merged w/ pslatex/pstex", is superseeded > by #1040192, "Merge post, epslatex, pslatex, pstex terminals", and could > also be closed. It would be nice to hear from people actually using these various drivers. I suppose we can deprecate ai.trm and the older forms of the various latex terminals, but we may have to resurrect them if there are user communities who rely on some feature of the older terminal drivers that we didn't realize we were changing. > And isn't the bug report #963176, "wish: only create docs for available > terminals", solved? Not that I know of. In fact, I don't think there was a consensus that this is desirable. The counter-argument was that the documentation should be complete even if that means describing some terminal types that are not universally configured. After all, how would you know your local installation is missing a terminal type if the=20 documentation doesn't even mention it? > This patch fixes bug #1000676 =A0(Rotated multiline text misaligned). > The alignment of rotated multiline text was correct for > horizontal and vertical text but incorrect for other > angles (they were handled as not rotated). This patch > corrects this. I don't agree that this was a bug. It depends on what you want to do with the text. For me, the chief use is to squeeze more (or longer) labels along an axis than would otherwise fit. And in this case the=20 baseline should remain the axis itself, i.e. not rotated. IMHO it looks really odd to have multi-line axis tic labels swing out and away from the axis. If you think it is useful to have the entire text block rotate as a unit, I think we would need some new syntax or justification option to specify it. Can you give an example of when you would want this? |
|
From: Harald H. <h.h...@tu...> - 2004-10-24 01:08:29
|
On Sat, 23 Oct 2004, Ethan Merritt wrote: > On Saturday 23 October 2004 01:55 pm, Harald Harders wrote: > > I have seen some old patches on sf.net that may have to change the stat= us. > > > > For example, the patch #982765, "Patch for AI (Adobe Illustrator) term"= , > > has been discussed here. Since the whole AI terminal is outdated and > > postscript is understood by Adobe Illustrator, this patch could be > > rejected and closed. > > Or patch #743667, "Epslatex term merged w/ pslatex/pstex", is superseed= ed > > by #1040192, "Merge post, epslatex, pslatex, pstex terminals", and coul= d > > also be closed. > > It would be nice to hear from people actually using these various > drivers. I suppose we can deprecate ai.trm and the older forms of > the various latex terminals, but we may have to resurrect them if > there are user communities who rely on some feature of the older > terminal drivers that we didn't realize we were changing. When closed, patches are not deleted immediately, right? Then, this should not be a too big problem. > > And isn't the bug report #963176, "wish: only create docs for available > > terminals", solved? > > Not that I know of. I think the discussion was somehow good. In all platform-independent formats, all terminals should be described. In the online form (via typing help in gnuplot), either only installed ones should be described (which is the case, I think) or not installed terminals should be described but marked as not installed. But the bug report #963176 requested to not describe uninstalled terminals at all, if I remember correctly. And then, it is not unsolved. > > This patch fixes bug #1000676 =A0(Rotated multiline text misaligned). > > The alignment of rotated multiline text was correct for > > horizontal and vertical text but incorrect for other > > angles (they were handled as not rotated). This patch > > corrects this. > > I don't agree that this was a bug. It depends on what you want to > do with the text. For me, the chief use is to squeeze more (or longer) > labels along an axis than would otherwise fit. And in this case the > baseline should remain the axis itself, i.e. not rotated. IMHO it looks > really odd to have multi-line axis tic labels swing out and away from > the axis. That is of course a usage I have not thought of, yet. But it surely is a bug to have the old alignment when using a rotation angle of more than 45 degree. Then, the lines overlap in most cases. But it should be possible to rotate the whole text block, too. > If you think it is useful to have the entire text block rotate as a > unit, I think we would need some new syntax or justification > option to specify it. Can you give an example of when you > would want this? I have had some plots with legends that had up to 2 lines each and were rotated by 60 degree. I wanted them to be centred. And it looked very odd that they were centred to a vertical(!) line. To me, it were best to centre to a line rotated by 60 degree from the vertical direction. In short: I still think it is a bug since even text rotated by 89 degree is aligned vertically. If the alignment axis should rotate with the text or if it has to stay at a fixed angle up to a threshold angle is a question of taste. I think both possibilities should be there. Maybe there should be an additional keyword 'alignmentangle' or similar. Greetings Harald --=20 Harald Harders h.h...@tu... http://www.harald-harders.de |
|
From: Petr M. <mi...@ph...> - 2004-10-25 13:50:29
|
> > > And isn't the bug report #963176, "wish: only create docs for availab= le > > > terminals", solved? > > > > Not that I know of. > > I think the discussion was somehow good. In all platform-independent > formats, all terminals should be described. In the online form (via typin= g > help in gnuplot), either only installed ones should be described (which i= s > the case, I think) or not installed terminals should be described but > marked as not installed. But the bug report #963176 requested to not > describe uninstalled terminals at all, if I remember correctly. And then, > it is not unsolved. Currently, "set term" lists all available terminals, while gnuplot docs describes docs for all terminals. Then we are sure that gnuplot docs is always complete. The beginning of "help term" should probably say explicitl= y that the terminals listed below may be platform-dependent or not available on some systems. > > > This patch fixes bug #1000676 =A0(Rotated multiline text misaligned). > > > The alignment of rotated multiline text was correct for > > > horizontal and vertical text but incorrect for other > > > angles (they were handled as not rotated). This patch > > > corrects this. > > In short: I still think it is a bug since even text rotated by 89 degree > is aligned vertically. If the alignment axis should rotate with the text > or if it has to stay at a fixed angle up to a threshold angle is a > question of taste. I think both possibilities should be there. > Maybe there should be an additional keyword 'alignmentangle' or similar. I would also prefer an option. Maybe "rleft, rright, rcenter" for rotated-sth? --- PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-10-25 18:53:15
|
On Monday 25 October 2004 06:50 am, Petr Mikulik wrote: > > > > This patch fixes bug #1000676 =A0(Rotated multiline text misaligned= ). >=20 > I would also prefer an option. Maybe "rleft, rright, rcenter" for rotated= =2Dsth? Maybe an additional keyword "block" as a modifier to left/right/center Rotate text but use current baseline for alignment: set label ... rotate by 45 left Rotate text as a block set label ... rotate by 45 left block =2D-=20 Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Harald H. <h.h...@tu...> - 2004-10-26 20:59:48
|
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 |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-10-26 12:10:11
|
Petr Mikulik wrote: >>>>And isn't the bug report #963176, "wish: only create docs for available >>>>terminals", solved? >>> >>>Not that I know of. >> >>I think the discussion was somehow good. In all platform-independent >>formats, all terminals should be described. In the online form (via typing >>help in gnuplot), either only installed ones should be described (which is >>the case, I think) or not installed terminals should be described but >>marked as not installed. But the bug report #963176 requested to not >>describe uninstalled terminals at all, if I remember correctly. And then, >>it is not unsolved. > > > Currently, "set term" lists all available terminals, while gnuplot docs > describes docs for all terminals. Only for some select values of what "docs" you may be speaking of. You won't see help for the X11, PM, or aquaterm drivers in the Windows version. The scheme is supposed to be: docs for all terminals *only* in the platform-independent versions of the docs (essentially the printable ones, and everything derived from gnuplot.texi). The online help of any given version will not contain documentation on terminal drivers not present in that version. The only other option I can see would be to have an #ifdef inside the documentation section of the relevant terminal drivers that switches between the actual documentation and " Sorry, this terminal is not present in your version of gnuplot" line, then build even the online versions using allterm.h instead of term.h. This would generate online docs with the complete set of nodes, but some of them would just contain this "Sorry" notice. |
|
From: Daniel J S. <dan...@ie...> - 2004-10-26 21:19:12
|
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
|
|
From: Harald H. <h.h...@tu...> - 2004-10-27 20:32:27
|
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 |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-10-27 20:51:59
|
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 |
|
From: Harald H. <h.h...@tu...> - 2004-10-27 20:57:09
|
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 |
|
From: Daniel J S. <dan...@ie...> - 2004-10-27 21:31:56
|
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
|
|
From: Daniel J S. <dan...@ie...> - 2004-10-27 22:26:27
|
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 |
|
From: Petr M. <mi...@ph...> - 2004-10-29 06:18:54
|
> 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 So we will need: global: set style linespacing 1.2 or set linespacing 1.2 and the same for a given text set label ... linespacing 1.2 set key title ... linespacing 1.2 --- PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-10-27 21:18:58
|
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 |
|
From: Harald H. <h.h...@tu...> - 2004-10-28 20:07:09
|
On Wed, 27 Oct 2004, Ethan Merritt wrote: > 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? I am not sure. Of course, it is less work to use one global flag in most cases. But in rare cases, a user may to use both cases in one plot. Then, a global flag is not possible. Or it could be a command similar to 'set pointsize' which takes effect immediately. For example, set pointsize 3 set style line 1 lt 1 pt 1 set pointsize 1 set style line 2 lt 1 pt 1 leads to different point sizes when using ls 1 resp. 2. The setting of the rotation behaviour could then be handled similarly. Harald -- Harald Harders h.h...@tu... http://www.harald-harders.de |
