4687274, xscl[1] 2145210464
xscl[0] -2147483648, xscl[1] -2147483648
Is this patch the right approach?
Regards,
Mark de Wever
diff --git a/src/plarc.c b/src/plarc.c
index 25defdf9a..d3034a94a 100644
--- a/src/plarc.c
+++ b/src/plarc.c
@@ -147,14 +147,20 @@ c_plarc( PLFLT x, PLFLT y, PLFLT a, PLFLT b
Regards,
Mark de Wever
diff --git a/src/plmap.c b/src/plmap.c
index 58d359a99..694e23fce 100644
--- a/src/plmap.c
+++ b/src/plmap.c
@@ -596,7 +596,7 @@ plmapline( PLMAPFORM_callback mapform, PLCHAR_VECTOR name,
PLINT_VECTOR plotentries, PLINT nplotentries )
{
#ifdef HAVE_SHAPELIB
Hi Phil,
I saw the release of 5.13 is being planned. I wondered whether it is
possible to fix this issue before the release.
Regards,
Mark de Wever
On 18.11.16 18:30, p.d.rosenb...@gmail.com wrote:
Hi Mark
Thanks for the report. I'll have a look at your example over the weekend and
s
earthdata.com/download/50m/cultural/ne_50m_admin_0_countries_lakes.zip
Regards,
Mark de Wever
diff --git a/src/plmap.c b/src/plmap.c
index 4030512..a175e8d 100644
--- a/src/plmap.c
+++ b/src/plmap.c
@@ -149,17 +149,13 @@ drawmapdata( PLMAPFORM_callback mapform, int shapetype, PLINT n, PLFLT *x,
oast lines; I picked Ireland since it shows the bug nicely.
Regards,
Mark de Wever
PS: It seems the old deprecated plmap code no longer shows a map (at
least on Windows). I didn't investigate further, I just installed the
shapelib library.
PPS: There also seems to be another issue with a
Hi Alan,
Seems I didn't notice your reply until today.
Alan W. Irwin wrote:
> On 2013-03-25 09:33+0100 Mark de Wever wrote:
>
> This is the right place to post concerning PLplot development issues
> such as the one you have found.
Ok thanks for the confirmation.
&g
7; data to a floating point value. When documented it
becomes a smaller issue, but might still catch some users by surprise.
Regards,
Mark de Wever
Index: examples/c/x01c.c
===
--- examples/c/x01c.c (revision 12283)
+++ exam
LabelDefaults structure. If the user, for example, sends a
pointer to an ingeger, it might cause accessing memory out of bounds and
can casting `random' data to a floating point value. When documented it
becomes a smaller issue, but might still ca
Hi,
When using the cairo-ext under Windows I get a lot of warnings about the
font not being found and the font size looks bad. The attached patch
fixes that problem, tested under Debian Squeeze and Windows.
Regards,
Mark de Wever
diff --git a/drivers/cairo.c b/drivers/cairo.c
index f3be69e
Hi Hez,
Hezekiah M. Carty wrote:
> On Tue, Oct 13, 2009 at 8:10 AM, Mark de Wever wrote:
> The Qt widget and wxwidgets drivers keep their own, driver-specific,
> lists of all plotted elements. So when a plot window using one of
> those devices is resized the plot is replayed automat
y application I need the widget to be able to scale. Since the Xwin
driver is able to do that, I thought it would be possible. But I found
out it isn't and for now I just redraw the plot in the newly sized widget.
It would be nice if it was possible to do it with a plreplay command. I
also
Mark de Wever wrote:
Hi,
I've been working on creating a plplot widget in gtkmm [1], this widget
uses the extcairo driver. In order to get this widget working I've been
making several modifications to the plplot sources.
I created a new patch in response to the discussion regarding
hat
> just leaves xcairo to be made offset-aware from the above list.
Seems the misunderstanding is now completely resolved.
Regards,
Mark de Wever
--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is
Hi Alan,
Alan W. Irwin wrote:
> On 2009-09-25 14:36+0200 Mark de Wever wrote:
>
>> From Alan's mail in that thread I understood that not using offset in
>> the other drivers was seen as a minor omission. I see some use for the
>> offset parameter for the extcai
for the exception.
So regardless whether a function exits due to returning normally or due
to unwinding the stack during an exception, the local variables are
cleaned up normally. This feature is used in the common C++ idom
Resource Acquisition Is Initialization (RAII) [1].
[1] http://en.wikip
is that I seem to miss a minor part of the puzzle. This
causes the resize not to work entirely as wanted. If you look at the
sample program with the second #if 0 changed to #if 1 you can see the
problem when you resize a widget which uses a clip rectangle.
Regards,
Mark de Wever
-
on. But I'm not
sure whether this is really wanted and/or how much existing code it
would break.
[1] http://gtkmm.org
[2]
http://www.mail-archive.com/plplot-devel@lists.sourceforge.net/msg03634.html
Regards,
Mark de Wever
diff --git a/drivers/cairo.c b/drivers/cairo.c
index 3d24c23..08f
Alan W. Irwin wrote:
> On 2009-09-18 11:10+0200 Werner Smekal wrote:
>> On 18.09.2009, at 10:21, Mark de Wever wrote:
>>> The attached patch shows the modification I did to try to resize the
>>> plot area and move the location of its origin in that test. The
not.
Regards,
Mark de Wever
PS: I switched to git-svn so the patch looks slightly different from the
normal svn patches, but should still apply when using -p1 instead of -p0.
diff --git a/examples/c/ext-cairo-test.c b/examples/c/ext-cairo-test.c
index 96e6265..d362682 100644
--- a/examples/c/e
k fix and detailed explanation of the cause of the
problem. I tested my own application with the current plplot trunk
version and can confirm that the issue is there resolved as well.
Regards,
Mark de Wever
--
Come buil
a way to reproduce the problem with example 2 screenshot 1.
Running the following command reproduces the problem:
./x02 -dev xcairo -bg FF
With the xwin device the boxes don't become invisible but black. When
not setting the background colour the example also works as expected.
Regard
Alan W. Irwin wrote:
On 2009-08-26 11:12+0200 Mark de Wever wrote:
I also noticed with gcc -Wall there are a lot of unused variables in
plplot, if wanted I could provide a patch which removes those variables.
Yes, please.
Sorry hit the send button too soon, this time with the patch attached
Alan W. Irwin wrote:
> On 2009-08-26 11:12+0200 Mark de Wever wrote:
>> The attached patches fix some compiler warnings:
>> plargs-patch Make sure the functions return a value.
>> cairo-patch Properly place parentheses, avoiding code having no effect.
>
> Thanks, Mar
removes those variables.
Regards,
Mark de Wever
Index: src/plargs.c
===
--- src/plargs.c(revision 10343)
+++ src/plargs.c(working copy)
@@ -2259,6 +2259,7 @@
opt_cmap0(const char *opt, const char *optarg, void
Hi Alan,
Alan W. Irwin wrote:
> Hi Mark:
>
> (I also have an important note for Hazen at the end.)
>
> On 2009-07-15 10:48+0200 Mark de Wever wrote:
>
>> Alan W. Irwin wrote:
>> I just tested with the xwin device, with the following command:
>> ./x01 -dev x
Alan W. Irwin wrote:
> On 2009-07-14 15:01+0200 Mark de Wever wrote:
>
>> Hi,
>>
>> The calculation of the aspect ratio doesn't take the rotation angle of
>> the plot into account. This patch solves the aspect ratio for 90 and
>> 270 degrees.
>
Hi,
The calculation of the aspect ratio doesn't take the rotation angle of
the plot into account. This patch solves the aspect ratio for 90 and 270
degrees.
Using other rotation angles still give odd results, should I file a bug
report for this issue?
Regards,
Mark de Wever
Index: plc
patch fixes this issue.
c_plfill3 seems to have the same problem seems to have the same error
(plfill.c:127), I've no test case for it so didn't fix it. Should I post
a bug report or can you fix it quickly?
Regards,
Mark de Wever
Index: sr
Hi,
When I installed plplot (svn trunk) with msvc 2008 I couldn't use plplot due
to a missing header for msvc. The attached patch fixes the problem.
Regards,
Mark de Wever
msvc_cmake.patch
Description: Binary
29 matches
Mail list logo
