gnuplot-beta

volunteers to fix some minor bugs in the lua/tikz terminal?

[Ethan A M. <sf...@us...>]

Is anyone out there comfortable working with lua code?

My ability to understand lua code is practically non-existent.
Therefore I could use some help in fixing a few minor problems with the
lua/tikz terminal in the CVS source for gnuplot.

So far as I know, all of these require modifying the file
 .../term/lua/gnuplot-tikz.lua

(1)
The alpha channel in ARGB colors is ignored in term->set_color.
The lua terminal does handle an alpha channel in other code paths,
for instance in gfx.format_color, so clearly it must be possible.

(2) 
The linetype LT_NODRAW (defined as -3 in term_api.h) is supposed
to indicate that this line is not drawn at all.  When applied to a fill area
it is supposed to indicate that no fill is present (i.e. 100% transparent).
The lua code is treating this the same as LT_BACKGROUND, which is
suppoed to mean "draw this line in the background color".
It is true that if you are drawing directly onto the background these both
come out the same.   But if you draw a new line on top of a dark area,
say a previous filled area, then they most certainly are not the same.

(3)
Most terminals support a terminal option "linewidth <x>" that is used
as a multiplier for whatever individual linetypes are used in drawing.
That is, to make all of the lines in a plot twice the normal thickness,
you should be able to say
    set term tikz linewidth 2.0
Unfortunately this isn't implemented in the lua/tikz terminal

(4)
This one may not be possible.  At any rate it is trickier than the others.
The tikz terminal does not support the "boxed" attribute of text strings.
See for example the final plot in
    http://gnuplot.sourceforge.net/demo_cvs/datastrings.html


		any help is much appreciated,

				Ethan

Re: volunteers to fix some minor bugs in the lua/tikz terminal?

[Christoph B. <us...@be...>]

Hi Ethan,

Am 02.09.2014 22:18, schrieb Ethan A Merritt:
>
> (1)
> The alpha channel in ARGB colors is ignored in term->set_color.
> The lua terminal does handle an alpha channel in other code paths,
> for instance in gfx.format_color, so clearly it must be possible.

I'm currently working on the ARGB part, which is already working.

I wasn't sure, how to handle properly the fill styles FS_OPAQUE and 
FS_SOLID with respect to the alpha value. Other terminals (checked qt 
and svg seem to use alpha values in both cases).

I can also have a look at the other points you raised.

Another problem I encountered with the lua/tikz terminal is your recent 
change of drawing the arrow shafts and the arrow heads separately, 
<http://gnuplot.cvs.sourceforge.net/viewvc/gnuplot/gnuplot/src/graphics.c?r1=1.462&r2=1.463>.
That doesn't work with the `tikzarrows` option, because the tikz-arrow 
routine doesn't support negative headstyle. It seems to be possible to 
draw only the arrow heads <http://tex.stackexchange.com/q/1260/33933>, 
but I'm not sure if this works properly.

Do you have any suggestions for this?

Best,
Christoph

Re: volunteers to fix some minor bugs in the lua/tikz terminal?

[Ethan A M. <sf...@us...>]

On Tuesday, 02 September, 2014 23:12:30 Christoph Bersch wrote:

> Another problem I encountered with the lua/tikz terminal is your recent 
> change of drawing the arrow shafts and the arrow heads separately, 
> <http://gnuplot.cvs.sourceforge.net/viewvc/gnuplot/gnuplot/src/graphics.c?r1=1.462&r2=1.463>.
> That doesn't work with the `tikzarrows` option, because the tikz-arrow 
> routine doesn't support negative headstyle. It seems to be possible to 
> draw only the arrow heads <http://tex.stackexchange.com/q/1260/33933>, 
> but I'm not sure if this works properly.
> 
> Do you have any suggestions for this?

The reason for that change was to insure that arrow heads were never
drawn with dashed lines.  Since the tikz private arrow routine will  (I think)
never draw with a head with dashed lines anyhow, the problem did not
exist there in the first place.  So it's unfortunate that the change broke
something.

My first inclination would be to have tikz interpret the negative head
style as a request to change the linetype to invisible, as shown in 
one of the stackexchange suggestions you linked to.

If necessary, the calling code could check some terminal flag - maybe
TERM_IS_LATEX? - and alter the call accordingly.  

I wouldn't be surprised if the new v5 dashed line code introduced other
bugs into the various TeX terminals.   

   cheers,

	Ethan

Re: volunteers to fix some minor bugs in the lua/tikz terminal?

[Christoph B. <us...@be...>]

Hi,

