SourceForge logo
SourceForge logo
Menu

matplotlib-devel — matplotlib developers

You can subscribe to this list here.

2003 Jan
Feb
Mar
Apr
May
Jun
Jul
Aug
Sep
Oct
(1)
Nov
(33)
Dec
(20)
2004 Jan
(7)
Feb
(44)
Mar
(51)
Apr
(43)
May
(43)
Jun
(36)
Jul
(61)
Aug
(44)
Sep
(25)
Oct
(82)
Nov
(97)
Dec
(47)
2005 Jan
(77)
Feb
(143)
Mar
(42)
Apr
(31)
May
(93)
Jun
(93)
Jul
(35)
Aug
(78)
Sep
(56)
Oct
(44)
Nov
(72)
Dec
(75)
2006 Jan
(116)
Feb
(99)
Mar
(181)
Apr
(171)
May
(112)
Jun
(86)
Jul
(91)
Aug
(111)
Sep
(77)
Oct
(72)
Nov
(57)
Dec
(51)
2007 Jan
(64)
Feb
(116)
Mar
(70)
Apr
(74)
May
(53)
Jun
(40)
Jul
(519)
Aug
(151)
Sep
(132)
Oct
(74)
Nov
(282)
Dec
(190)
2008 Jan
(141)
Feb
(67)
Mar
(69)
Apr
(96)
May
(227)
Jun
(404)
Jul
(399)
Aug
(96)
Sep
(120)
Oct
(205)
Nov
(126)
Dec
(261)
2009 Jan
(136)
Feb
(136)
Mar
(119)
Apr
(124)
May
(155)
Jun
(98)
Jul
(136)
Aug
(292)
Sep
(174)
Oct
(126)
Nov
(126)
Dec
(79)
2010 Jan
(109)
Feb
(83)
Mar
(139)
Apr
(91)
May
(79)
Jun
(164)
Jul
(184)
Aug
(146)
Sep
(163)
Oct
(128)
Nov
(70)
Dec
(73)
2011 Jan
(235)
Feb
(165)
Mar
(147)
Apr
(86)
May
(74)
Jun
(118)
Jul
(65)
Aug
(75)
Sep
(162)
Oct
(94)
Nov
(48)
Dec
(44)
2012 Jan
(49)
Feb
(40)
Mar
(88)
Apr
(35)
May
(52)
Jun
(69)
Jul
(90)
Aug
(123)
Sep
(112)
Oct
(120)
Nov
(105)
Dec
(116)
2013 Jan
(76)
Feb
(26)
Mar
(78)
Apr
(43)
May
(61)
Jun
(53)
Jul
(147)
Aug
(85)
Sep
(83)
Oct
(122)
Nov
(18)
Dec
(27)
2014 Jan
(58)
Feb
(25)
Mar
(49)
Apr
(17)
May
(29)
Jun
(39)
Jul
(53)
Aug
(52)
Sep
(35)
Oct
(47)
Nov
(110)
Dec
(27)
2015 Jan
(50)
Feb
(93)
Mar
(96)
Apr
(30)
May
(55)
Jun
(83)
Jul
(44)
Aug
(8)
Sep
(5)
Oct
Nov
(1)
Dec
(1)
2016 Jan
Feb
Mar
(1)
Apr
May
Jun
(2)
Jul
Aug
(3)
Sep
(1)
Oct
(3)
Nov
Dec
2017 Jan
Feb
(5)
Mar
Apr
May
Jun
Jul
(3)
Aug
Sep
(7)
Oct
Nov
Dec
2018 Jan
Feb
Mar
Apr
May
Jun
Jul
(2)
Aug
Sep
Oct
Nov
Dec
S M T W T F S
1
(1)
2
3
(1)
4
(1)
5
6
(2)
7
(2)
8
(2)
9
(4)
10
(3)
11
12
(1)
13
14
15
16
(3)
17
(5)
18
19
(2)
20
21
22
23
(2)
24
(5)
25
26
27
28
29
30
(1)





Showing 4 results of 4

