Re: [matplotlib-devel] Problem saving to eps with usetex=True
On Wed, Apr 29, 2009 at 4:07 PM, Ken Schutte wrote: > Yes, I'm sorry, I also spoke too soon. I have found problems with > this patch - mainly things like it chopping off xlabel, titles, etc, > for some examples. > I'm not sure if these are related with my patch. Please show some example when you have time. Regards, -JJ -- Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Problem saving to eps with usetex=True
Argg, attached a wrong patch. This one should work
# set the paper size to the figure size if isEPSF. The
# resulting ps file has the given size with correct bounding
# box so that there is no need to call 'pstoeps'
if isEPSF:
paperWidth, paperHeight = self.figure.get_size_inches()
+if isLandscape:
+paperWidth, paperHeight = paperHeight, paperWidth
else:
temp_papertype = _get_papertype(width, height)
if papertype=='auto':
On Wed, Apr 29, 2009 at 5:55 PM, Jae-Joon Lee wrote:
> Thanks Darren,
>
> I believe that my patch only affects eps output with usetex=True,
> i.e., only those "tex_*.eps" files are affected.
>
> I found that my previous patch didn't treated the orientation of the
> paper correctly.
> So the bounding box of all the landscape eps outputs are incorrect.
> This can be easily fixed.
>
> Index: lib/matplotlib/backends/backend_ps.py
> ===
> --- lib/matplotlib/backends/backend_ps.py (revision 7071)
> +++ lib/matplotlib/backends/backend_ps.py (working copy)
> @@ -1100,8 +1100,11 @@
> # set the paper size to the figure size if isEPSF. The
> # resulting ps file has the given size with correct bounding
> # box so that there is no need to call 'pstoeps'
> paperWidth, paperHeight = self.figure.get_size_inches()
> + if isLandscape:
> + paperWidth, paperHeight = paperHeight, paperWidth
> else:
> temp_papertype = _get_papertype(width, height)
> if papertype=='auto':
>
>
>
>
> Anyhow, after the landscape fix, all eps output looks fine to me.
> Can you check this?
>
> Regards,
>
> -JJ
>
>
>
> On Wed, Apr 29, 2009 at 3:55 PM, Darren Dale wrote:
>> Hi Jae-Joon,
>>
>> On Tue, Apr 28, 2009 at 3:49 PM, Jae-Joon Lee wrote:
>>>
>>> This patch is now committed to the trunk (r7068).
>>
>> I think these changes have had unintended consequences. I attached a test
>> file I used to inspect the results when I wrote the original code that you
>> recently tried to improve. There are lots of combinations of large and small
>> figures, with usetex and without, and with no distiller, gs distiller, of
>> xpdf (pdftops) distiller. You have to visually inspect all of the ps/eps
>> files that are generated. At one time, all of these files looked acceptable,
>> but that was a couple years ago and I don't remember what version of
>> ghostscript I was using at the time (I'm sure there is a record of it
>> somewhere on this mailing list). WIth r7067, most of the files look fine, a
>> few of the large files (large paper sizes) have problems. With r7068, quite
>> a few examples have problems.
>>
>> Darren
>>
>>
>>>
>>> On Sat, Apr 25, 2009 at 8:29 AM, Ken Schutte wrote:
>>> > Yeah, that seems to work! thanks a lot,
>>> > Ken
>>> >
>>> > On Fri, Apr 24, 2009 at 5:21 PM, Jae-Joon Lee
>>> > wrote:
>>> >> ps backend, when usetex=True, uses latex with psfrag package to
>>> >> generate the output (with some extra steps).
>>> >> It seems that the bounding box information is not correctly recovered
>>> >> during this process.
>>> >> I first thought that it would be quite difficult to get this correct,
>>> >> however the attached (relatively simple) patch seems to work fine.
>>> >>
>>> >> Ken, can you try the patch and see if it works?
>>> >>
>>> >> -JJ
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> On Thu, Apr 23, 2009 at 2:25 PM, Ken Schutte
>>> >> wrote:
>>> >>> I've been trying to track down some strange behavior I was getting,
>>> >>> and I think narrowed it down to some code that I'll paste below.
>>> >>>
>>> >>> I'm trying to write to .eps files, and when I have usetex=True,
>>> >>> something is screwed up with the padding on the left, and eventually
>>> >>> the whole image is just white.
>>> >>>
>>> >>> If I run this script, the 'testA-*.eps' look good, but 'testB-*' does
>>> >>> not. The same problem happens even if I remove the ticklabels.
>>> >>>
>>> >>> Any tips would be appreciated.
>>> >>> thanks,
>>> >>> Ken
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> import matplotlib.pyplot as plt
>>> >>> import numpy as np
>>> >>> from matplotlib import rc
>>> >>>
>>> >>> fig = plt.figure()
>>> >>> ax = fig.add_axes([0,0,1,1],frameon=False)
>>> >>>
>>> >>> X = np.tile(np.arange(500),(10,1)) # (10,500) shape
>>> >>>
>>> >>> ax.imshow(X,interpolation='nearest',aspect='auto')
>>> >>>
>>> >>> def go(name):
>>> >>>
>>> >>> for d in (1,2,3,4):
>>> >>>
>>> >>> w = d*5
>>> >>> h = d
>>> >>>
>>> >>> fig.set_size_inches(w,h)
>>> >>> fig.savefig("%s-%d.eps" % (name,d))
>>> >>>
>>> >>> rc('text', usetex=False)
>>> >>> go("testA")
>>> >>>
>>> >>> rc('text', usetex=True)
>>> >>> go("testB")
>>> >>>
>>> >>>
>>> >>> --
>>> >>> Crys
Re: [matplotlib-devel] Problem saving to eps with usetex=True
Thanks Darren,
I believe that my patch only affects eps output with usetex=True,
i.e., only those "tex_*.eps" files are affected.
I found that my previous patch didn't treated the orientation of the
paper correctly.
So the bounding box of all the landscape eps outputs are incorrect.
This can be easily fixed.
Index: lib/matplotlib/backends/backend_ps.py
===
--- lib/matplotlib/backends/backend_ps.py (revision 7071)
+++ lib/matplotlib/backends/backend_ps.py (working copy)
@@ -1100,8 +1100,11 @@
# set the paper size to the figure size if isEPSF. The
# resulting ps file has the given size with correct bounding
# box so that there is no need to call 'pstoeps'
paperWidth, paperHeight = self.figure.get_size_inches()
+if isLandscape:
+paperWidth, paperHeight = paperHeight, paperWidth
else:
temp_papertype = _get_papertype(width, height)
if papertype=='auto':
Anyhow, after the landscape fix, all eps output looks fine to me.
Can you check this?
Regards,
-JJ
On Wed, Apr 29, 2009 at 3:55 PM, Darren Dale wrote:
> Hi Jae-Joon,
>
> On Tue, Apr 28, 2009 at 3:49 PM, Jae-Joon Lee wrote:
>>
>> This patch is now committed to the trunk (r7068).
>
> I think these changes have had unintended consequences. I attached a test
> file I used to inspect the results when I wrote the original code that you
> recently tried to improve. There are lots of combinations of large and small
> figures, with usetex and without, and with no distiller, gs distiller, of
> xpdf (pdftops) distiller. You have to visually inspect all of the ps/eps
> files that are generated. At one time, all of these files looked acceptable,
> but that was a couple years ago and I don't remember what version of
> ghostscript I was using at the time (I'm sure there is a record of it
> somewhere on this mailing list). WIth r7067, most of the files look fine, a
> few of the large files (large paper sizes) have problems. With r7068, quite
> a few examples have problems.
>
> Darren
>
>
>>
>> On Sat, Apr 25, 2009 at 8:29 AM, Ken Schutte wrote:
>> > Yeah, that seems to work! thanks a lot,
>> > Ken
>> >
>> > On Fri, Apr 24, 2009 at 5:21 PM, Jae-Joon Lee
>> > wrote:
>> >> ps backend, when usetex=True, uses latex with psfrag package to
>> >> generate the output (with some extra steps).
>> >> It seems that the bounding box information is not correctly recovered
>> >> during this process.
>> >> I first thought that it would be quite difficult to get this correct,
>> >> however the attached (relatively simple) patch seems to work fine.
>> >>
>> >> Ken, can you try the patch and see if it works?
>> >>
>> >> -JJ
>> >>
>> >>
>> >>
>> >>
>> >> On Thu, Apr 23, 2009 at 2:25 PM, Ken Schutte
>> >> wrote:
>> >>> I've been trying to track down some strange behavior I was getting,
>> >>> and I think narrowed it down to some code that I'll paste below.
>> >>>
>> >>> I'm trying to write to .eps files, and when I have usetex=True,
>> >>> something is screwed up with the padding on the left, and eventually
>> >>> the whole image is just white.
>> >>>
>> >>> If I run this script, the 'testA-*.eps' look good, but 'testB-*' does
>> >>> not. The same problem happens even if I remove the ticklabels.
>> >>>
>> >>> Any tips would be appreciated.
>> >>> thanks,
>> >>> Ken
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> import matplotlib.pyplot as plt
>> >>> import numpy as np
>> >>> from matplotlib import rc
>> >>>
>> >>> fig = plt.figure()
>> >>> ax = fig.add_axes([0,0,1,1],frameon=False)
>> >>>
>> >>> X = np.tile(np.arange(500),(10,1)) # (10,500) shape
>> >>>
>> >>> ax.imshow(X,interpolation='nearest',aspect='auto')
>> >>>
>> >>> def go(name):
>> >>>
>> >>> for d in (1,2,3,4):
>> >>>
>> >>> w = d*5
>> >>> h = d
>> >>>
>> >>> fig.set_size_inches(w,h)
>> >>> fig.savefig("%s-%d.eps" % (name,d))
>> >>>
>> >>> rc('text', usetex=False)
>> >>> go("testA")
>> >>>
>> >>> rc('text', usetex=True)
>> >>> go("testB")
>> >>>
>> >>>
>> >>> --
>> >>> Crystal Reports - New Free Runtime and 30 Day Trial
>> >>> Check out the new simplified licensign option that enables unlimited
>> >>> royalty-free distribution of the report engine for externally
>> >>> facing
>> >>> server and web deployment.
>> >>> http://p.sf.net/sfu/businessobjects
>> >>> ___
>> >>> Matplotlib-devel mailing list
>> >>> Matplotlib-devel@lists.sourceforge.net
>> >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> >>>
>> >>
>> >
>>
>>
>> --
>
>
>
>>
>> Register Now & Save for Velocity, the Web Performance & Operations
>> Conference from O'Reilly Media. Velocity features a full day of
>
Re: [matplotlib-devel] Rasterized artists have wrong transform
Jae-Joon Lee wrote: > On Sun, Apr 26, 2009 at 11:31 PM, Eric Bruning wrote: >> I like that this solution doesn't litter every call to draw with >> rasterize checks. But it means that the rasterization support had >> better be robust, since Artist authors might not know they're >> interacting with the rasterization code. It has the downside of being >> implicit rather than explicit. > > Eric, > I think we'd better stick to your decorator solution. > > Anyhow, I thought you had a svn commit permission but it seems not. Do > you (and other dwevelopers) mind if I commit this patch to the trunk? It would be especially good for John and Mike to have a look. As a matter of style, I suggest a name change. "@hook_before_after_draw" is too generic, and brings to mind discussions a long time ago about possibly adding a general hook mechanism; even before rasterization, and before decorators were available, there were thoughts that we might need this. (Now I don't remember what the motivation was, but I think it had to do with coordinating different elements of a plot.) In any case, the decorator is actually very specific to rasterization, so maybe call it "@with_rasterization" or "@allow_rasterization". I am very anxious to see rasterization support in place; let's just be sure we have a good API and mechanism. The patch looks reasonable to me, but I have no experience in writing decorators, and have not had time to really think about the rasterization API problem. Eric > > One I thing I want to add your patch is to warn users when they set > "rasterized" attribute of the artists whose draw method is not > decorated. I'll think about it later but feel free to propose any. > > Thanks, > > -JJ > > -- > Register Now & Save for Velocity, the Web Performance & Operations > Conference from O'Reilly Media. Velocity features a full day of > expert-led, hands-on workshops and two days of sessions from industry > leaders in dedicated Performance & Operations tracks. Use code vel09scf > and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Problem saving to eps with usetex=True
Yes, I'm sorry, I also spoke too soon. I have found problems with
this patch - mainly things like it chopping off xlabel, titles, etc,
for some examples.
I have some major deadlines using this stuff right now, so I don't
have time to experiment. But, eventually, I will try to take a look
at what is happening.
Ken
On Wed, Apr 29, 2009 at 3:56 PM, Darren Dale wrote:
> The test file is attached this time.
>
> On Wed, Apr 29, 2009 at 3:55 PM, Darren Dale wrote:
>>
>> Hi Jae-Joon,
>>
>> On Tue, Apr 28, 2009 at 3:49 PM, Jae-Joon Lee
>> wrote:
>>>
>>> This patch is now committed to the trunk (r7068).
>>
>> I think these changes have had unintended consequences. I attached a test
>> file I used to inspect the results when I wrote the original code that you
>> recently tried to improve. There are lots of combinations of large and small
>> figures, with usetex and without, and with no distiller, gs distiller, of
>> xpdf (pdftops) distiller. You have to visually inspect all of the ps/eps
>> files that are generated. At one time, all of these files looked acceptable,
>> but that was a couple years ago and I don't remember what version of
>> ghostscript I was using at the time (I'm sure there is a record of it
>> somewhere on this mailing list). WIth r7067, most of the files look fine, a
>> few of the large files (large paper sizes) have problems. With r7068, quite
>> a few examples have problems.
>>
>> Darren
>>
>>
>>>
>>> On Sat, Apr 25, 2009 at 8:29 AM, Ken Schutte wrote:
>>> > Yeah, that seems to work! thanks a lot,
>>> > Ken
>>> >
>>> > On Fri, Apr 24, 2009 at 5:21 PM, Jae-Joon Lee
>>> > wrote:
>>> >> ps backend, when usetex=True, uses latex with psfrag package to
>>> >> generate the output (with some extra steps).
>>> >> It seems that the bounding box information is not correctly recovered
>>> >> during this process.
>>> >> I first thought that it would be quite difficult to get this correct,
>>> >> however the attached (relatively simple) patch seems to work fine.
>>> >>
>>> >> Ken, can you try the patch and see if it works?
>>> >>
>>> >> -JJ
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> On Thu, Apr 23, 2009 at 2:25 PM, Ken Schutte
>>> >> wrote:
>>> >>> I've been trying to track down some strange behavior I was getting,
>>> >>> and I think narrowed it down to some code that I'll paste below.
>>> >>>
>>> >>> I'm trying to write to .eps files, and when I have usetex=True,
>>> >>> something is screwed up with the padding on the left, and eventually
>>> >>> the whole image is just white.
>>> >>>
>>> >>> If I run this script, the 'testA-*.eps' look good, but 'testB-*' does
>>> >>> not. The same problem happens even if I remove the ticklabels.
>>> >>>
>>> >>> Any tips would be appreciated.
>>> >>> thanks,
>>> >>> Ken
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> import matplotlib.pyplot as plt
>>> >>> import numpy as np
>>> >>> from matplotlib import rc
>>> >>>
>>> >>> fig = plt.figure()
>>> >>> ax = fig.add_axes([0,0,1,1],frameon=False)
>>> >>>
>>> >>> X = np.tile(np.arange(500),(10,1)) # (10,500) shape
>>> >>>
>>> >>> ax.imshow(X,interpolation='nearest',aspect='auto')
>>> >>>
>>> >>> def go(name):
>>> >>>
>>> >>> for d in (1,2,3,4):
>>> >>>
>>> >>> w = d*5
>>> >>> h = d
>>> >>>
>>> >>> fig.set_size_inches(w,h)
>>> >>> fig.savefig("%s-%d.eps" % (name,d))
>>> >>>
>>> >>> rc('text', usetex=False)
>>> >>> go("testA")
>>> >>>
>>> >>> rc('text', usetex=True)
>>> >>> go("testB")
>>> >>>
>>> >>>
>>> >>> --
>>> >>> Crystal Reports - New Free Runtime and 30 Day Trial
>>> >>> Check out the new simplified licensign option that enables unlimited
>>> >>> royalty-free distribution of the report engine for externally
>>> >>> facing
>>> >>> server and web deployment.
>>> >>> http://p.sf.net/sfu/businessobjects
>>> >>> ___
>>> >>> Matplotlib-devel mailing list
>>> >>> Matplotlib-devel@lists.sourceforge.net
>>> >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>> >>>
>>> >>
>>> >
>>>
>>>
>>> --
>>
>>
>>
>>>
>>> Register Now & Save for Velocity, the Web Performance & Operations
>>> Conference from O'Reilly Media. Velocity features a full day of
>>> expert-led, hands-on workshops and two days of sessions from industry
>>> leaders in dedicated Performance & Operations tracks. Use code vel09scf
>>> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
>>> ___
>>> Matplotlib-devel mailing list
>>> Matplotlib-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>
--
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity feat
[matplotlib-devel] Solaris and GCC 4.3.x: error TTStreamWriter has no putc
When attempting to build matplotlib 0.98.5.2 on Solaris 10 using GCC
4.3.3, I get an error:
ttconv/pprdrv_tt2.cpp: In member function ‘void
GlyphToType3::stack(TTStreamWriter&, int)’:
ttconv/pprdrv_tt2.cpp:107: error: ‘class TTStreamWriter’ has no member
named ‘putc’
So I tried invoking GCC with the -E flag to get the output of the
preprocessor and I see that line 107 of pprdrv_tt2.cpp gets rewritten to:
stream.putc(('{'), (&__iob[1]));
so it seems that something in GCC 4.3.3 on Solaris is defining a putchar
macro that is doing this, but not correspondingly being applied to the
pprdrv.h.
Searching the list archives, I see that back in July & August, 2008
there was a brief thread between Peter Norton and Mike Droettboom about
this and a proposal was made to rename TTStreamWriter::putchar to
TTStreamWriter:put_char. I just looked at the trunk and it looks like
this has never been done. Was there some other work-around that didn't
make it into the thread that obviated the need for the mentioned change?
I can confirm that the renaming of putchar to put_char does solve the
problem. I've attached a patch file, though it is against 0.98.5.2.
-- Dave
--- ttconv/pprdrv.h Wed Apr 29 15:04:00 2009
+++ ttconv/pprdrv.h Wed Apr 29 15:08:46 2009
@@ -40,7 +40,7 @@
virtual void write(const char*) = 0;
virtual void printf(const char* format, ...);
- virtual void putchar(int val);
+ virtual void put_char(int val);
virtual void puts(const char* a);
virtual void putline(const char* a);
};
--- ttconv/pprdrv_tt.cppWed Apr 29 15:06:16 2009
+++ ttconv/pprdrv_tt.cppWed Apr 29 15:08:46 2009
@@ -482,20 +482,20 @@
if(!in_string)
{
- stream.putchar('<');
+ stream.put_char('<');
string_len=0;
line_len++;
in_string=TRUE;
}
-stream.putchar( hexdigits[ n / 16 ] );
-stream.putchar( hexdigits[ n % 16 ] );
+stream.put_char( hexdigits[ n / 16 ] );
+stream.put_char( hexdigits[ n % 16 ] );
string_len++;
line_len+=2;
if(line_len > 70)
{
- stream.putchar('\n');
+ stream.put_char('\n');
line_len=0;
}
@@ -548,7 +548,7 @@
#endif
sfnts_pputBYTE(stream, 0); /* extra byte for pre-2013
compatibility */
- stream.putchar('>');
+ stream.put_char('>');
line_len++;
}
in_string=FALSE;
@@ -955,7 +955,7 @@
/* a BuildGlyph and BuildChar proceedures. */
if( font->target_type == PS_TYPE_3 )
{
- stream.putchar('\n');
+ stream.put_char('\n');
stream.putline("/BuildGlyph");
stream.putline(" {exch begin"); /* start font dictionary */
@@ -964,7 +964,7 @@
stream.putline(" true 3 1 roll get exec");
stream.putline(" end}_d");
- stream.putchar('\n');
+ stream.put_char('\n');
/* This proceedure is for compatiblity with */
/* level 1 interpreters. */
@@ -973,7 +973,7 @@
stream.putline(" 1 index /BuildGlyph get exec");
stream.putline("}_d");
- stream.putchar('\n');
+ stream.put_char('\n');
}
/* If we are generating a type 42 font, we need to check to see */
@@ -985,7 +985,7 @@
/* setup instructions and part of BuildGlyph came from. */
else if( font->target_type == PS_TYPE_42 )
{
- stream.putchar('\n');
+ stream.put_char('\n');
/* If we have no "resourcestatus" command, or FontType 42 */
/* is unknown, leave "true" on the stack. */
@@ -1066,7 +1066,7 @@
/* if the printer has no built-in TrueType */
/* rasterizer. */
stream.putline("}if");
- stream.putchar('\n');
+ stream.put_char('\n');
} /* end of if Type 42 not understood. */
stream.putline("FontName currentdict end definefont pop");
--- ttconv/pprdrv_tt2.cpp Wed Apr 29 15:10:48 2009
+++ ttconv/pprdrv_tt2.cpp Wed Apr 29 15:08:46 2009
@@ -104,7 +104,7 @@
{ /* have a log of points. */
if(stack_depth == 0)
{
- stream.putchar('{');
+ stream.put_char('{');
stack_depth=1;
}
--- ttconv/ttutil.cpp Wed Apr 29 15:04:25 2009
+++ ttconv/ttutil.cpp Wed Apr 29 15:08:46 2009
@@ -52,7 +52,7 @@
va_end(arg_list);
}
-void TTStreamWriter::putchar(int val)
+void TTStreamWriter::put_char(int val)
{
char c[2];
c[0] = (char)val;
--
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf___
Matplotlib-devel mailing list
Mat
Re: [matplotlib-devel] Problem saving to eps with usetex=True
The test file is attached this time.
On Wed, Apr 29, 2009 at 3:55 PM, Darren Dale wrote:
> Hi Jae-Joon,
>
> On Tue, Apr 28, 2009 at 3:49 PM, Jae-Joon Lee wrote:
>
>> This patch is now committed to the trunk (r7068).
>>
>
> I think these changes have had unintended consequences. I attached a test
> file I used to inspect the results when I wrote the original code that you
> recently tried to improve. There are lots of combinations of large and small
> figures, with usetex and without, and with no distiller, gs distiller, of
> xpdf (pdftops) distiller. You have to visually inspect all of the ps/eps
> files that are generated. At one time, all of these files looked acceptable,
> but that was a couple years ago and I don't remember what version of
> ghostscript I was using at the time (I'm sure there is a record of it
> somewhere on this mailing list). WIth r7067, most of the files look fine, a
> few of the large files (large paper sizes) have problems. With r7068, quite
> a few examples have problems.
>
> Darren
>
>
>
>>
>>
>> On Sat, Apr 25, 2009 at 8:29 AM, Ken Schutte wrote:
>> > Yeah, that seems to work! thanks a lot,
>> > Ken
>> >
>> > On Fri, Apr 24, 2009 at 5:21 PM, Jae-Joon Lee
>> wrote:
>> >> ps backend, when usetex=True, uses latex with psfrag package to
>> >> generate the output (with some extra steps).
>> >> It seems that the bounding box information is not correctly recovered
>> >> during this process.
>> >> I first thought that it would be quite difficult to get this correct,
>> >> however the attached (relatively simple) patch seems to work fine.
>> >>
>> >> Ken, can you try the patch and see if it works?
>> >>
>> >> -JJ
>> >>
>> >>
>> >>
>> >>
>> >> On Thu, Apr 23, 2009 at 2:25 PM, Ken Schutte
>> wrote:
>> >>> I've been trying to track down some strange behavior I was getting,
>> >>> and I think narrowed it down to some code that I'll paste below.
>> >>>
>> >>> I'm trying to write to .eps files, and when I have usetex=True,
>> >>> something is screwed up with the padding on the left, and eventually
>> >>> the whole image is just white.
>> >>>
>> >>> If I run this script, the 'testA-*.eps' look good, but 'testB-*' does
>> >>> not. The same problem happens even if I remove the ticklabels.
>> >>>
>> >>> Any tips would be appreciated.
>> >>> thanks,
>> >>> Ken
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> import matplotlib.pyplot as plt
>> >>> import numpy as np
>> >>> from matplotlib import rc
>> >>>
>> >>> fig = plt.figure()
>> >>> ax = fig.add_axes([0,0,1,1],frameon=False)
>> >>>
>> >>> X = np.tile(np.arange(500),(10,1)) # (10,500) shape
>> >>>
>> >>> ax.imshow(X,interpolation='nearest',aspect='auto')
>> >>>
>> >>> def go(name):
>> >>>
>> >>>for d in (1,2,3,4):
>> >>>
>> >>>w = d*5
>> >>>h = d
>> >>>
>> >>>fig.set_size_inches(w,h)
>> >>>fig.savefig("%s-%d.eps" % (name,d))
>> >>>
>> >>> rc('text', usetex=False)
>> >>> go("testA")
>> >>>
>> >>> rc('text', usetex=True)
>> >>> go("testB")
>> >>>
>> >>>
>> --
>> >>> Crystal Reports - New Free Runtime and 30 Day Trial
>> >>> Check out the new simplified licensign option that enables unlimited
>> >>> royalty-free distribution of the report engine for externally
>> facing
>> >>> server and web deployment.
>> >>> http://p.sf.net/sfu/businessobjects
>> >>> ___
>> >>> Matplotlib-devel mailing list
>> >>> Matplotlib-devel@lists.sourceforge.net
>> >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> >>>
>> >>
>> >
>>
>>
>> --
>>
>
>
>
>
>> Register Now & Save for Velocity, the Web Performance & Operations
>> Conference from O'Reilly Media. Velocity features a full day of
>> expert-led, hands-on workshops and two days of sessions from industry
>> leaders in dedicated Performance & Operations tracks. Use code vel09scf
>> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
>> ___
>> Matplotlib-devel mailing list
>> Matplotlib-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>
from pylab import *
from matplotlib import rcParams
rcParams['text.usetex'] = False
rcParams['ps.usedistiller'] = None
figure(figsize=(10,5))
plot([1,2,3,4])
savefig('notex_nodist_pm.ps', orientation='portrait', papertype='letter')
savefig('notex_nodist_lm.ps', orientation='landscape', papertype='letter')
savefig('notex_nodist_pm.eps', orientation='portrait')
savefig('notex_nodist_lm.eps', orientation='landscape')
rcParams['text.usetex'] = False
rcParams['ps.usedistiller'] = 'ghostscript'
figure(figsize=(10,5))
plot([1,2,3,4])
savefig('notex_gs_pm.ps', orientation='portrait', papertype='letter')
savefig('notex_gs_lm.ps', orientation='landscape', papertype='letter')
savefig('notex_gs_pm.eps'
Re: [matplotlib-devel] Problem saving to eps with usetex=True
Hi Jae-Joon,
On Tue, Apr 28, 2009 at 3:49 PM, Jae-Joon Lee wrote:
> This patch is now committed to the trunk (r7068).
>
I think these changes have had unintended consequences. I attached a test
file I used to inspect the results when I wrote the original code that you
recently tried to improve. There are lots of combinations of large and small
figures, with usetex and without, and with no distiller, gs distiller, of
xpdf (pdftops) distiller. You have to visually inspect all of the ps/eps
files that are generated. At one time, all of these files looked acceptable,
but that was a couple years ago and I don't remember what version of
ghostscript I was using at the time (I'm sure there is a record of it
somewhere on this mailing list). WIth r7067, most of the files look fine, a
few of the large files (large paper sizes) have problems. With r7068, quite
a few examples have problems.
Darren
>
>
> On Sat, Apr 25, 2009 at 8:29 AM, Ken Schutte wrote:
> > Yeah, that seems to work! thanks a lot,
> > Ken
> >
> > On Fri, Apr 24, 2009 at 5:21 PM, Jae-Joon Lee
> wrote:
> >> ps backend, when usetex=True, uses latex with psfrag package to
> >> generate the output (with some extra steps).
> >> It seems that the bounding box information is not correctly recovered
> >> during this process.
> >> I first thought that it would be quite difficult to get this correct,
> >> however the attached (relatively simple) patch seems to work fine.
> >>
> >> Ken, can you try the patch and see if it works?
> >>
> >> -JJ
> >>
> >>
> >>
> >>
> >> On Thu, Apr 23, 2009 at 2:25 PM, Ken Schutte
> wrote:
> >>> I've been trying to track down some strange behavior I was getting,
> >>> and I think narrowed it down to some code that I'll paste below.
> >>>
> >>> I'm trying to write to .eps files, and when I have usetex=True,
> >>> something is screwed up with the padding on the left, and eventually
> >>> the whole image is just white.
> >>>
> >>> If I run this script, the 'testA-*.eps' look good, but 'testB-*' does
> >>> not. The same problem happens even if I remove the ticklabels.
> >>>
> >>> Any tips would be appreciated.
> >>> thanks,
> >>> Ken
> >>>
> >>>
> >>>
> >>>
> >>> import matplotlib.pyplot as plt
> >>> import numpy as np
> >>> from matplotlib import rc
> >>>
> >>> fig = plt.figure()
> >>> ax = fig.add_axes([0,0,1,1],frameon=False)
> >>>
> >>> X = np.tile(np.arange(500),(10,1)) # (10,500) shape
> >>>
> >>> ax.imshow(X,interpolation='nearest',aspect='auto')
> >>>
> >>> def go(name):
> >>>
> >>>for d in (1,2,3,4):
> >>>
> >>>w = d*5
> >>>h = d
> >>>
> >>>fig.set_size_inches(w,h)
> >>>fig.savefig("%s-%d.eps" % (name,d))
> >>>
> >>> rc('text', usetex=False)
> >>> go("testA")
> >>>
> >>> rc('text', usetex=True)
> >>> go("testB")
> >>>
> >>>
> --
> >>> Crystal Reports - New Free Runtime and 30 Day Trial
> >>> Check out the new simplified licensign option that enables unlimited
> >>> royalty-free distribution of the report engine for externally
> facing
> >>> server and web deployment.
> >>> http://p.sf.net/sfu/businessobjects
> >>> ___
> >>> Matplotlib-devel mailing list
> >>> Matplotlib-devel@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >>>
> >>
> >
>
>
> --
>
> Register Now & Save for Velocity, the Web Performance & Operations
> Conference from O'Reilly Media. Velocity features a full day of
> expert-led, hands-on workshops and two days of sessions from industry
> leaders in dedicated Performance & Operations tracks. Use code vel09scf
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] SF.net SVN: matplotlib:[7070] trunk/matplotlib
On Wed, Apr 29, 2009 at 19:51, John Hunter wrote: > On Wed, Apr 29, 2009 at 12:13 PM, Sandro Tosi wrote: >> >> On Wed, Apr 29, 2009 at 18:07, wrote: >> > Log Message: >> > --- >> > add masked array support to fill_between >> > >> > Modified Paths: >> > -- >> > trunk/matplotlib/examples/user_interfaces/embedding_in_gtk.py >> > trunk/matplotlib/examples/user_interfaces/embedding_in_gtk2.py >> >> is the switch to FigureCanvasGTKAgg in the examples somewhat related to... >> >> > trunk/matplotlib/lib/matplotlib/axes.py >> >> ...supporting masked array here? >> >> I'm asking because I'm studying those embedded_in_gtk* examples to >> learn/describe how to embed mpl into gtk :) > > No, it is unrelated; my commit message was incomplete. :) > I was demo-ing the embedding example to a colleague and got a gtk drawing > error (we have an older pygtk error here). Apparently our backend gtk api > is not consistent with all the pygtk's in the wild. With gtkcairo and > gtkagg, I am not too concerned with this, so I just changed the default to > gtkagg for that example which will work out of the box for more users, and > we always try to push people onto *agg where feasible. and I also got a reply for my next question "why this change?" :) Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] SF.net SVN: matplotlib:[7070] trunk/matplotlib
On Wed, Apr 29, 2009 at 12:13 PM, Sandro Tosi wrote: > On Wed, Apr 29, 2009 at 18:07, wrote: > > Log Message: > > --- > > add masked array support to fill_between > > > > Modified Paths: > > -- > >trunk/matplotlib/examples/user_interfaces/embedding_in_gtk.py > >trunk/matplotlib/examples/user_interfaces/embedding_in_gtk2.py > > is the switch to FigureCanvasGTKAgg in the examples somewhat related to... > > >trunk/matplotlib/lib/matplotlib/axes.py > > ...supporting masked array here? > > I'm asking because I'm studying those embedded_in_gtk* examples to > learn/describe how to embed mpl into gtk :) No, it is unrelated; my commit message was incomplete. I was demo-ing the embedding example to a colleague and got a gtk drawing error (we have an older pygtk error here). Apparently our backend gtk api is not consistent with all the pygtk's in the wild. With gtkcairo and gtkagg, I am not too concerned with this, so I just changed the default to gtkagg for that example which will work out of the box for more users, and we always try to push people onto *agg where feasible. JDH -- Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] SF.net SVN: matplotlib:[7070] trunk/matplotlib
On Wed, Apr 29, 2009 at 18:07, wrote: > Log Message: > --- > add masked array support to fill_between > > Modified Paths: > -- > trunk/matplotlib/examples/user_interfaces/embedding_in_gtk.py > trunk/matplotlib/examples/user_interfaces/embedding_in_gtk2.py is the switch to FigureCanvasGTKAgg in the examples somewhat related to... > trunk/matplotlib/lib/matplotlib/axes.py ...supporting masked array here? I'm asking because I'm studying those embedded_in_gtk* examples to learn/describe how to embed mpl into gtk :) Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Rasterized artists have wrong transform
On Sun, Apr 26, 2009 at 11:31 PM, Eric Bruning wrote: > I like that this solution doesn't litter every call to draw with > rasterize checks. But it means that the rasterization support had > better be robust, since Artist authors might not know they're > interacting with the rasterization code. It has the downside of being > implicit rather than explicit. Eric, I think we'd better stick to your decorator solution. Anyhow, I thought you had a svn commit permission but it seems not. Do you (and other dwevelopers) mind if I commit this patch to the trunk? One I thing I want to add your patch is to warn users when they set "rasterized" attribute of the artists whose draw method is not decorated. I'll think about it later but feel free to propose any. Thanks, -JJ -- Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] backend_cairo.py clipping, bug in SVN
Yeah -- this looks like a bad merge from the branch. The branch's version of convert_path takes two arguments, the trunk takes three because it was updated to support path simplification routines which do their own transformation. The trunk has been updated to use the three-argument form consistently (r7069). Mike Michiel de Hoon wrote: > Hi everybody, > > I believe a bug was introduced in revision 7002 of backend_cairo.py. > This code, in two places, now calls RendererCairo.convert_path with two > arguments (ctx and tpath), whereas RendererCairo.convert_path expects three > arguments. In one other place, RendererCairo.convert_path is called > (correctly) with three arguments. One example of the code containing the bug > is > > tpath, affine = clippath.get_transformed_path_and_affine() > ctx.new_path() > affine = affine + Affine2D().scale(1.0, -1.0).translate(0.0, self.height) > tpath = affine.transform_path(tpath) > RendererCairo.convert_path(ctx, tpath) > > Before this revision, the corresponding code was > > tpath, affine = path.get_transformed_path_and_affine() > ctx.new_path() > affine = affine + Affine2D().scale(1.0, -1.0).translate(0.0, > self.renderer.height) > RendererCairo.convert_path(ctx, path, affine) > > RendererCairo.convert_path is defined as > >@staticmethod > def convert_path(ctx, path, transform): > > so with three arguments. Either the calls to convert_path are incorrect, or > convert_path should be updated to handle two arguments. > > --Michiel > > > > > -- > Register Now & Save for Velocity, the Web Performance & Operations > Conference from O'Reilly Media. Velocity features a full day of > expert-led, hands-on workshops and two days of sessions from industry > leaders in dedicated Performance & Operations tracks. Use code vel09scf > and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA -- Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
