On Mar 4, 2015, at 8:50 PM, "Alan W. Irwin" wrote:
> On 2015-03-04 16:07-0500 Jim Dishaw wrote:
>
>>
>> On Mar 4, 2015, at 4:01 PM, Phil Rosenberg wrote:
>>
> Regarding non-solid lines, are you referring to dashed lines? If so what
> is the issue?
>>>
The devices have differen
On 2015-03-04 16:07-0500 Jim Dishaw wrote:
>
> On Mar 4, 2015, at 4:01 PM, Phil Rosenberg wrote:
>
Regarding non-solid lines, are you referring to dashed lines? If so what
is the issue?
>>
>>> The devices have different number of pixels, which results in a different
>>> number of dash
On 2015-03-04 13:09-0500 Jim Dishaw wrote:
> The reason I ask is because plpoin and plsym use symht/symdef and the
> plstring documentation mentions that it supersedes those two functions.
>
> The plstring function passes the string to plP_text to render the text and
> plP_text uses chrht/chrdef
On Mar 4, 2015, at 4:01 PM, Phil Rosenberg wrote:
>>> Regarding non-solid lines, are you referring to dashed lines? If so what is
>>> the issue?
>
>> The devices have different number of pixels, which results in a different
>> number of dashes.
>
> The plplot docs state that the dash sizes a
Okay
I will leave that with you then
Thanks
Phil
On 4 March 2015 at 15:07, Jim Dishaw wrote:
>
>> On Mar 4, 2015, at 9:13 AM, Phil Rosenberg wrote:
>>
>> Hi Jim
>> There is still a bug in the buffer with respect to the correct state
>> parameters. I think we discussed this in the past regarding
>>Regarding non-solid lines, are you referring to dashed lines? If so what is
>>the issue?
>The devices have different number of pixels, which results in a different
>number of dashes.
The plplot docs state that the dash sizes are specified in mm. They
should therefore be saved in the buffer as
Thanks for the heads up Alan, especially the Valgrind output and the
reproduction method. Very handy!
Regardign the surface pattern artefacts. I had already spotted them
and x08.1 is on the trello page. It appears to be a bad antiaiasing
issue or rounding issue, basically adjacent polygons don't q
Hi Phil:
Your latest commit (f6dcf09703 = "Fixed reentrant behaviour in
wxPLViewer...") mostly works. For example, it builds without
issues, and examples 1 and 4 (the first two run by the
test_c_wxwidgets target) appear to work at run-time with
no obvious issues. However, example 8 now has a sub
The reason I ask is because plpoin and plsym use symht/symdef and the plstring
documentation mentions that it supersedes those two functions.
The plstring function passes the string to plP_text to render the text and
plP_text uses chrht/chrdef. The plpoin and plsym use plhersh, which changes
On Mar 4, 2015, at 6:04 AM, "Alan W. Irwin" wrote:
>
> Of course, it is always true that if you store raw user input (as
> opposed to some transformed result) in the plmeta file and then
> plrender calls the relevant plplot routine with that raw user data,
> then the direct and indirect result
> On Mar 4, 2015, at 9:13 AM, Phil Rosenberg wrote:
>
> Hi Jim
> There is still a bug in the buffer with respect to the correct state
> parameters. I think we discussed this in the past regarding plplot
> initialisation, but this particular bug occurs at page change.
>
> Basically at the beginn
> On Mar 4, 2015, at 6:04 AM, Alan W. Irwin wrote:
>
>> On 2015-03-04 02:41-0500 Jim Dishaw wrote:
>>
>> I have gotten things to the point where the differences are due to
> round off error, the rendering of non-solid lines, and plot symbols
> generated by commands that utilize plhrsh (i.e. pls
> On Mar 4, 2015, at 5:04 AM, Phil Rosenberg wrote:
>
> Hi Jim
> My thoughts would be to save all text and symbols, including Hershey text as
> text not vector outlines. As you say, some devices use Hershey as a fall
> back, because they cannot render text themselves, but in general we want to
Hi Jim
There is still a bug in the buffer with respect to the correct state
parameters. I think we discussed this in the past regarding plplot
initialisation, but this particular bug occurs at page change.
Basically at the beginning of a render, plplot inherits it's state
from the previous render
On 2015-03-04 02:41-0500 Jim Dishaw wrote:
> I have gotten things to the point where the differences are due to
round off error, the rendering of non-solid lines, and plot symbols
generated by commands that utilize plhrsh (i.e. plsym, plpoin, and
plpoin3).
Thanks, Jim. Sounds like you have made
OK. Here's my results for your precise tests - completely clean.
andrew@andrew-laptop:~/software/plplot/build_qt5$ ldd -r drivers/qt.so |& grep
-i qt
libQt5Svg.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Svg.so.5
(0x7f09fff34000)
libQt5Gui.so.5 => /usr/lib/x86_64-linux-gnu/libQt
Hi Jim
My thoughts would be to save all text and symbols, including Hershey text as
text not vector outlines. As you say, some devices use Hershey as a fall back,
because they cannot render text themselves, but in general we want to make use
of the font rendering capability of the rendering devi
17 matches
Mail list logo
