From: Hans-Bernhard B. <br...@ph...> - 2004-03-29 10:29:22
|
On Sun, 28 Mar 2004, Ethan A Merritt wrote: > On Sunday 28 March 2004 13:35, Per Persson wrote: > > A warning unrelated to aquaterm/OS X I think: > > ../term/fig.trm: In function `FIG_arrow': > > ../term/fig.trm:785: warning: comparison is always false due to > > limited range of data type > > ../term/fig.trm:817: warning: comparison is always false due to > > limited range of data type > > Yes, that's the same bug I reported a few days ago. > It is due to an improper use of TBOOLEAN for one of the > term->arrow parameters that wants to take on numical > values. Hans, are you working on that one? I have a patched version ready to commit, but am a bit hesitant to do so. This is a fundamental change to the definition of the terminal API, something I've been opposing for a while now when others suggested anything like that. But then, the actual change to the API has already been done a while ago, when this abuse of a boolean argument was introduced. I.e. this change just adapts the formal type to what the code actually has been doing for quite a while. Ah heck, I'll just check it in and package up a new snapshot, then. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
From: Hans-Bernhard B. <br...@ph...> - 2004-03-29 10:29:24
|
On Sun, 28 Mar 2004, Per Persson wrote: > During configure: > ----------------- > Can't find malloc.h Don't worry -- it's not needed. <malloc.h> is a non-standard header, not required to be found. Some pre-standard and/or standard-ignoring compilers kept malloc() there. > During make: > ------------ > A warning unrelated to aquaterm/OS X I think: > ../term/fig.trm: In function `FIG_arrow': > ../term/fig.trm:785: warning: comparison is always false due to > limited range of data type > ../term/fig.trm:817: warning: comparison is always false due to > limited range of data type I'll take care of that. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
From: Hans-Bernhard B. <br...@ph...> - 2004-03-31 12:28:57
|
On Tue, 30 Mar 2004, Ethan Merritt wrote: > On Tuesday 30 March 2004 01:17 pm, Per Persson wrote: > > > > I was a little curious about the reason for the overlap between > > filled_polygon() and boxfill(), any particular reason? > > Two parallel projects that got incompletely merged. That's not the entire truth, though. There's also the problem that doing cross-hatching pattern-fill of arbitrary polygons is at least an order of magnitude harder than either cross-hatching of axis-aligned rectangles or solid-colour filling of arbitrary polygons. > the job, I'll probably do it as part of general code cleanup > eventually. That'll be a good deal more work than just a little clean-up. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
From: Ethan M. <merritt@u.washington.edu> - 2004-04-01 18:28:44
|
On Wednesday 31 March 2004 04:22 am, Hans-Bernhard Broeker wrote: > On Tue, 30 Mar 2004, Ethan Merritt wrote: > > On Tuesday 30 March 2004 01:17 pm, Per Persson wrote: > > > I was a little curious about the reason for the overlap between > > > filled_polygon() and boxfill(), any particular reason? > > > > Two parallel projects that got incompletely merged. > > That's not the entire truth, though. There's also the problem that > doing cross-hatching pattern-fill of arbitrary polygons is at least an > order of magnitude harder than either cross-hatching of axis-aligned > rectangles or solid-colour filling of arbitrary polygons. I worried about that originally, but it turns out not to be a problem in practice. Other people have already done the hard work, and included the necessary support in the relevant libraries or languages. The patch on SourceForge shows that pattern-fill of polygons works with no special effort for pdf, png, svg and x11. There is an issue with PostScript, but it's more a question of policy than of difficulty. PostScript pattern-fill requires PostScript Level 2 language support. This is nearly universal by now, but not quite. The question is, what should we fall back to if it is requested but not present? It seems to me that at worst we fall back to doing nothing at all, which is what happens in the current version anyway. That leaves Windows as the largest gap in implementation. Is pattern-fill so horribly difficult in Windows? The current code in src/win/wgraph.c does this: idx = <expression that evaluates to pattern number>; SelectObject(hdc, pattern_brush[idx]); That suggests to me that the pattern-fill support can be applied to any sort of object, but I could be wrong. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |