Wellcome here
Mojca Miklavec
https://sourceforge.net/tracker/?func=detail&atid=102055&aid=1434633&group_id=2055
(The patch for post.term was commited to CVS today.)
To all the others: thanks for joining.
I've also sent a short notice to the ConTeXt mailing list if anyone
else would like to join the conversation.
The terminal is now half-done (I decided to do that one year ago, was
then contemplating for more than one year and finaly did something on
the last weekend). I implemented most drawing routines, what still
remains to be done is:
- handling font names & sizes (I need help here)
- fix centering of text (How should I vertically center text? \strut
might not always be the best solution. I though about centering the
middle point between baseline and upper corners, but that might fail
for small and big letters as well; perhaps lowering text for one half
of the declared size?)
- handling palettes & strange ways of specifying colors (have to study
how it's done first), 3D plotting comes with that
- including bitmap images (low priority)
- filling with 2D patterns
- setting the plot size
I need suggestions and opinions about:
- default plot size (it's 5x3 inches in some terminals, 5x3.5 in others, ...)
- default length of tics (it's 5pt in LaTeX, 3.15 in metapost,
probably whatever anywhere else; I guess that the plots on the web
page are plotted with 3.5pt, but I'm not sure since I changed the
behaviour once already)
- default line widths (I would say that it should remain 0.4 points,
but how about the borders? Many terminals use 1pt. I added it to the
terminal options, but should scaling factor 1.0 stand for 1pt or for
0.4pt?) Should the border have any other default line width?
- point shapes & default point shapes (I would like to implement two
ways for including points or at least two main sources for point
shapes, one using symbols from fonts and the other one using metapost
for drawing them)
- metapost has a "textmag" option which scales all labels for a
certain factor. Do we need that and in that case is this name OK or
would you suggest something else?
- I first implemented the option "do not setbounds to the declared
size of the figure" and then deleted it again. But perhaps this option
is sensible to have anyway. Opinions? Any suggestiong for the name of
that option if I add it again (setboundingbox | nosetboundingbox |
clip|noclip | originalsize |...)?
I would like to leave most options easily configurable, so that one
could for example list colors, dash patterns, point shapes to be used,
...
What I would like to do but is not yet supported by gnuplot core (or
only half-possible):
- being able to specify if a line has to have mitered or rounded
linejoins and linecaps (I already fixed the behaviour with respect to
postscript and metapost, which never closed circular lines, so that
thicker plots had one uneven corner; the problem is that one would
probably like to keep the border mitered, while having wild and 3D
plots rounded)
- smooth gradient colors (perhaps it would be possible with some
trickery, I have to take a look at the code since here both metapost
and gnuplot have their limitations, but might be overcome somehow;
I'll first add normal support for palettes and then see what I can do
here)
Things that have to be added to the module:
- somehow deleting all the trash file produced for the sake of and by gnuplot
- inclusion (and scaling?) of plots produced by the context terminal
Any comments on this?
set terminal context {default}
{input | standalone}
{text | page}
{header "<header>" | noheader}
{color | colour | monochrome}
{dashed | solid}
{mitered | rounded | beveled}
{butt | round | squared}
{dashlength | dl <DL>}
{linewidth | lw <LW>}
{textmag ???? <mag>}
{textext | btex}
{"<fontname>"} {<fontsize>}
Mostly to Taco and Hans: this is very low priority, but I'll ask
anyway. The routine for drawing images is on optional routine to be
implemented in terminals (you get n*m colors and have to draw a
rectangular image). I can do n*m "fill unitsquare shifted (i,j)
withcolor ..." statements, but that's extremely inefficient (slow and
ugly rendering on screen). Is there a way to include that into PDF? I
know how to put that into PS as hexadecimal strings, but I don't know
how to pass that to metapost. Is there any special trickery like the
one for transparency needed for that?
There's also some strange part with palettes to be implemented, but I
have to figure out first how it works. It might be sufficient to keep
track about colors inside C code since PostScript is probably the only
terminal which writes palettes into file and does all conversions
directly in file.
That's enough for now,
Mojca
Taco Hoekwater
Mojca Miklavec wrote:
> To Taco: thanks for the patch, I'll try it and report. See also
> https://sourceforge.net/tracker/?func=detail&atid=102055&aid=1434633&group_id=2055
> (The patch for post.term was commited to CVS today.)
You should adopt that instead of my code. I did not realise
there was a dedicated function for reading strings safely.
> what still remains to be done is:
> - handling font names & sizes (I need help here)
What needs to be done there?
> - fix centering of text (How should I vertically center text? \strut
> might not always be the best solution. I though about centering the
> middle point between baseline and upper corners, but that might fail
> for small and big letters as well; perhaps lowering text for one half
> of the declared size?)
I guess you should center on a fixed height (the x-height or the math
axis or so). If the alignment depends on the actual character(s), you
can get quite ugly results in some cases because not all vertically
aligned labels are on the same visual baseline.
> - handling palettes & strange ways of specifying colors (have to study
> how it's done first), 3D plotting comes with that
Some support macros for this stuff could move to the m-gnuplot.tex
(and perhaps mp-gnup.mp as well). That would avoid some clutter in
the output?
> I need suggestions and opinions about:
> - default plot size (it's 5x3 inches in some terminals, 5x3.5 in others, ...)
ConTeXt oft uses a ratio of 4:3, so what about 4x3 inches?
> - default length of tics (it's 5pt in LaTeX, 3.15 in metapost,
Needs some testing. Short ones tend to look a bit more professional
in my eyes (and they are less likely to get in the way of the plot
itself), but too short is strange.
> - default line widths (I would say that it should remain 0.4 points,
> but how about the borders? Many terminals use 1pt. I added it to the
I would prefer if you drew no borders at all. At least not in the
"page" case: a \framed can be added easily by the user, but an
existing border (drawn by gnuplot) cannot easily be dropped.
> terminal options, but should scaling factor 1.0 stand for 1pt or for
> 0.4pt?) Should the border have any other default line width?
Context has a "scale" keyword that is measured in permilles of
the original value. Does that help?
I have to look at test results first before I can comment on
other preferences.
Cheers, Taco
Mojca Miklavec
On 2/21/06, Taco Hoekwater wrote:
>
> Mojca Miklavec wrote:
> > To Taco: thanks for the patch, I'll try it and report. See also
> > https://sourceforge.net/tracker/?func=detail&atid=102055&aid=1434633&group_id=2055
> > (The patch for post.term was commited to CVS today.)
>
> You should adopt that instead of my code. I did not realise
> there was a dedicated function for reading strings safely.
OK.
> > what still remains to be done is:
> > - handling font names & sizes (I need help here)
>
> What needs to be done there?
See http://gnuplot.sourceforge.net/docs_4.1/node176.html#set_label:
set label {<tag>} {"<label text>"} {at <position>}
{left | center | right}
{norotate | rotate {by <degrees>}}
{font "<name>{,<size>}"}
Some (most?) terminals also support specifying the font to be used in plots:
set terminal emf 'Times Roman Italic' 12
set terminal postscript {landscape | portrait | eps}
{"<fontname>"} {<fontsize>}
How should I interpret those names and sizes? I always get them as
"fontname,size" strings and have to typeset all the labels that that
are issued after that with that font. Whay should I do with them (I'm
asking for both standalone and "to-be-included" graphics.)
Should I say "btex \switchtobodyfont[fontname,size] whatevertext
etex"? Any other way? Perhaps issuing an "verbatimtex
\switchtobodyfont[fontname,fontsize] etex"? What about typescripts,
encodings and I-don't-know-what-features-xetexers might want to use?
How to combine the size specified here and the global font size
settings? I don't want to issue any "\switchtobodyfont[...]" if that's
not necessary.
I would like to have a special case: if font name is "default", don't
use any \switchtobodyfont (but I have to be careful, so that the fon't
will indeed reset to "default", not just that the way it was before
setting it to "default").
And I have to tell to gnuplot what size of characters I'm using (char
width and height) ...
I also decided to implement both typesetting with btex ... etex and
textext("") since I had way too much problems using textext, so I have
to support both ways, but I have to figure out first what to do with
the settings mentioned above.
> > - fix centering of text (How should I vertically center text? \strut
> > might not always be the best solution. I though about centering the
> > middle point between baseline and upper corners, but that might fail
> > for small and big letters as well; perhaps lowering text for one half
> > of the declared size?)
>
> I guess you should center on a fixed height (the x-height or the math
> axis or so). If the alignment depends on the actual character(s), you
> can get quite ugly results in some cases because not all vertically
> aligned labels are on the same visual baseline.
I already noticed that I was getting "jan" and "feb" aligned
differently. So should I align in TeX with something like \raise
-\whateverthenameofmathheightis\hbox{content} (probably doesn't work
that way) or in Metapost for one half of the height for which metapost
thinks that the label should be tall?
> > - handling palettes & strange ways of specifying colors (have to study
> > how it's done first), 3D plotting comes with that
>
> Some support macros for this stuff could move to the m-gnuplot.tex
> (and perhaps mp-gnup.mp as well). That would avoid some clutter in
> the output?
I planned to do that anyway. I just temporary stored the metapost
routines inside \startMPinclusions ... \stopMPinclusions in the
document to be processed. (some proper place should be found for other
user-defined macros such the example with "\input test-gnuplot")
As I was looking for a way out of problems with metafun I browsed
through texexec.pl and tex.rb a bit. I'm starting to get a feeling
that supporting gnuplot at ruby level would be much more error-prone
than strange TeX tricks. That way it would be much easier to support
even some slightly more strange latex/epslatex terminals (which need
an additional document to be crated and compiled first), to clean up
the trash left after gnuplot runs and to hanle gnuplot scripts
properly, I'll start a new thread about that.
> > I need suggestions and opinions about:
> > - default plot size (it's 5x3 inches in some terminals, 5x3.5 in others, ...)
>
> ConTeXt oft uses a ratio of 4:3, so what about 4x3 inches?
Interesting idea. For publications that might be a reasonable size,
for standalone graphs it's perhaps a bit too small. In any case the
default tick lenght should be OK for a wide enough range of sizes and.
> > - default line widths (I would say that it should remain 0.4 points,
> > but how about the borders? Many terminals use 1pt. I added it to the
>
> I would prefer if you drew no borders at all. At least not in the
> "page" case: a \framed can be added easily by the user, but an
> existing border (drawn by gnuplot) cannot easily be dropped.
I didn't want to draw any borders around the figure. I was talking
about the border around the plotting area.
> > terminal options, but should scaling factor 1.0 stand for 1pt or for
> > 0.4pt?) Should the border have any other default line width?
>
> Context has a "scale" keyword that is measured in permilles of
> the original value. Does that help?
Where would you use this one?
I was talking about "set term context linewidth 2.0" or something.
That one should set the default line widths for the whole plot (a
multiplier). But should now 2.0 stand for 2pt or for 0.8 (twice the
default weight). In other settings 1.0 usually means "default".
Mojca
Taco Hoekwater
Mojca Miklavec wrote:
> I also decided to implement both typesetting with btex ... etex and
> textext("") since I had way too much problems using textext, so I have
> to support both ways, but I have to figure out first what to do with
> the settings mentioned above.
I understand better now. On the down side: there is no clear answer
from me, because it seems that all you can do needs some sort of
not-yet-written support from within metafun. On the bright side:
you can use pretty much whatever is easiest or most pleasing to you :-)
> I already noticed that I was getting "jan" and "feb" aligned
> differently. So should I align in TeX with something like \raise
> -\whateverthenameofmathheightis\hbox{content} (probably doesn't work
> that way) or in Metapost for one half of the height for which metapost
> thinks that the label should be tall?
raising the baseline in metapost by 0.3*<fontsize> should give
reasonable results, I believe. (the 0.3 is based on my assumption
that an average font is using 800 vs. 200 for ascender and
descender)
>>>I need suggestions and opinions about:
>>>- default plot size (it's 5x3 inches in some terminals, 5x3.5 in others, ...)
>>
>>ConTeXt oft uses a ratio of 4:3, so what about 4x3 inches?
>
> Interesting idea. For publications that might be a reasonable size,
> for standalone graphs it's perhaps a bit too small. In any case the
> default tick lenght should be OK for a wide enough range of sizes and.
The postscript terminal multiplies/divides by two for that, so
you would get 8x6 for the standalone version (10x7 in postscript term)
That size is not unreasonable, but it needs to be rotated to fit on
(most) paper.
> I didn't want to draw any borders around the figure. I was talking
> about the border around the plotting area.
Sorry, I was missing the point. IMHO making the borders (that
duplicate as axes) fatter is ugly, but that is personal taste.
"set border" allows finetuning, either way.
> I was talking about "set term context linewidth 2.0" or something.
> That one should set the default line widths for the whole plot (a
> multiplier). But should now 2.0 stand for 2pt or for 0.8 (twice the
> default weight). In other settings 1.0 usually means "default".
I feel dimensionless floats really should be scale factors. There
is enough confusion between "bp" and "pt" in TeX vs. MetaPost so that
people will not automatically know which unit is used, otherwise.
Cheers, Taco
nibua-r
>> - default length of tics (it's 5pt in LaTeX, 3.15 in metapost,
Personally, I prefer shortest...
> I would prefer if you drew no borders at all. At least not in the
> "page" case: a \framed can be added easily by the user, but an
> existing border (drawn by gnuplot) cannot easily be dropped.
Is it possible to have a set/unset borders (the keyword could be frame
or whatever you suggest) ?
Renaud
Mojca Miklavec
>
> Personally, I prefer shortest...
I also think they're better (current version has 3.5 set for no
special reason; I can make them 3.15 as well).
> Is it possible to have a set/unset borders (the keyword could be frame
> or whatever you suggest) ?
Which borders are you talking about? Those around the plotting area
(ie. "something like x and y axes") or the borders around the whole
resulting graphic, equivalent to
\framed{gnuplot graphic here}?
The first one can be controlled with "set border":
http://gnuplot.sourceforge.net/docs_4.1/node146.html
If you're talking about the second one: I don't know if it can be set
in gnuplot (you can set all kind of labels and draw lines, I don't
know about boxes). I could add a black frame as a special feature
(it's trivial), I'm only not sure if this is really a part of work for
terminal (since you will probably want to draw dashed border of
linewidth 3pt and rgbcolor(1,0,.8) once in the future). You could draw
frame around pliots with \framed, although I admit that the interface
has to be changed then.
If I draw 10 subsequent plots with \startMPcode ... \stopMPcode, they
cannot be framed, but Taco or Hans has to suggest something here. I
thought already about that, but didn't come to a good solution yet.
Taco: thanks once more for your header patch. The patch in CVS was
better in the way that it used try_to_parse_string (which also escapes
quotes and does other useful stuff), but didn't address the problem
that your patch solved with setting pointers to free and empty headers
to noheader. So I combined the two solutions and fixed the one in
epslatex too. If "environment" is better than "header" (keyword stolen
from epslatex), I'll change it.
I uploaded that on pub.mojca.org/gnuplot (otherwise there are no
changes yet except that linidth now stands for scaling factor, so the
behaviour didn't really change; I also uploaded the forgotten pdflib
for potential windows users).
Mojca
Mojca Miklavec
> > I also decided to implement both typesetting with btex ... etex and
> > textext("") since I had way too much problems using textext, so I have
> > to support both ways, but I have to figure out first what to do with
> > the settings mentioned above.
>
> I understand better now. On the down side: there is no clear answer
> from me, because it seems that all you can do needs some sort of
> not-yet-written support from within metafun. On the bright side:
> you can use pretty much whatever is easiest or most pleasing to you :-)
No, not that I had problems understanding how textext works (more
user-friendly than btax ... etex alone in any case), but with my
installation btex ... etex almost always worked OK, while textext("")
didn't. Since I suppose I'm not the only one, I would like to make the
code as portable as possible.
I discovered "hobbiestextext" variable in the metafun source today. I
have to test that one ;)
May I assume that the users of gnuplot will never dare to use "etex"
in titles and other labels?
> > I already noticed that I was getting "jan" and "feb" aligned
> > differently. So should I align in TeX with something like \raise
> > -\whateverthenameofmathheightis\hbox{content} (probably doesn't work
> > that way) or in Metapost for one half of the height for which metapost
> > thinks that the label should be tall?
>
> raising the baseline in metapost by 0.3*<fontsize> should give
> reasonable results, I believe. (the 0.3 is based on my assumption
> that an average font is using 800 vs. 200 for ascender and
> descender)
That sounds OK to me. But which <fontsize>? (Does metapost
accidentally know what size of font is used inside btex ... etex?) I
have to clear out how "fontname,size" will be used in general.
> >>>I need suggestions and opinions about:
> >>>- default plot size (it's 5x3 inches in some terminals, 5x3.5 in others, ...)
> >>
> >>ConTeXt oft uses a ratio of 4:3, so what about 4x3 inches?
> >
> > Interesting idea. For publications that might be a reasonable size,
> > for standalone graphs it's perhaps a bit too small. In any case the
> > default tick lenght should be OK for a wide enough range of sizes and.
>
> The postscript terminal multiplies/divides by two for that, so
> you would get 8x6 for the standalone version (10x7 in postscript term)
>
> That size is not unreasonable, but it needs to be rotated to fit on
> (most) paper.
That one made me think a bit. I remember the problem I pointed out at
the beginning when PS graphics were rotated by 90 degrees and
\useGNUPLOTgraphic wasn't able to rotate it.
I think that postscript scales down everything by factor 2 or so
(including fonts) if you use eps instead of the default size. I don't
want any scaling in standalone mode unless explicitely asked for. (Is
there a need for a keyword "scale 3" or can/should this be done later
in ConTeXt? Since this wouldn't have any influence on the way that
gnuplot renders graphic, I don't want to have too many keywords.)
There's a big difference in scaling by two and setting the size of the
plot twice as big, namely line widths, point sizes, tics on axes, font
size, ...
It's not clear to me if we also need keywords like "rotated" or even
"rotated 90" or "landscape" or such. I don't want the user to read
help for 10 minutes to find out how to set something trivial, but on
the other hand I want to leave enough flexibility.
> > I didn't want to draw any borders around the figure. I was talking
> > about the border around the plotting area.
>
> Sorry, I was missing the point. IMHO making the borders (that
> duplicate as axes) fatter is ugly, but that is personal taste.
> "set border" allows finetuning, either way.
Agree on that.
> > I was talking about "set term context linewidth 2.0" or something.
> > That one should set the default line widths for the whole plot (a
> > multiplier). But should now 2.0 stand for 2pt or for 0.8 (twice the
> > default weight). In other settings 1.0 usually means "default".
>
> I feel dimensionless floats really should be scale factors. There
> is enough confusion between "bp" and "pt" in TeX vs. MetaPost so that
> people will not automatically know which unit is used, otherwise.
OK, "set terminal context linewidth 1.0" will stand for 0.5bp then (I
don't know why I thought it was 0.4) and the border will be drawn with
that linewidth too. Although: this number could theoretically be both:
a scaling factor (defaulting to 0.5bp) or an actual unit ("set
terminal context lw 0.3mm"). I have to rewrite the code a bit in this
case, but it's doable.
Mojca
Taco Hoekwater
Mojca Miklavec wrote:
> Taco: thanks once more for your header patch. The patch in CVS was
> better in the way that it used try_to_parse_string (which also escapes
> quotes and does other useful stuff), but didn't address the problem
> that your patch solved with setting pointers to free and empty headers
> to noheader. So I combined the two solutions and fixed the one in
> epslatex too. If "environment" is better than "header" (keyword stolen
> from epslatex), I'll change it.
"environment" is only really better if you would change
environment "mystuff"
into
\environment mystuff
if you do not do that (I ma not saying you should), then "header" is
at least as good.
Cheers, taco
Taco Hoekwater
Mojca Miklavec wrote:
> May I assume that the users of gnuplot will never dare to use "etex"
> in titles and other labels?
If they do, you can just hit them on the head with something :-)
Seriously: just document the fact that they cannot do that if
they want to use the btex .. etex variant, that should not be
a problem.
textext() needs a companion textextsetup() for the verbatimtex
functionality. Perhaps Hans is already working on that because
the problem also came up a few weeks back. Is Hans on this list?
> That sounds OK to me. But which <fontsize>? (Does metapost
> accidentally know what size of font is used inside btex ... etex?) I
> have to clear out how "fontname,size" will be used in general.
Side note: Metapost 'sees' the result of btex ... etex, and that
are "infont" commands, just like normal labels. For example, here
is the final resulting MPX file from "btex \TeX etex":
% Written by DVItoMP, Version 0.9/color (Web2C 7.5.3)
begingroup save _p,_r,_s,_n; picture _p; _p=nullpicture;
string _n[];
vardef _s(expr _t,_f,_m,_x,_y)(text _c)=
addto _p also _t infont _f scaled _m shifted (_x,_y) _c; enddef;
_n0="cmr10";
_s("T",_n0,1.00000,0.0000,-6.8078,);
_s("E",_n0,1.00000,5.5345,-8.9525,);
_s("X",_n0,1.00000,11.0693,-6.8078,);
setbounds _p to (0,-8.9525)--(18.5413,-8.9525)--
(18.5413,0.0000)--(0,0.0000)--cycle;
_p endgroup
mpxbreak
"fontname,size" does not have a lot of meaning for TeX-processed
labels because they are not limited to a specific font. This is
probably also why the LaTeX terminal is so vague on the subject.
> I think that postscript scales down everything by factor 2 or so
> (including fonts) if you use eps instead of the default size. I don't
> want any scaling in standalone mode unless explicitely asked for. (Is
> there a need for a keyword "scale 3" or can/should this be done later
> in ConTeXt? Since this wouldn't have any influence on the way that
> gnuplot renders graphic, I don't want to have too many keywords.)
The 'standalone' version maybe needs such a keyword, since there
is no "later in ConTeXt". For the 'page' version, it is easy to
do this in context (likewise for rotation). But you can escape
from this by making the 'standalone' read a special optional
options file. Then you don't have to do everything inside gnuplot.
Cheers, Taco