From: Eric F. <ef...@ha...> - 2012年04月09日 19:38:22
On 04/09/2012 09:25 AM, Michael Gilbert wrote:
> On Mon, Apr 9, 2012 at 1:43 PM, Eric Firing<ef...@ha...> wrote:
>>> Making the polygons overlap by one pdf unit (1/72 of an inch) seems to
>>> make the lines go away at least in Preview. Making them overlap by 0.1
>>> units does not help.
>>
>> Does it make them go away with alpha = 0.5, say?
>
> Setting alpha 0.5 didn't help. It made the contours more transparent
> as expected, but the unwanted lines remain yet with the same amount of
> transparency.
Sorry, my point was that even if the 1/72 overlap "works" with some 
viewers with alpha = 1, I would expect it to cause trouble with non-unit 
alpha, with some if not with all viewers. I don't think there is any 
hack that works in general, and a 1/72 overlap sounds to me like a hack.
Eric
>
> Best wishes,
> Mike
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
From: Michael G. <mic...@gm...> - 2012年04月09日 19:25:07
On Mon, Apr 9, 2012 at 1:43 PM, Eric Firing <ef...@ha...> wrote:
>> Making the polygons overlap by one pdf unit (1/72 of an inch) seems to
>> make the lines go away at least in Preview. Making them overlap by 0.1
>> units does not help.
>
> Does it make them go away with alpha = 0.5, say?
Setting alpha 0.5 didn't help. It made the contours more transparent
as expected, but the unwanted lines remain yet with the same amount of
transparency.
Best wishes,
Mike
From: Eric F. <ef...@ha...> - 2012年04月09日 17:43:41
On 04/09/2012 04:13 AM, Jouni K. Seppänen wrote:
> Benjamin Root<ben...@ou...> writes:
>
>>> It seems that savig a pcolor plot to a pdf format always includes
>>> gridlines, which isn't true for other output formats like png. The
>>> attached example demonstrates this problem. I've only tested this on
>>> version 1.1.1rc1.
>>
>> I have reported something like this before, and it seems that it is
>> dependent upon the PDF viewer and i's settings. Particularly, the
>> antialiasing settings. I have seen this with gs-based viewers. Have you
>> tried others?
>
> I see gridlines in the resulting image in gs, xpdf Preview.app but not
> in Adobe Reader. When I zoom in Preview, the lines jump around a bit,
> and are always the same width on the screen regardless of zoom level.
>
> What gets drawn in this example is a lot of polygons, so that adjacent
> polygons share an edge with the exact same coordinates. The code fills
> the inside of each polygon, and apparently some rendering algorithms
> leave a minimal-width line between polygons.
>
> Making the polygons overlap by one pdf unit (1/72 of an inch) seems to
> make the lines go away at least in Preview. Making them overlap by 0.1
> units does not help.
Does it make them go away with alpha = 0.5, say?
>
> I don't think this can be fixed purely in the pdf backend; it just gets
> a path collection and draws each polygon. I suppose pcolor would need to
> pad the polygons a little, but could it cause problems with other
> backends or use cases? (E.g. if you use alpha blending, neighboring
> rectangles might get gridlines of a darker color where they overlap.)
I'm very skeptical about attempted workarounds such as padding; I would 
be amazed if any of them work over the full range of cases--backends, 
alpha, antialiasing, viewers--while maintaining accuracy of plot element 
placement.
Has cairo solved this problem? Anyone else?
>
> I wonder if drawing zero-width lines between neighboring rectangles,
> e.g. taking the color always from the left or the upper rectangle, would
> work. In matplotlib a line of zero width means no line at all, but in
> the pdf file format it means a line of the smallest possible width,
> which might work well for filling in a missing line of that same
> width. This would need some kind of special-casing in the graphics
> context (because linewidth=0 means to not draw a line) so it's not
> completely trivial to try it out.
Problems occur not just with rectangles but with all patch boundaries, 
such as in contourf. The problem may be most severe with rectangles, 
though.
We have gone around in circles with this problem before.
>
> A different approach would be to output a raster image from pcolor and
> render it with large pixels. I don't know how well that would work with
> Agg, though.
>
I don't understand; wouldn't this wreck accuracy and defeat the purpose 
of using pdf (scalability)?
Eric
From: Jouni K. S. <jk...@ik...> - 2012年04月09日 14:13:47
Benjamin Root <ben...@ou...> writes:
>> It seems that savig a pcolor plot to a pdf format always includes
>> gridlines, which isn't true for other output formats like png. The
>> attached example demonstrates this problem. I've only tested this on
>> version 1.1.1rc1.
>
> I have reported something like this before, and it seems that it is
> dependent upon the PDF viewer and i's settings. Particularly, the
> antialiasing settings. I have seen this with gs-based viewers. Have you
> tried others?
I see gridlines in the resulting image in gs, xpdf Preview.app but not
in Adobe Reader. When I zoom in Preview, the lines jump around a bit,
and are always the same width on the screen regardless of zoom level.
What gets drawn in this example is a lot of polygons, so that adjacent
polygons share an edge with the exact same coordinates. The code fills
the inside of each polygon, and apparently some rendering algorithms
leave a minimal-width line between polygons.
Making the polygons overlap by one pdf unit (1/72 of an inch) seems to
make the lines go away at least in Preview. Making them overlap by 0.1
units does not help.
I don't think this can be fixed purely in the pdf backend; it just gets
a path collection and draws each polygon. I suppose pcolor would need to
pad the polygons a little, but could it cause problems with other
backends or use cases? (E.g. if you use alpha blending, neighboring
rectangles might get gridlines of a darker color where they overlap.)
I wonder if drawing zero-width lines between neighboring rectangles,
e.g. taking the color always from the left or the upper rectangle, would
work. In matplotlib a line of zero width means no line at all, but in
the pdf file format it means a line of the smallest possible width,
which might work well for filling in a missing line of that same
width. This would need some kind of special-casing in the graphics
context (because linewidth=0 means to not draw a line) so it's not
completely trivial to try it out.
A different approach would be to output a raster image from pcolor and
render it with large pixels. I don't know how well that would work with
Agg, though.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Showing 4 results of 4

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X





Briefly describe the problem (required):
Upload screenshot of ad (required):
Select a file, or drag & drop file here.
Screenshot instructions:

Click URL instructions:
Right-click on the ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)

More information about our ad policies

Ad destination/click URL:

AltStyle によって変換されたページ (->オリジナル) /