Menu
▾
▴
gnuplot-beta
|
From: Thomas S. <t.s...@fz...> - 2008-05-21 20:19:53
|
i got two Seiko DPU-414 thermal printers (http://www.seiko-instruments.de/73-0-dpu414.html) and was asking myself whether it would make sense to write a gnuplot driver for this printer. it's still in production and sold as printer for various measurement devices, so it's not really obsolete and i thought this driver could be useful. the driver is an extension of 'epson.trm', mainly a merge of some epson/nec code with some code from 'pbm.trm'. it supports two resolutions: 'normal' (640x480) and 'draft' (320x240) font sizes are 'small', 'medium', and 'large' (like in 'pbm.trm') - but the combination 'draft' + 'large' is forbidden because it drives the 'test' command into an endless(?) loop. http://www.nabble.com/file/p17371497/epson.trm_dpu414.patch epson.trm_dpu414.patch -- View this message in context: http://www.nabble.com/DPU-414-terminal-tp17371497p17371497.html Sent from the Gnuplot - Dev mailing list archive at Nabble.com. |
|
From: Ethan M. <merritt@u.washington.edu> - 2008-05-21 22:19:25
|
On Wednesday 21 May 2008 13:19, Thomas Sefzick wrote: > > i got two Seiko DPU-414 thermal printers > (http://www.seiko-instruments.de/73-0-dpu414.html) and was asking myself > whether it would make sense to write a gnuplot driver for this printer. it's > still in production and sold as printer for various measurement devices, so > it's not really obsolete and i thought this driver could be useful. > the driver is an extension of 'epson.trm', mainly a merge of some epson/nec > code with some code from 'pbm.trm'. > it supports two resolutions: 'normal' (640x480) and 'draft' (320x240) > font sizes are 'small', 'medium', and 'large' (like in 'pbm.trm') - > > http://www.nabble.com/file/p17371497/epson.trm_dpu414.patch > epson.trm_dpu414.patch Fine. Could you please create a new tracker item for the patch and upload it there? I notice a few things on a quick look. The various terminal types covered by this driver can share entry points. For example, there is no reason to have separate identical routines EPSON_reset() STARC_reset() NEC_reset() DPU414_reset(). All four TERM_TABLEs can simply reference EPSON_reset(). > but the > combination 'draft' + 'large' is forbidden because it drives the 'test' > command into an endless(?) loop. I'd rather fix the bug than forbid an otherwise reasonable combination. Anyhow, the bug seems to be more pervasive: set term dpu large normal set output 'test.dpu' load 'histograms.dem' also goes into an infinite loop Can you work out where/why the loop happens? Ethan -- Ethan A Merritt |
|
From: Thomas S. <t.s...@fz...> - 2008-05-22 07:25:20
|
> Could you please create a new tracker item for the patch and > upload it there? yes, ii'l do it. > I notice a few things on a quick look. > The various terminal types covered by this driver can share entry points. > For example, there is no reason to have separate identical routines > EPSON_reset() STARC_reset() NEC_reset() DPU414_reset(). > All four TERM_TABLEs can simply reference EPSON_reset(). there are some things in 'epson.trm' which should be repaired, i noticed that for most of the terminals there's a hyphen used in the name (e.g. nec-cp6) in the help text and in the manual, but in 'set term' these names are accepted with underscore only (nec_cp6). obviously because hyphens in terminal names don't work (i first used 'dpu-414' and had problems with 'set term'). i'll go through 'epson.trm' and try to clean it up a little bit. >> but the >> combination 'draft' + 'large' is forbidden because it drives the 'test' >> command into an endless(?) loop. > > I'd rather fix the bug than forbid an otherwise reasonable combination. > Anyhow, the bug seems to be more pervasive: > set term dpu large normal > set output 'test.dpu' > load 'histograms.dem' >also goes into an infinite loop the same applies for the pbm terminal. > Can you work out where/why the loop happens? well, i'll try to find where it happens, up to now i have no idea where to search. maybe it's due to clipping of characters which extend the drawing area? we'll see... thomas -- View this message in context: http://www.nabble.com/DPU-414-terminal-tp17371497p17398826.html Sent from the Gnuplot - Dev mailing list archive at Nabble.com. |
|
From: Thomas S. <t.s...@fz...> - 2008-05-22 12:38:45
|
> Can you work out where/why the loop happens? well... the loop is not endless, but stepping from 4294967266, 135 to 350, 135 stepsize 1 takes a loooong time... this '4294967266' was meant as '-30' in 'term.c' procedure 'test_term'. it was produced by (*t->move) (xmax_t / 2 - t->h_char * 10, ymax_t / 2 + t->v_char / 2); xmax is 320 (because of 'dpu414 draft') t->h_char is 19 (because of 'dpu414 large') and 160-190 is -30, but it's interpreted as 'unsigned int' by 'b_move', so it's 4294967266. and then b_vector(350, 135) is called which then calls b_line(4294967266, 135, 350, 135) which takes a long time to step from 4294967266, 135 to 350, 135 how to repair this? check every call to 'b_move' and 'b_vector' (i.e. '*t->move' and '*t->vector') that all arguments positive? everywhere, where 'b_move' and 'b_vector' are called? that's a lot of work... but i don't see another solution thomas -- View this message in context: http://www.nabble.com/DPU-414-terminal-tp17371497p17403380.html Sent from the Gnuplot - Dev mailing list archive at Nabble.com. |
|
From: Thomas S. <t.s...@fz...> - 2008-05-22 14:07:54
|
> how to repair this?
> check every call to 'b_move' and 'b_vector' (i.e. '*t->move' and
> '*t->vector') that all arguments are positive?
> everywhere, where 'b_move' and 'b_vector' are called?
> that's a lot of work...
> but i don't see another solution
maybe 'b_move' and 'b_vector' could check their arguments for the highest
bit set and then set the too large (= negative) argument to zero.
this would not be too much code:
---------------------------------------------------------------------
--- bitmap.c.orig 2005-04-22 23:40:37.000000000 +0200
+++ bitmap.c 2008-05-22 15:53:01.000000000 +0200
@@ -1168,6 +1168,7 @@
b_value = value;
}
+static unsigned int b_negmask = (1 << (8*sizeof(unsigned int)-1));
/*
* move to (x,y)
@@ -1175,6 +1176,8 @@
void
b_move(unsigned int x, unsigned int y)
{
+ if (x & b_negmask) x = 0;
+ if (y & b_negmask) y = 0;
b_currx = x;
b_curry = y;
}
@@ -1186,6 +1189,8 @@
void
b_vector(unsigned int x, unsigned int y)
{
+ if (x & b_negmask) x = 0;
+ if (y & b_negmask) y = 0;
b_line(b_currx, b_curry, x, y);
b_currx = x;
b_curry = y;
---------------------------------------------------------------------
any ideas?
thomas
--
View this message in context: http://www.nabble.com/DPU-414-terminal-tp17371497p17405047.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.
|
|
From: Ethan M. <merritt@u.washington.edu> - 2008-05-22 15:55:04
|
On Thursday 22 May 2008 05:38, Thomas Sefzick wrote: > > > Can you work out where/why the loop happens? > > well... > the loop is not endless, but stepping > from 4294967266, 135 > to 350, 135 > stepsize 1 > takes a loooong time... > > this '4294967266' was meant as '-30' in 'term.c' procedure 'test_term'. > it was produced by > (*t->move) (xmax_t / 2 - t->h_char * 10, ymax_t / 2 + t->v_char / 2); As I said in the comment attached to your patch, I'm afraid the underlying problem is a design flaw in gnuplot. It tracks terminal coordinates as unsigned values, which makes proper clipping virtually impossible. Unfortunately, changing the coordinates to signed values would touch essentially every bit of code in the program. The bitmap terminals are pretty ancient code at this point. Other than special devices like your DPU gadget, there isn't any incentive to use or modernize them. The PBM driver was at one point a reasonable output path, but for years now PNG has been better for any purpose I can think of. So there is not much gain to be had from reworking the code in bitmap.c. But if you are so inclined - go for it. As a minimal patch, one might just modify b_vector to ignore any call for which the coordinates are out of range. That would not be proper clipping, but at least it would prevent memory access violations when flipping bits in the bitmap array. On the other hand, it's possible that by now we have wrapped almost all of the terminal calls originating from the core code in calls to draw_clip_line() and clip_move(), clip_point(), and so on. It might well be worth the effort to find and fix the few remaining cases. Ethan > xmax is 320 (because of 'dpu414 draft') > t->h_char is 19 (because of 'dpu414 large') > and 160-190 is -30, but it's interpreted as 'unsigned int' by 'b_move', so > it's 4294967266. > > and then b_vector(350, 135) is called which then calls b_line(4294967266, > 135, 350, 135) > which takes a long time to step from 4294967266, 135 to 350, 135 > > how to repair this? > check every call to 'b_move' and 'b_vector' (i.e. '*t->move' and > '*t->vector') that all arguments positive? > everywhere, where 'b_move' and 'b_vector' are called? > that's a lot of work... > but i don't see another solution > > thomas -- Ethan A Merritt |
|
From: Thomas S. <t.s...@fz...> - 2008-05-22 17:25:35
|
> The bitmap terminals are pretty ancient code at this point.
> Other than special devices like your DPU gadget, there
> isn't any incentive to use or modernize them. The PBM
> driver was at one point a reasonable output path, but for
> years now PNG has been better for any purpose I can think
> of. So there is not much gain to be had from reworking the
> code in bitmap.c. But if you are so inclined - go for it. As a
> minimal patch, one might just modify b_vector to ignore any
> call for which the coordinates are out of range. That would
> not be proper clipping, but at least it would prevent memory
> access violations when flipping bits in the bitmap array.
some kind of clipping is done in 'bitmap.c', it's checked if a pixel
is inside the canvas (x < b_xsize) && (y < b_ysize), but this
doesn't help for negative values.
well, i only wanted to get this little printer running, and with
reasonable options ('draft small' or 'normal medium') it's
printing pretty well.
> On the other hand, it's possible that by now we have
> wrapped almost all of the terminal calls originating from
> the core code in calls to draw_clip_line() and clip_move(),
> clip_point(), and so on. It might well be worth the effort
> to find and fix the few remaining cases.
there seem to be many remaining cases in gnuplot/src:
grep clip_move *.[ch] | wc
14 50 542
grep clip_vector *.[ch] | wc
14 50 569
versus
grep -- "->move" *.[ch] | wc
105 590 5121
grep -- "->vector" *.[ch] | wc
151 875 7338
would it be enough to replace every (*t->vector) with clip_vector,
and every (*t->move) with clip_move ?
or would it need extensive testing?
thomas
--
View this message in context: http://www.nabble.com/DPU-414-terminal-tp17371497p17409329.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.
|
|
From: Jonathan T. <J.T...@so...> - 2008-05-22 20:30:51
|
On Thu, 22 May 2008, someone whose nested quoting has overflowed
my mental stack :) wrote:
> The bitmap terminals are pretty ancient code at this point.
> Other than special devices like your DPU gadget, there
> isn't any incentive to use or modernize them. The PBM
> driver was at one point a reasonable output path, but for
> years now PNG has been better for any purpose I can think
> of.
I hope we keep the PBM driver around -- I still use it fairly often
to generate individual frames for encoding into a movie with ppmtompeg
(which only groks a limited set of native input formats: PPM, PNM,
YUV, JPEG, and JMOVIE, but *not* PNG).
ciao,
--
-- Jonathan Thornburg (remove -animal to reply) <J.T...@so...>
School of Mathematics, U of Southampton, England
"Washing one's hands of the conflict between the powerful and the
powerless means to side with the powerful, not to be neutral."
-- quote by Freire / poster by Oxfam
|
|
From: Ethan M. <merritt@u.washington.edu> - 2008-05-22 20:55:21
|
On Thursday 22 May 2008 13:30, Jonathan Thornburg wrote:
> On Thu, 22 May 2008, someone whose nested quoting has overflowed
> my mental stack :) wrote:
> > The bitmap terminals are pretty ancient code at this point.
> > Other than special devices like your DPU gadget, there
> > isn't any incentive to use or modernize them. The PBM
> > driver was at one point a reasonable output path, but for
> > years now PNG has been better for any purpose I can think
> > of.
>
> I hope we keep the PBM driver around
I wasn't proposed to dump it. I was just trying to prioritize where
development effort is spent. There are plenty of things to work on
that will benefit many terminal types (new plot modes, continued work
on internationalization, updated numerical routines) and other
terminal types with more potential users (cairopdf).
> -- I still use it fairly often
> to generate individual frames for encoding into a movie with ppmtompeg
> (which only groks a limited set of native input formats: PPM, PNM,
> YUV, JPEG, and JMOVIE, but *not* PNG).
That's not much of a reason.
You could use the far more featureful png driver and interpose
a png->pnm filter in the output:
set term png truecolor enhanced font "verdana,11"
set output '| convert png:- mypic.pnm'
--
Ethan A Merritt
|
|
From: Jonathan T. <J.T...@so...> - 2008-05-22 21:03:25
|
Hi,
On Thu, 22 May 2008, Ethan Merritt wrote:
[[about the PBM driver]]
> > -- I still use it fairly often
> > to generate individual frames for encoding into a movie with ppmtompeg
> > (which only groks a limited set of native input formats: PPM, PNM,
> > YUV, JPEG, and JMOVIE, but *not* PNG).
>
> That's not much of a reason.
> You could use the far more featureful png driver and interpose
> a png->pnm filter in the output:
> set term png truecolor enhanced font "verdana,11"
> set output '| convert png:- mypic.pnm'
Good idea, I'll play around the next time I make a movie. The
only problem is that crunching 3000 frames is already a cpu- and
disk-intensive process, and firing up ImageMagick for each frame
would make it considerably worse. What might be better would be
to do a pnmtopnm (part of netpbm) conversion on each frame, since
I already have a pnmchange (also part of netpbm) conversion there.
The netpbm programs are a lot lighter-weight than ImageMagick.
ciao,
--
-- Jonathan Thornburg (remove -animal to reply) <J.T...@so...>
School of Mathematics, U of Southampton, England
"Washing one's hands of the conflict between the powerful and the
powerless means to side with the powerful, not to be neutral."
-- quote by Freire / poster by Oxfam
|
|
From: Ethan M. <merritt@u.washington.edu> - 2008-05-22 18:15:43
|
On Thursday 22 May 2008 10:25, Thomas Sefzick wrote: > > On the other hand, it's possible that by now we have > > wrapped almost all of the terminal calls originating from > > the core code in calls to draw_clip_line() and clip_move(), > > clip_point(), and so on. It might well be worth the effort > > to find and fix the few remaining cases. > > there seem to be many remaining cases in gnuplot/src: > > grep clip_move *.[ch] | wc > 14 50 542 > grep clip_vector *.[ch] | wc > 14 50 569 > > versus > > grep -- "->move" *.[ch] | wc > 105 590 5121 > grep -- "->vector" *.[ch] | wc > 151 875 7338 > > would it be enough to replace every (*t->vector) with clip_vector, > and every (*t->move) with clip_move ? > or would it need extensive testing? No, it takes more than that. For one thing, you have to set the clipping boundaries. Some operations are clipped against the plot boundaries; some are clipped against the screen. Some terminals (postscript, mostly) still insist on drawing outside the clipping area for backwards compatibility. The documentation warns that this may eventually change to hard clipping, but we don't have a consensus on that issue I think. If your version of the simple fix to b_vector() passes muster, let's leave it at that for now. Could you test it by running all.dem through 'set term pbm size 1.0,0.5 large' or something like that? If it segfaults, we've still got a problem. -- Ethan A Merritt |
|
From: Thomas S. <t.s...@fz...> - 2008-05-22 18:56:45
|
> If your version of the simple fix to b_vector() passes muster,
> let's leave it at that for now. Could you test it by running
> all.dem through 'set term pbm size 1.0,0.5 large'
> or something like that? If it segfaults, we've still got a problem.
set term pbm size 160,120 large
set out 'test.pbm'
load 'all.dem'
segfault when running 'singulr.dem'
with 'set term pbm size 320,240 large' everything is ok, segfaults occur
when y-size is <=170 or x-size <= 110.
Program received signal SIGSEGV, Segmentation fault.
in_front (edgenum=1240, vnum1=441, vnum2=442, firstpoly=0xbfffe318)
at hidden3d.c:1821
1821 polynum = qlist[listhead].p;
--
View this message in context: http://www.nabble.com/DPU-414-terminal-tp17371497p17411182.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.
|
|
From: Ethan M. <merritt@u.washington.edu> - 2008-05-22 20:04:51
|
On Thursday 22 May 2008 11:56, Thomas Sefzick wrote: > > set term pbm size 160,120 large > set out 'test.pbm' > load 'all.dem' > > segfault when running 'singulr.dem' > > with 'set term pbm size 320,240 large' everything is ok, segfaults occur > when y-size is <=170 or x-size <= 110. > > Program received signal SIGSEGV, Segmentation fault. > in_front (edgenum=1240, vnum1=441, vnum2=442, firstpoly=0xbfffe318) > at hidden3d.c:1821 > 1821 polynum = qlist[listhead].p; That's a bit strange, because apparently it segfaulted in the hidden-surface bookkeeping routines rather than anything having to do with bitmap management. I suppose one of those overflowed coordinates causes trouble in the depth-sort algorithm. Let me know when you are ready for me to look at the driver again before adding it to CVS. -- Ethan A Merritt |
|
From: Thomas S. <t.s...@fz...> - 2008-05-23 10:10:50
|
> That's a bit strange, because apparently it segfaulted in the
> hidden-surface bookkeeping routines rather than anything having to do
> with bitmap management. I suppose one of those overflowed coordinates
> causes trouble in the depth-sort algorithm.
at least i have found what happens:
access to non-existing elements of 'quadtree' in procedure 'in_front' in
'hidden3d.c' resulting in useless values for 'listhead'
> for (grid_x = grid_x_low; grid_x <= grid_x_high; grid_x ++)
> for (grid_y = grid_y_low; grid_y <= grid_y_high; grid_y ++)
> for (listhead = quadtree[grid_x][grid_y]; <<====THERE====
but why it happens - don't know.
the following patch prevents segfaults and gives warnings:
------------------------------------------------------------------------------
--- hidden3d.c.orig 2008-03-29 10:28:01.000000000 +0100
+++ hidden3d.c 2008-05-23 11:56:46.000000000 +0200
@@ -1801,5 +1801,21 @@
grid_x_low = COORD_TO_TREECELL(xmin);
+ if (grid_x_low < 0) {
+ grid_x_low = 0;
+ fprintf(stderr,"in_front: grid_x_low set to 0\n");
+ }
grid_x_high = COORD_TO_TREECELL(xmax);
+ if (grid_x_high >= QUADTREE_GRANULARITY) {
+ grid_x_high = QUADTREE_GRANULARITY-1;
+ fprintf(stderr,"in_front: grid_x_high set to
QUADTREE_GRANULARITY-1\n");
+ }
grid_y_low = COORD_TO_TREECELL(ymin);
+ if (grid_y_low<0) {
+ grid_y_low = 0;
+ fprintf(stderr,"in_front: grid_y_low set to 0\n");
+ }
grid_y_high = COORD_TO_TREECELL(ymax);
+ if (grid_y_high >= QUADTREE_GRANULARITY) {
+ grid_y_high = QUADTREE_GRANULARITY-1;
+ fprintf(stderr,"in_front: grid_y_high set to
QUADTREE_GRANULARITY-1\n");
+ }
------------------------------------------------------------------------------
gnuplot> set term pbm large size 100,100
gnuplot> set out 'test.pbm'
gnuplot> load 'singulr.dem'
in_front: grid_x_high set to QUADTREE_GRANULARITY-1
in_front: grid_y_high set to QUADTREE_GRANULARITY-1
in_front: grid_x_high set to QUADTREE_GRANULARITY-1
in_front: grid_y_high set to QUADTREE_GRANULARITY-1
...
Hit return to continue (1)
in_front: grid_x_high set to QUADTREE_GRANULARITY-1
in_front: grid_y_high set to QUADTREE_GRANULARITY-1
...
it seems that the 'xmax' and 'ymax' values, set in the macro 'setup_edge',
are wrong sometimes.
--
View this message in context: http://www.nabble.com/DPU-414-terminal-tp17371497p17422742.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.
|