Am 02.09.2014 22:18, schrieb Ethan A Merritt:
>
> (2)
> The linetype LT_NODRAW (defined as -3 in term_api.h) is supposed
> to indicate that this line is not drawn at all.  When applied to a fill area
> it is supposed to indicate that no fill is present (i.e. 100% transparent).
> The lua code is treating this the same as LT_BACKGROUND, which is
> suppoed to mean "draw this line in the background color".
> It is true that if you are drawing directly onto the background these both
> come out the same.   But if you draw a new line on top of a dark area,
> say a previous filled area, then they most certainly are not the same.

the more I look through the code, the more confused I get concerning the 
handling of LT_BACKGROUND, LT_NODRAW and FS_EMPTY:

* According to comments in many terminal drivers, FS_EMPTY is handled as 
if it should be filled with background color. However, I didn't manage 
to get any plot command which actually delivers the FS_EMPTY style to 
the terminal driver. Do you have an example?

I would expect the FS_EMPTY call to be handled like LT_NODRAW, i.e. no 
fillarea should be drawn at all.

* Based on your description above (LT_NODRAW applied to a fill area), I 
constructed the following script:

set object rectangle from graph 0,0 to graph 1,1 fc rgb 'red' fs solid
set object polygon from graph 0.2,0.2 to graph 0.5,0.2 to graph 0.6, 0.7 
fs solid fc lt -3

plot x

That however fails on all terminals I tested and always draws a white 
polygon (tested cairo terminals, qt, svg, lua).

Best,
Christoph

Re: volunteers to fix some minor bugs in the lua/tikz terminal?

[sfeam <sf...@us...>]

On Monday, 15 September 2014 09:27:24 PM Christoph Bersch wrote:
> Hi,
> 
> Am 02.09.2014 22:18, schrieb Ethan A Merritt:
> >
> > (2)
> > The linetype LT_NODRAW (defined as -3 in term_api.h) is supposed
> > to indicate that this line is not drawn at all.  When applied to a fill area
> > it is supposed to indicate that no fill is present (i.e. 100% transparent).
> > The lua code is treating this the same as LT_BACKGROUND, which is
> > suppoed to mean "draw this line in the background color".
> > It is true that if you are drawing directly onto the background these both
> > come out the same.   But if you draw a new line on top of a dark area,
> > say a previous filled area, then they most certainly are not the same.
> 
> the more I look through the code, the more confused I get concerning the 
> handling of LT_BACKGROUND, LT_NODRAW and FS_EMPTY:
> 
> * According to comments in many terminal drivers, FS_EMPTY is handled as 
> if it should be filled with background color. However, I didn't manage 
> to get any plot command which actually delivers the FS_EMPTY style to 
> the terminal driver. Do you have an example?

I wish I could say that all the intersecting features, code, and terminal
support followed some grand plan that had been well designed and laid out
in advance.  The addition of fill styles, including FS_EMPTY, came before
any of the rest.  It was a top-down design:  the top level data structures
and syntax came first, terminal support got added later one at a time.
So yeah, it could be that FS_EMPTY is implemented entirely in the core
code and none of the terminals ever sees that flag.

> I would expect the FS_EMPTY call to be handled like LT_NODRAW, i.e. no 
> fillarea should be drawn at all.

Yes.


> * Based on your description above (LT_NODRAW applied to a fill area), I 
> constructed the following script:
> 
> set object rectangle from graph 0,0 to graph 1,1 fc rgb 'red' fs solid
> set object polygon from graph 0.2,0.2 to graph 0.5,0.2 to graph 0.6, 0.7 
> fs solid fc lt -3
> 
> plot x
> 
> That however fails on all terminals I tested and always draws a white 
> polygon (tested cairo terminals, qt, svg, lua).

Remember that until relatively recently there was no clear distinction
between "linetype" and "line color".  The idea that "background"
can be a color rather than a terminal property was introduced, I think,
in version 4.2.

In version 5 I hope we have managed to disentangle linetype from color.
So "fillcolor bgnd" makes sense because "background" is a color.
But "fillcolor LT_NODRAW" does not, although I suppose if is accepted at
all then background color is the most logical thing to get.


Getting back to the lua terminal, my concern was specifically with
term->linetype(LT_NODRAW) followed by a series of term->vector()
commands.  Several places in the core code now emit this sequence in
order to "not draw" pieces of a surface or grid.  Arguably this should
be changed in the core code rather than individual terminals, but at
the moment it depends on the terminal itself knowing to turn the vector
commands into move commands when the current linetype is LT_NODRAW.

	Ethan