While I cannot say much about the "compound renderering" in Agg as I know
little about it, but the upsampling method that Mike mentioned seems quite
robust.
Just a quick question, will it affect the rendered quality of AA'ed
artists, like texts? What I mean is, drawing texts w/ AA on (in the
upsamp
Note that we already use a decorator for a similar purpose
(allow_rasterization).
Also, please note that the "draw" method is not just for drawing things.
There are other things being done within the draw method, and I think some
of them still need to be done even though the artist is invisible.
On Tue, Oct 30, 2012 at 12:25 AM, Nicolas Rougier
wrote:
>
>
> Thanks for testing.
>
> If I zoom at any line cross, the lines are definitely at the wrong place for
> me.
As jules hummon commented, I see lines in right places when I zoom in.
> As for screen aliasing I'm not sure since both the
I'd agree with Eric on most of his points.
On Mon, Oct 15, 2012 at 5:22 AM, Eric Firing wrote:
> If some of the PEP8 commits include genuine bug-fixes that need to be in
> v1.2.x, then these fixes should be made via PRs directly against v1.2.x.
I think it is not a good idea to have a PR that mix
On Wed, Aug 22, 2012 at 6:40 AM, Eric Firing wrote:
> Correction: now I can't reproduce what I thought I was seeing; plt.gca()
> is returning an AxesSubplot as it should. Maybe the problem is in the
> axes_grid1 toolkit. It is appearing in the last figure of the
> tight_layout tutorial in the do
Welcome aboard, Phil!
Regards,
-JJ
On Thu, May 31, 2012 at 8:55 PM, John Hunter wrote:
> Phil Elson has been making pull requests for some time now on matters
> great and small, from hairy transformations improvements to minor
> docstring cleanups to GUI fixes. Given his prolific work, I tho
I think what we may do is to make the default value of "scatterponts"
to None, and if None, set it to the value of numpoints.
But, I want to hear how others think about it.
Regards,
-JJ
On Fri, Mar 30, 2012 at 11:39 PM, Pim Schellart wrote:
> Dear all,
>
> there is an inconsistency in the nam
I'm afraid that, unfortunately, it won't be fixed soon (if ever, as
far as I can tell).
What "tight_layout" does is to adjust the *subplot parameters* of the
figure so that the "subplots" fit in. Artists created with figtext
command is not affected by the subplot parameters, i.e. there is not
much
Please see if this PR works.
https://github.com/matplotlib/matplotlib/pull/689
Regards,
-JJ
On Mon, Jan 30, 2012 at 1:03 PM, Jae-Joon Lee wrote:
> On Mon, Jan 30, 2012 at 5:26 AM, Jeff Whitaker wrote:
>> unless matplotlib takes into account all the artist
>> objects associate
On Mon, Jan 30, 2012 at 5:26 AM, Jeff Whitaker wrote:
> unless matplotlib takes into account all the artist
> objects associated with a figure.
My primary reason behind not accounting all the artists was that, in
general, Matplotlib does not know the exact bounding box of artists
when the artists
Hi Eric,
I just pushed a commit that I believe fix the problem.
https://github.com/matplotlib/matplotlib/commit/fcebc2338ad730098520c866122061eefd866641
The documentation now builds fine in my linux box.
Regards,
-JJ
On Tue, Aug 16, 2011 at 8:52 AM, Eric Firing wrote:
> On 08/15/2011 12:07
Sorry for this very very reply.
The error message is now fixed in the git master branch.
Regards,
-JJ
On Fri, May 20, 2011 at 12:31 PM, Steve Ward wrote:
> In legend.__init__ the exception message doesn't match the condition
> that raises it. I think it should say "numpoints must be > 0". I'
On Tue, Jul 12, 2011 at 7:01 PM, Martin Teichmann
wrote:
> (There were some quirks to get sheard images on some backends,
> see examples/api/demo_affine_image.py, but it worked on some backends
> only).
I didn't have time to go through your code carefully, but my
understanding is that you rely on
Hi all,
I thought we have a "v1.0.x" branch on the github repo, but no more.
https://github.com/matplotlib/matplotlib/branches
Hmm...
Is it (accidentally?) removed or do we now use another branch for
maintenance (although I don't see any alternative)?
Regards,
-JJ
Hi,
According to the legend doc,
If label is set to '_nolegend_', the item will not be shown in
legend.
But I think the documented behavior a bit ambiguous. For example,
consider the example below.
l1, = plot([1,2,3], label="_nolegend_")
l2, = plot([2,3,1])
legend(["my line"
I just committed a change that I believe that fixes this problem.
https://github.com/matplotlib/matplotlib/commit/be420a34031c9c50813bc5be5f01a3cfb49639a1
Regards,
-JJ
On Fri, Mar 4, 2011 at 12:58 AM, James Kitchen wrote:
> Hi all,
>
> I found a small bug in the Draggable Legend feature when
On Sun, Feb 13, 2011 at 6:08 AM, Benjamin Root wrote:
> In particular, the following just produces an empty box:
>
This has been fixed in my side, and the fix will be included when I commit.
> Another use-case that doesn't seem addressed yet (and isn't quite right in
> regular mpl either) is leg
On Sun, Jan 30, 2011 at 10:32 PM, Peter Butterworth wrote:
> When plotting interactively is it actually possible to update the
> legend with the current plots while retaining the previous legend
> settings (position, visibility, etc.) ?
>
I think it is possible, but will be quite difficult to do
On Wed, Jan 26, 2011 at 7:28 PM, Pauli Virtanen wrote:
> The complete magic stanza is:
>
> git reflog expire --expire=0 --all
> git prune
> git repack -f -a -d
> git gc --prune=0
Wonderful!
With this, I get about 40 MB!
Regards,
-JJ
-
On Wed, Jan 26, 2011 at 8:38 AM, Darren Dale wrote:
> On Tue, Jan 25, 2011 at 6:12 PM, Darren Dale wrote:
>> There is still an outstanding issue that must be taken care of before
>> we migrate. The conversion routines create a basemap repository out of
>> trunk/toolkits/basemap, and matplotlib re
Big thank you for correcting those typos where virtually all of them are mine.
I'm +1 for backporting these changes as they will not break anything.
But others may have different ideas.
Regards,
-JJ
On Tue, Jan 18, 2011 at 4:35 AM, Paul Ivanov wrote:
> Hi everyone,
>
> I just committed a big
Can you see if setting the "should_simplify" to False work? i.e.,
path=cs.collections[5].get_paths()[0] #210 vertices
path.should_simplify = False
path.to_polygons()
At least, it seems to conserve the number of vertices.
Regards,
-JJ
On Tue, Jan 18, 2011 at 5:07 PM, Lionel Roubeyrie
wrote:
>
Thanks for the patches.
I just committed the getitem patch to the trunk with slight modifications.
As I think this is not a serious bug, I didn't push it to the
maintenance branch.
I'll review the doc patch and commit it later this week.
On the other hand, I don't think it is a good idea to have t
The patch is applied to the maintenance branch (r8846) and the trunk (r8847).
-JJ
On Wed, Dec 22, 2010 at 11:49 PM, Stan West wrote:
>> From: Jae-Joon Lee [mailto:[email protected]]
>> Sent: Monday, December 13, 2010 05:24
>>
>> Attached is a preliminary fix. So, p
I believe this was recently introduced when I refactored the annotation code.
Attached is a preliminary fix. So, please test it if you can.
Since the change during the refactoring was rather significant, I'm
not 100% sure if this will restore the old behavior without affecting
the new functionality
Hi,
I just committed a simple change that disables pstoeps in ps backend
when "xpdf" distiller is used. Without this, output bbox was incorrect
with "xpdf" distiller and usetex=False.
Getting the correct bbox with the ps backend is very tricky, and it'll
be appreciated if others help me test this
On Fri, Nov 5, 2010 at 9:19 AM, Jae-Joon Lee wrote:
> Eric, it seems to be happened because the "_original_facecolor"
> property that you introduced is not initialized in __init__ method but
> in the set_facecolor method. Is there any reason that this cannot be
> initi
This seems to be related to the recent change by Eric.
I just submitted a modified version of demo_text_path.py.
Eric, it seems to be happened because the "_original_facecolor"
property that you introduced is not initialized in __init__ method but
in the set_facecolor method. Is there any reason t
On Sat, Oct 23, 2010 at 7:09 AM, Kynn Jones wrote:
> Without knowing much about the internals of matplotlib, it seems to me that
> the best way to do this would be to define a container class that can have
> itself as one of the contained elements. In this way, a containment
> hierarchy of arbitr
I push the new example in r8740.
Thanks.
-JJ
On Sat, Oct 9, 2010 at 12:15 AM, Stan West wrote:
> Greetings. I initially encountered some difficulty following the
> multiple_yaxis_with_spines example, especially regarding what the functions
> make_patch_spines_invisible and make_spine_invisible
On Thu, Sep 9, 2010 at 4:13 AM, Eric Firing wrote:
> I don't think I understand the point you are making here--is it that the
> Axes3D is a lone anomaly?
>
Yes.
And I feel that Axes3D better not add itself to the figure during the
instance initialization. Just a different view of the current bug.
On Thu, Sep 9, 2010 at 9:38 AM, Eric Firing wrote:
> Fixed in 8693.
>
Thanks!
-JJ
--
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
ht
Eric,
The drawing order of multiple axes in a same figure depends on the
order of "axes". And this has been the order that axes is added to the
figure (given that they have same zorder value). However, the current
implementation does not preserve this order.
For example,
ax1 = axes([0.1, 0.1, 0
On Fri, Sep 3, 2010 at 4:14 AM, Benjamin Root wrote:
> I think there are multiple issues here. Primarially, there is the issue
> that Axes3D is attaching itself to a figure. However, in the interest of
> backwards-compatibility, we can't just fix this outright. There is also the
> issue that th
On Wed, Sep 1, 2010 at 9:33 AM, Benjamin Root wrote:
> matplotlib version 1.0 now has a few different tools that could help you.
> There is GridSpec,
>
> http://matplotlib.sourceforge.net/api/gridspec_api.html#
>
http://matplotlib.sourceforge.net/users/gridspec.html
> There is also AxesGrid1:
t 3:42 AM, Erik Tollerud wrote:
> Did this fix ever get applied? I was looking at some other svn
> changes and it still says none of this part of legend.py has been
> altered...
>
> On Thu, Jun 10, 2010 at 8:50 AM, Jae-Joon Lee wrote:
>> On Wed, Jun 9, 2010 at 7:15 PM, Erik Tol
Michael,
In your commit 8585, you added an extra apply_translation command in
the make_image function (line 594 of image.py, note that there is
another one at line 599).
Currently, imshow command places image in wrong place (except when
interpolation is nearest ) and I think this is because of th
I don't think this is just an issue of "bbox_inches" option. For
example, if you create an axes of rect=[0,0,1,1] and save the figure
(w/o bbox_inches option), you will see a similar behavior.
Also, I believe that the result depends on the backends.
I think this kind of issue is quite difficult to
In r8472, I tried to modify the image slicing so that it works even if
images are rotated and skewed. And the "noslice" option is now gon.
Let me know if it causes any problem.
Regards,
-JJ
On Tue, Jun 22, 2010 at 11:05 PM, Jae-Joon Lee wrote:
> Eric,
>
> I should have
Eric,
I should have left more comments about my change.
The issue is that the current slicing algorithm sometimes fails with
"_draw_unsampled_image" which support arbitrary affine transformation
of the image. The slicing gets wrong when the image is significantly
skewed or rotated. So, as a tempor
n Sat, Jun 5, 2010 at 1:54 PM, Jae-Joon Lee wrote:
> The link to the trunk-version of the documentation
>
> http://matplotlib.sourceforge.net/trunk-docs/
>
> has not been working for a few days.
> And this seems to be due to build failure on one of th build bot.
>
> http:/
On Thu, Jun 10, 2010 at 1:13 PM, Benjamin Root wrote:
> Taking out adjustable='box' had the same effect for me as setting
> adjustable='box-forced
Just a quick comment.
As you can verify, the axes created with AxesGrid will have
adjustable="datalim". With AxesGrid, the size of each axes is adjust
On Wed, Jun 9, 2010 at 7:15 PM, Erik Tollerud wrote:
> Jae-Joon, your patch looks to be effectively the same except for
> slightly different behavior when more than 3 points are present... but
> that was what was originally intended - the numpoints-> scatterpoints
> was a good catch!
I'm not sure
On Wed, Jun 9, 2010 at 6:22 PM, Eric Firing wrote:
> Jeff can correct me if I am wrong, but I think adjustable='box' is
> essential for basemap because the maximum data limits are set when the
> Basemap instance is created. In some cases the characteristics of the
> projection, and in all cases t
tly, the markerscale argument accepts only a scalar, and not a list.
> I don't know how difficult it would be to modify it do that, but it is a
> thought.
>
> Ben Root
>
> On Wed, Jun 9, 2010 at 2:23 PM, Jae-Joon Lee wrote:
>>
>> Thanks for reporting these.
>>
On Wed, Jun 9, 2010 at 4:18 PM, Eric Firing wrote:
> My sense is that box-forced lets you shoot yourself in the foot with
> shared axes, box doesn't. The reason I prohibited sharing x and y axes
> with adjustable as box is that it is not clear what should happen, or
> will happen--fundamental inc
Thanks for reporting these.
I took a look at your patch and slight revised it (see the attached).
While I believe that my patch is compatible to yours, it'll be great
if you check my patch to see if I missed anything.
I'll commit the change soon.
Regards,
-JJ
On Tue, Jun 8, 2010 at 3:16 PM, Eri
The link to the trunk-version of the documentation
http://matplotlib.sourceforge.net/trunk-docs/
has not been working for a few days.
And this seems to be due to build failure on one of th build bot.
http://mpl-buildbot.code.astraw.com/waterfall
However, the the documentation build just fine i
On Sat, Jun 5, 2010 at 12:24 AM, Eric Firing wrote:
>> No, they do work when decorated, I am not claiming that they don't.
>> Maybe the CircleCollection and the EllipseCollection don't need the
>> decorator, but the PolyCollector generates a warning if you set
>> rasterized=True without the decora
On Wed, Jun 2, 2010 at 10:09 PM, Benjamin Root wrote:
> I have noticed that the svn repo still does not have rasterization
> decorators for some of the collections (e.g., PolyCollection,
> EllipseCollection, CircleCollection if I remember correctly). Don't know
> what are supposed to be the final
I'm attaching a copy of my comment to Ben's bug report for a reference.
here is a bug report.
https://sourceforge.net/tracker/index.php?func=detail&aid=3010569&group_id=80706&atid=560720#
My comment:
As far as I can see, this is not a bug of matplotlib, but an artifact of
the rasterizer you're
On Wed, Jun 2, 2010 at 10:51 AM, Benjamin Root wrote:
> This is from the matplotlib-users list. A user noticed that he can not
> change the background color of a 3d plot with arguments to .savefig(). Is
> this a bug or is it intentional?
>
> Thanks,
> Ben Root
I think it is just that they are i
will error out, saying that it has to
> be 'datalim'. What are the implications of using 'box-forced' instead of
> 'box' in Basemap?
>
> Ben Root
>
> On Thu, May 27, 2010 at 1:59 PM, Jae-Joon Lee wrote:
>>
>> ax1 = subplot(121)
>> ax2 = s
It seems that pcolormesh silently ignores some of the keyword
parameters, and "rasterized" is one of them. And I'm not sure this is
intended behavior or not and I hope other developers step in.
In the meantime, use a member method explicitly.
p2 = pcolormesh(arr)
p2.set_rasterized(True)
Regards,
If possible, can you try the latest svn version and see if it makes
any difference?
Also, see if increasing the dpi helps, i.e.,
savefig(..., dpi=150)
Given the nature of the rasterization, I'm not sure if we can
completely avoid the white gap for low dpi settings.
But the displacement issue you
Eric,
Just a minor concern about "locator_params" implicitly calling "autoscale_view".
For example,
ax1 = subplot(121)
ax1.plot([1,2,3])
ax1.locator_params("x", nbins=5)
ax1.margins(0.1, tight=True)
ax2 = subplot(122)
ax2.plot([1,2,3])
ax2.margins(0.1, tight=True)
ax2.locator_params("x", nbins=5
On Mon, Mar 29, 2010 at 12:30 PM, Jeff Klukas wrote:
> # Create BrokenAxes with bottom from 0 to 5 and top from 30 to 35
> ax = plt.broken_axes(ybounds=[0.,5.,30.,35.])
> # Plot a line onto BOTH subaxes
> ax.plot(range(35),range(35))
>
> The call to plot would get routed through __getattribute__,
I guess I misunderstood your original issue.
I think I fixed this in r8210. So please give it a try.
Regards,
-JJ
On Sun, Mar 21, 2010 at 6:42 PM, Anne Archibald
wrote:
> On 21 March 2010 18:10, Jae-Joon Lee wrote:
>>
>>
>> On Sun, Mar 14, 2010 at 3:43 PM, Ann
On Sun, Mar 21, 2010 at 8:10 PM, Fernando Perez wrote:
> Mmh, back to this one: I do think it would be something useful to have
> somewhere, because typing draw() after *every* operation when working
> interactively does get tiresome, it seems to me... If we encourage
> calling subplots() for new
On Sun, Mar 21, 2010 at 6:07 PM, Eric Firing wrote:
> I think your version would need an additional try/except or conditional,
> because a Figure doesn't necessarily have a canvas assigned to it, and a
> canvas doesn't necessarily have a manager. Granted, the problem would arise
> only under odd
On Sun, Mar 14, 2010 at 3:43 PM, Anne Archibald
wrote:
> Often when I want to
> zoom in, I want to change only (say) the upper x and y limits.
>
I pushed a change into the svn that enables this, but in a different way
than you suggested.
The behavior I implemented is similar to the current behavi
On Sat, Mar 20, 2010 at 8:40 PM, Eric Firing wrote:
> By the way, given that we now have "suplots" in the pyplot namespace,
>> can we have sca also?
>>
>
> Done in svn 8205.
>
Eric,
A minor question. I wonder whether an explicit for-loop inside pyplot.sca is
necessary?
Here is a slight variati
On Sun, Mar 21, 2010 at 2:30 PM, Eric Firing wrote:
> Is the added complexity, scrambling pylab into the OO layer, and need for
> explanation, really worth the gain? As far as I can see, it merely adds
one
> more way to do something--and not a particularly recommended way. It is
no
> more concis
On Sat, Mar 20, 2010 at 8:40 PM, Eric Firing wrote:
>
> Done in svn 8205.
>
Thanks!
>>
>> Or, how about we make axes an context manager.
>
> This would require dropping support for Python 2.4.
I don't think making the Axes a context manager means dropping python
2.4 support
(note that I'm not s
On Sat, Mar 20, 2010 at 5:05 AM, Fernando Perez wrote:
> I wonder if it's possible to put things like a draw_if_interactive()
> call at the end of the OO methods... I realize that pyplot was the
> only one meant to do that, but if we are to encourage using the OO api
> more, then it's going to hav
Thanks for the report.
A fix has been committed in r8191 (maint. branch) and r8292 (head).
Give it a try and let me know of any problems.
Regards,
-JJ
On Sat, Mar 13, 2010 at 4:49 PM, Ray Speth wrote:
> Hello,
>
> I am encountering a problem with the legend entries for scatter plots when
> se
Do you have fonts whose family name is "sans serif"?
Maybe you meant "sans-serif"?
"sans-serif" searches for fonts whose family name is in
rcParams["font.sans-serif"], but "sans serif" only search for "sans
serif".
I don't think it has anything to do with annotation.
Check if findfont gives you a
Should be fixed with r8178.
Regards,
-JJ
On Wed, Mar 3, 2010 at 5:19 PM, Jae-Joon Lee wrote:
> On Wed, Mar 3, 2010 at 4:48 PM, John Hunter wrote:
>> JJ is this related to your commit in r8035 : "support
>> unsampled image for ps backend"
>
> It seems to be.
On Wed, Mar 3, 2010 at 4:48 PM, John Hunter wrote:
> JJ is this related to your commit in r8035 : "support
> unsampled image for ps backend"
It seems to be.
I'll take a look.
Regards,
-JJ
--
Download Intel® Parallel St
A few days ago I committed a patch with which I tried to improve the
coordinate handling of annotation.
And I updated the annotation guide which describes the change in some detail.
http://matplotlib.sourceforge.net/trunk-docs/users/annotations_guide.html#using-complex-coordinate-with-annotation
On Thu, Feb 18, 2010 at 11:50 PM, Fernando Perez wrote:
> I defer to your wisdom here: I had no clue about this, so I went for
> the clumsier API. If you are right, it would also make the
> implementation much simpler, as I had to play some not-totally-obvious
> gymnastics to alter axis creation
On Wed, Feb 17, 2010 at 10:17 PM, John Hunter wrote:
> Perhaps the solution to my sharex conundrum is to support an axes number, eg
>
> ax1, ax2, ax3, ax4 = subplots(4,1, sharex=1)
>
I thought there is no master and slave for an axis-sharing?
If that's the case, maybe "sharex=True" should be suf
On Sat, Feb 13, 2010 at 2:23 PM, T J wrote:
> Subclasses of Axes, such as PolarAxes, inherit many functions which
> make implicit assumptions of rectilinear coordinates. From a design
> perspective, it seems like most of these functions should not belong
> to the parent class, and that, perhaps,
Agg backends (in addition to the ps backend) now support
affine-transformed image.
Regards,
-JJ
On Thu, Dec 17, 2009 at 7:05 PM, Jae-Joon Lee wrote:
> On Thu, Dec 17, 2009 at 5:03 PM, Andrew Straw wrote:
>> It's not clear to me if this proposal lets one specify any ar
I just committed the changes.
Regards,
-JJ
On Wed, Jan 27, 2010 at 2:31 PM, Eric Firing wrote:
> Jae-Joon Lee wrote:
>>
>> On Mon, Jan 25, 2010 at 7:19 PM, Jae-Joon Lee
>> wrote:
>>>
>>> Adding a "set_ticks" method seems reasonable.
>>
&
gards,
-JJ
On Wed, Feb 3, 2010 at 4:15 PM, Ryan May wrote:
> On Wed, Feb 3, 2010 at 2:01 PM, Jae-Joon Lee wrote:
>> Dear all,
>>
>> I just committed a small change that enables a user to register a
>> custom backend that will be used with "savefig".
>> F
I'm experimenting with a customized ps backend that saves images in
cmyk colorspace.
It simply converts the rgb image to cmyk (using lcms), and nothing
more (i.e., it does not embed the icc profile inside the eps file).
While I don't see practical usefulness of this other than for a
previewing purp
Dear all,
I just committed a small change that enables a user to register a
custom backend that will be used with "savefig".
For example,
import matplotlib.backend_bases
from matplotlib.backends.backend_ps import FigureCanvasPS, RendererPS
class RendererPSCustom(RendererPS):
def draw_path(se
On Mon, Jan 25, 2010 at 7:19 PM, Jae-Joon Lee wrote:
> Adding a "set_ticks" method seems reasonable.
A patch is attached.
It does some refactoring and introduces three new methods, set_ticks,
set_ticklabels and update_ticks, on the colorbar class.
So, now one can do
imshow(
>
> How do you get around this while supporting both the proportional and the
> non-proportional modes?
>
I must confess that I never considered that option. And, no, my
current implementation does not support non-proportional mode. So, I
guess syncing the data coordinate with ticks has its own p
John and others developers,
I think the current colorbar implementation has some (minor) issue
related with how ticks are treated.
Here is a quick example,
imshow(np.arange(100).reshape((10,10)))
cb = colorbar()
This gives you a nice colorbar, However, an issue arises when you want
to chang
On Tue, Jan 12, 2010 at 5:14 PM, Nico Schlömer wrote:
> I attached a PDF with two figures, one PDF generated and one TikZ
> (generated using my little script). There's clearly a difference in
> how seamless the two figures embed into the document, but I might not
> be using the PDF backend appropr
Matplotlib, by design, needs to know the exact dimension (height,
width and descent) of texts that the backend will produce (before the
output is produced), and I wonder if that's going to be possible with
TikZ.
Unless you can solve this problem, I don't think tikz backend will be feasible.
Some f
The error happens because of the *.rst files under doc/examples that
are not in sync with examples/*.py.
Removing that directory (doc/examples) will solve the problem (the
directory will be repopulated when you run make.py again). Here is a
related link.
http://old.nabble.com/python-make.py-html-f
On Thu, Dec 17, 2009 at 5:03 PM, Andrew Straw wrote:
> It's not clear to me if this proposal lets one specify any arbitrary affine
> transformation. Does it?
I believe it does. 3 coordinates will define 6 equations where we have
6 unknowns of the affine matrix.
The question is how user want to sp
ormation will be calculated internally by the Image class.
Any thought?
-JJ
On Wed, Dec 16, 2009 at 3:41 PM, Andrew Straw wrote:
> Jae-Joon Lee wrote:
>>
>> On Wed, Dec 16, 2009 at 12:59 PM, Jouni K. Seppänen wrote:
>>
>>>
>>> While the back
On Wed, Dec 16, 2009 at 12:59 PM, Jouni K. Seppänen wrote:
> Jae-Joon Lee writes:
>
>> While extending this to other backend such as pdf and svg should be
>> straight forward, I want to hear how others think about the overall
>> approach, e.g., api change and such. Th
A patch that enables drawing image in ps backend without resampling is
committed in r8035.
So, please test it if you're interested.
The raw image is to be used only when interpolation=="nearest" and
there is only one image.
While extending this to other backend such as pdf and svg should be
straig
The recent zorder-related changes broke the some of the rasterization
feature, and I just committed a fix. In doing so, I replaced
dsu.sort(key=lambda x: x[0])
to
dsu.sort(key=itemgetter(0))
which I think is slightly faster (although speed is not much of concern here).
Regards
On Thu, Nov 12, 2009 at 3:45 PM, Jae-Joon Lee wrote:
> By the way, I just encountered some zorder issue with the new patch.
> The thing is, zorder=1 for Images seems to high.
> For example, patches also have zorders=1. So, if I draw an image, and
> add some patches (which I often do
On Wed, Nov 11, 2009 at 7:12 PM, Andrew Straw wrote:
> I had a patch waiting in the wings for that, but I wanted to see the dust
> settle before committing it. I think the dust is officially settled, so
> please commit yours or else I'll commit mine.
>
Please go ahead.
By the way, I just encount
I also committed a small patch that makes zorders respected among
images (not with other artists) for noncomposit backends.
Anyhow, can we get rid of the second items in the "dsu" list? My guess
is that this is to make the sort stable, but python sort is already
stable, isn't it?
-JJ
On Tue, Nov
On Mon, Nov 9, 2009 at 3:55 PM, Andrew Straw wrote:
> What's the motivation of the ps backend "compositing" (rasterizing to a
> single bitmap) multiple images? It seems it will, by design, preclude the
> use of non-image artists between two images. I guess the motivation is to
> reduce output file
On Mon, Nov 9, 2009 at 12:44 PM, Eric Firing wrote:
> PS backend already does things differently from others because it doesn't
> handle alpha, correct? Does the patch make this situation any worse?
>
When there are multiple Images and render.option_image_nocomposite()
is false (as in the ps bac
On Mon, Nov 9, 2009 at 1:01 PM, John Hunter wrote:
> Your
> patch is only applied when len(images)<=1 or
> renderer.option_image_nocomposite(), both of which will be False when
> using Agg with multiple images, no?
I believe renderer.option_image_nocomposite() is True for the agg backend.
So, it
Andrew,
One of my worry is that this can results in inconsistent ouputs
between backends. Your patch only affects backends with compositing
capabilities. And backends such as ps backend will still render images
at the bottom of all other artists.
I think it is often sufficient if we draw images a
ut I suspect freetype on the mac is passing back the
> wrong glyph. So it would seem to point to a freetype problem, or a font
> problem, and specific to the mac.
>
> I did install the latest amsfonts but the bug was still there.
>
> tcb
>
> On Wed, Nov 4, 2009 at 2:32 PM, Ja
; cmmi12
>> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
>> None CMMI12-25
>> cmr17
>> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
>> None CMR17-50
>> cmmi12
>> /usr/local/texlive/2009/texmf-dist/fo
On Tue, Nov 3, 2009 at 4:23 AM, tcb wrote:
> and if I convert the dvi with dvipng, it all seems in order
> (demo_text_path_tex.png). I haven't looked closely into how the textpath
> stuff works, but I thought it would read the dvi as a path, and display that
> on the screen- if that is correct the
Thanks for the report.
And I wonder if you can provide us some more details of your
configuration and do some more tests.
1) You're not using usetex mode, correct?
2) Does your mathtext work fine otherwise? I mean, with the ordinary
text command, not the textpath example.
Regards,
-JJ
On Mon,
1 - 100 of 226 matches
Mail list logo
