Re: [matplotlib-devel] rgb versus cmyk
Hi, > Publishers sometimes require electronic figures as tif or eps, and using > the cymk color system. We do everything in rgb. I don't understand > color systems well. What would be needed to give mpl the ability to > produce files using the cymk system? I don't understand color systems very well, either, but I ran into this problem when I printed out some color figures recently. I saved a mpl line plot containing 'r', 'g' and 'b' lines to a PDF file. The file displayed on-screen as expected, using both Linux acroread and Mac OS X Preview as viewer. It also printed out as expected on an HP Color Laserjet via Linux acroread. On the Mac, however, a straightforward printout resulted in purple instead of blue lines. The problem disappeared when I selected ColorSync -> Color Conversion -> In Printer in the print dialog. When I printed out an OmniGraffle PDF diagram, however, the colors were messed up using "In Printer" and correct when using "Standard" color conversion. This forced me to print the color pages in my thesis containing OmniGraffle diagrams and mpl figures using different printer settings, which is quite annoying. There is another option, which makes Linux and Mac PDFs much more compatible (especially for color), and that is PDF/X-3 (http://en.wikipedia.org/wiki/PDF/X). This subset of PDF forces the document to include all fonts and color profiles, leaving nothing to chance. While the file is possibly bigger, it is more likely to display correctly on all manner of printers and screens. I eventually converted my Omnigraffle diagrams to PDF/X-3, and now their colors and shadows appear correct on Linux, while they were psychedelic before. PDF/X-3 might be a worthwhile standard to follow for mpl figure output (even only as an option). At least embedding ICC profiles is probably a good idea. Regards, Ludwig - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rgb versus cmyk
Ludwig Schwardt wrote: >> Publishers sometimes require electronic figures as tif or eps, and using >> the cymk color system. We do everything in rgb. I don't understand >> color systems well. What would be needed to give mpl the ability to >> produce files using the cymk system? > > PDF/X-3 might be a worthwhile standard to follow for mpl figure output > (even only as an option). At least embedding ICC profiles is probably > a good idea. That seems like a great suggestion (without knowing the details of what is really involved). I wonder if that would appease some of the publisher's requirements that Eric mentioned. I vaguely recall seeing CMYK requirements myself in the past, but I can't dig up any of them. I just wonder what *specifically* publishers may require, and whether providing an ICC profile in the PDF or converting rgb colors to cmyk on output (within matplotlib) is the better way to go. Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rgb versus cmyk
I have had some problems printing posters on a plot where indeed the colors came out a bit wrong. I was told by the staff that it was because the conversion RGB->CMYK was handled differently by different printers and screens. I don't know if providing and ICC profile would solve the problem, but it can't harm. Is this also possible for EPS, or are we stuck with the problem without a good solution? By the way, what is the status of TeX support in PDF. On the version I have on my box it is not running, but I don't run svn. Cheers, Gaël - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rgb versus cmyk
Hi, On Nov 21, 2007 3:39 PM, Gael Varoquaux <[EMAIL PROTECTED]> wrote: > I have had some problems printing posters on a plot where indeed the > colors came out a bit wrong. I was told by the staff that it was because > the conversion RGB->CMYK was handled differently by different printers > and screens. I don't know if providing and ICC profile would solve the > problem, but it can't harm. The ICC profile maps the device-dependent RGB (or CMYK) values stored in the plot to a device-independent color space (either CIE Lab or the equivalent XYZ). This independent color space describes *absolute* color - a point in Lab space is therefore intended to look the same on any screen or printer. When this profile is combined with a second ICC profile for the target screen or printer on which the plot is to be viewed/printed, it allows the color management software to convert the RGB values in the PDF to the appropriate RGB or CMYK values that will produce the intended absolute color on the target device. It is therefore important to realise that both RGB and CMYK are *relative* color spaces, relative to some device. The R, G and B values are merely weights mixing together the device's interpretation of true R, G and B (the same goes for CMYK). Some problems: - Devices produce different subsets of the set of all visible colors (the issue of color gamut). For example, CMYK printers struggle with highly saturated green. If you make an RGB plot on your LCD screen, a pure green line with color 'g' or 0x00FF00 may not ever come out the same way on your printer. - Matplotlib plots typically use an abstract concept of color. Lines are usually colored to distinguish them from each other, and frequently the absolute color is not that important. More importantly, there is typically no device associated with the input color (as is the case with images derived from scanners or digital cameras), and therefore no way to map the RGB relative values to absolute color. Possible solutions: - Use colors that are safe for printing and displaying (less saturated colors?). - Use Lab color, which is absolute. This is cumbersome, and RGB is much more commonplace and well-understood in plotting packages, including Matlab. - Associate a generic ICC profile with the mpl plot, to attach absolute color values to the RGB values in the plot in a consistent way. Maybe this is the default in many graphics file formats and therefore redundant, or maybe it does make a difference specifying it explicitly, I'm not sure. > Is this also possible for EPS, or are we stuck with the problem without a > good solution? As far as I can tell, you can embed ICC profiles in most graphic file formats, including PDF, EPS, JPG, PNG, SVG, TIFF, etc. Regards, Ludwig - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] updating an image with a colorbar, performance issues
I should have some time today to look at this, unless any other developers already know an obvious solution. Cheers, Mike Darren Dale wrote: > I have been working on an application which is basically a dressed up version > of embedding_in_qt4.py. I have two canvases, one is just a plot, the other an > image with a colorbar, both of which should get updated about once a second > as data is acquired. I noticed that for larger images, it was taking longer > to update the canvases as time went on. > > Attached is a script that demonstrates the problem (png's are also attached > for those who dont have PyQt4). At each timeout, I check the time, generate a > new random array, update the image's data, draw it, collect garbage, and > check the time again. The plot in the upper window shows how long it took to > update the image canvas as a function of iteration number. > > When the image has a colorbar, the time to update the image canvas increases > linearly, about 0.3 ms/iteration. This can really add up: after 20,000 > iterations it takes about 5-6 seconds to update the image canvas. If I > comment out the line that creates the colorbar (line 64), the time to update > the image canvas does not increase. > > A couple other observations and benchmarks from this test: > > * The intercept for the update time with a color bar was 0.17 seconds > * With the colorbar enabled but garbage collection turned off, the > application > slowly consumed memory, roughly 12KB/iteration > * Updating an image without a colorbar took 0.1 seconds per iteration, and > did > not increase > * Turning off both garbage collection and the colorbar decreased the update > time to 0.043 seconds, with maybe 1.7 KB/iteration increase in memory usage. > > I don't know if I'll get a chance to dig any further into this in the next > two > weeks. For now, I'll just disable the colorbar in my application. > > Darren > > > > > > > > > > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > > > > > ___ > Matplotlib-devel mailing list > [email protected] > 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 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] TypeError: sort() takes no keyword arguments
Hi all,
I have installed matplotlib via svn on Centos (x86-64
python2.3). If I try to import pylab I get
Python 2.3.4 (#1, May 2 2007, 19:18:17)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-8)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> from pylab import plot, show
Traceback (most recent call last):
File "", line 1, in ?
File
"/data/home/nwagner/local/lib64/python2.3/site-packages/matplotlib-0.90.1-py2.3-linux-x86_64.egg/pylab.py",
line 1, in ?
from matplotlib.pylab import *
File
"/data/home/nwagner/local/lib64/python2.3/site-packages/matplotlib-0.90.1-py2.3-linux-x86_64.egg/matplotlib/__init__.py",
line 94, in ?
from rcsetup import defaultParams, validate_backend,
validate_toolbar
File
"/data/home/nwagner/local/lib64/python2.3/site-packages/matplotlib-0.90.1-py2.3-linux-x86_64.egg/matplotlib/rcsetup.py",
line 12, in ?
from matplotlib.fontconfig_pattern import
parse_fontconfig_pattern
File
"/data/home/nwagner/local/lib64/python2.3/site-packages/matplotlib-0.90.1-py2.3-linux-x86_64.egg/matplotlib/fontconfig_pattern.py",
line 21, in ?
from matplotlib.pyparsing import Literal, OneOrMore,
ZeroOrMore, Optional, Regex, \
File
"/data/home/nwagner/local/lib64/python2.3/site-packages/matplotlib-0.90.1-py2.3-linux-x86_64.egg/matplotlib/pyparsing.py",
line 3151, in ?
commonHTMLEntity = Combine("&" + oneOf("gt lt amp
nbsp quot").setResultsName("entity") +";")
File
"/data/home/nwagner/local/lib64/python2.3/site-packages/matplotlib-0.90.1-py2.3-linux-x86_64.egg/matplotlib/pyparsing.py",
line 2849, in oneOf
symbols.sort(reverse=True)
TypeError: sort() takes no keyword arguments
Any pointer would be appreciated.
Nils
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] TypeError: sort() takes no keyword arguments
Sorry -- I accidentally used a feature only available in Python 2.4 and
above.
I have added a fix in SVN r4402. Since I don't have a Python2.3 to test
with, can you please let me know if that fixes your problem?
Cheers,
Mike
Nils Wagner wrote:
> Hi all,
>
> I have installed matplotlib via svn on Centos (x86-64
> python2.3). If I try to import pylab I get
>
> Python 2.3.4 (#1, May 2 2007, 19:18:17)
> [GCC 3.4.6 20060404 (Red Hat 3.4.6-8)] on linux2
> Type "help", "copyright", "credits" or "license" for more
> information.
from pylab import plot, show
> Traceback (most recent call last):
>File "", line 1, in ?
>File
> "/data/home/nwagner/local/lib64/python2.3/site-packages/matplotlib-0.90.1-py2.3-linux-x86_64.egg/pylab.py",
>
> line 1, in ?
> from matplotlib.pylab import *
>File
> "/data/home/nwagner/local/lib64/python2.3/site-packages/matplotlib-0.90.1-py2.3-linux-x86_64.egg/matplotlib/__init__.py",
>
> line 94, in ?
> from rcsetup import defaultParams, validate_backend,
> validate_toolbar
>File
> "/data/home/nwagner/local/lib64/python2.3/site-packages/matplotlib-0.90.1-py2.3-linux-x86_64.egg/matplotlib/rcsetup.py",
>
> line 12, in ?
> from matplotlib.fontconfig_pattern import
> parse_fontconfig_pattern
>File
> "/data/home/nwagner/local/lib64/python2.3/site-packages/matplotlib-0.90.1-py2.3-linux-x86_64.egg/matplotlib/fontconfig_pattern.py",
>
> line 21, in ?
> from matplotlib.pyparsing import Literal, OneOrMore,
> ZeroOrMore, Optional, Regex, \
>File
> "/data/home/nwagner/local/lib64/python2.3/site-packages/matplotlib-0.90.1-py2.3-linux-x86_64.egg/matplotlib/pyparsing.py",
>
> line 3151, in ?
> commonHTMLEntity = Combine("&" + oneOf("gt lt amp
> nbsp quot").setResultsName("entity") +";")
>File
> "/data/home/nwagner/local/lib64/python2.3/site-packages/matplotlib-0.90.1-py2.3-linux-x86_64.egg/matplotlib/pyparsing.py",
>
> line 2849, in oneOf
> symbols.sort(reverse=True)
> TypeError: sort() takes no keyword arguments
>
> Any pointer would be appreciated.
>
> Nils
>
>
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
> ___
> Matplotlib-devel mailing list
> [email protected]
> 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
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] updating an image with a colorbar, performance issues
It seems that the set of callbacks held by the Axis objects was not being cleared by cla(). This has been fixed in SVN r4404, and does seem to correct your example script. I'd appreciate a sanity check by the other developers to make sure that change makes sense -- i.e. that the Axis callbacks don't really need to stick around beyond the call to cla() for any reason I'm not aware of. An alternative and more general solution would be to change the implementation of CallbackRegistry so it uses a WeakValueDictionary, so that it won't keep callback targets alive that have otherwise been orphaned. But I can't decide whether that is a good thing or would just hide easily fixed errors. Cheers, Mike Michael Droettboom wrote: > I should have some time today to look at this, unless any other > developers already know an obvious solution. > > Cheers, > Mike > > Darren Dale wrote: >> I have been working on an application which is basically a dressed up >> version >> of embedding_in_qt4.py. I have two canvases, one is just a plot, the other >> an >> image with a colorbar, both of which should get updated about once a second >> as data is acquired. I noticed that for larger images, it was taking longer >> to update the canvases as time went on. >> >> Attached is a script that demonstrates the problem (png's are also attached >> for those who dont have PyQt4). At each timeout, I check the time, generate >> a >> new random array, update the image's data, draw it, collect garbage, and >> check the time again. The plot in the upper window shows how long it took to >> update the image canvas as a function of iteration number. >> >> When the image has a colorbar, the time to update the image canvas increases >> linearly, about 0.3 ms/iteration. This can really add up: after 20,000 >> iterations it takes about 5-6 seconds to update the image canvas. If I >> comment out the line that creates the colorbar (line 64), the time to update >> the image canvas does not increase. >> >> A couple other observations and benchmarks from this test: >> >> * The intercept for the update time with a color bar was 0.17 seconds >> * With the colorbar enabled but garbage collection turned off, the >> application >> slowly consumed memory, roughly 12KB/iteration >> * Updating an image without a colorbar took 0.1 seconds per iteration, and >> did >> not increase >> * Turning off both garbage collection and the colorbar decreased the update >> time to 0.043 seconds, with maybe 1.7 KB/iteration increase in memory usage. >> >> I don't know if I'll get a chance to dig any further into this in the next >> two >> weeks. For now, I'll just disable the colorbar in my application. >> >> Darren >> >> >> >> >> >> >> >> >> >> >> - >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2005. >> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ >> >> >> >> >> ___ >> Matplotlib-devel mailing list >> [email protected] >> 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 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] updating an image with a colorbar, performance issues
Thank you for tracking this down, Mike. Darren On Wednesday 21 November 2007 11:17:04 am Michael Droettboom wrote: > It seems that the set of callbacks held by the Axis objects was not > being cleared by cla(). > > This has been fixed in SVN r4404, and does seem to correct your example > script. I'd appreciate a sanity check by the other developers to make > sure that change makes sense -- i.e. that the Axis callbacks don't > really need to stick around beyond the call to cla() for any reason I'm > not aware of. > > An alternative and more general solution would be to change the > implementation of CallbackRegistry so it uses a WeakValueDictionary, so > that it won't keep callback targets alive that have otherwise been > orphaned. But I can't decide whether that is a good thing or would just > hide easily fixed errors. > > Cheers, > Mike > > Michael Droettboom wrote: > > I should have some time today to look at this, unless any other > > developers already know an obvious solution. > > > > Cheers, > > Mike > > > > Darren Dale wrote: > >> I have been working on an application which is basically a dressed up > >> version of embedding_in_qt4.py. I have two canvases, one is just a plot, > >> the other an image with a colorbar, both of which should get updated > >> about once a second as data is acquired. I noticed that for larger > >> images, it was taking longer to update the canvases as time went on. > >> > >> Attached is a script that demonstrates the problem (png's are also > >> attached for those who dont have PyQt4). At each timeout, I check the > >> time, generate a new random array, update the image's data, draw it, > >> collect garbage, and check the time again. The plot in the upper window > >> shows how long it took to update the image canvas as a function of > >> iteration number. > >> > >> When the image has a colorbar, the time to update the image canvas > >> increases linearly, about 0.3 ms/iteration. This can really add up: > >> after 20,000 iterations it takes about 5-6 seconds to update the image > >> canvas. If I comment out the line that creates the colorbar (line 64), > >> the time to update the image canvas does not increase. > >> > >> A couple other observations and benchmarks from this test: > >> > >> * The intercept for the update time with a color bar was 0.17 seconds > >> * With the colorbar enabled but garbage collection turned off, the > >> application slowly consumed memory, roughly 12KB/iteration > >> * Updating an image without a colorbar took 0.1 seconds per iteration, > >> and did not increase > >> * Turning off both garbage collection and the colorbar decreased the > >> update time to 0.043 seconds, with maybe 1.7 KB/iteration increase in > >> memory usage. > >> > >> I don't know if I'll get a chance to dig any further into this in the > >> next two weeks. For now, I'll just disable the colorbar in my > >> application. > >> > >> Darren > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >>- This SF.net email is sponsored by: Microsoft > >> Defy all challenges. Microsoft(R) Visual Studio 2005. > >> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > >> > >> > >> > >> > >> ___ > >> Matplotlib-devel mailing list > >> [email protected] > >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Darren S. Dale, Ph.D. [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Fwd: Nabble - War on trailing whitespace]
John Hunter wrote: > ( I configured my emacs to detect > whitespace) and suspect I may have been a trailing whitespace > contributer, Can you give me a pointer about what exactly you did? Just now, I just discovered a whitespace-cleanup and a whitespace-visual-mode. It'd be nice if there was something that automatically showed just tabs and end-of-line whitespace. As it is, I found whitespace-visual-set-whitespace-chars doesn't seem to have quite that level of granularity. Have you configured anything beyond this? Thanks, Andrew - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Fwd: Nabble - War on trailing whitespace]
On Nov 21, 2007 1:37 PM, Andrew Straw <[EMAIL PROTECTED]> wrote: > Can you give me a pointer about what exactly you did? Just now, I just > discovered a whitespace-cleanup and a whitespace-visual-mode. It'd be > nice if there was something that automatically showed just tabs and > end-of-line whitespace. As it is, I found > whitespace-visual-set-whitespace-chars doesn't seem to have quite that > level of granularity. Have you configured anything beyond this? I ended up adding both of these to .emacs and restarting. Probably one or the other would work. For some reason I had to restart, and not just eval them in .emacs (??) (add-hook 'python-mode-hook (lambda () (setq show-trailing-whitespace t) )) (mapc (lambda (hook) (add-hook hook (lambda () (setq show-trailing-whitespace t '(python-mode-hook)) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Fwd: Nabble - War on trailing whitespace]
Thanks, that works, but unforunately only on emacs21 but not xemacs 21. Looks like I'll now have to find a way to do the one thing in emacs that keeps me using xemacs: goto-line bound to M-g. (Any quick tips appreciated.) -Andrew John Hunter wrote: > On Nov 21, 2007 1:37 PM, Andrew Straw <[EMAIL PROTECTED]> wrote: > >> Can you give me a pointer about what exactly you did? Just now, I just >> discovered a whitespace-cleanup and a whitespace-visual-mode. It'd be >> nice if there was something that automatically showed just tabs and >> end-of-line whitespace. As it is, I found >> whitespace-visual-set-whitespace-chars doesn't seem to have quite that >> level of granularity. Have you configured anything beyond this? > > I ended up adding both of these to .emacs and restarting. Probably > one or the other would work. For some reason I had to restart, and > not just eval them in .emacs (??) > > (add-hook 'python-mode-hook > (lambda () > (setq show-trailing-whitespace t) > )) > > (mapc (lambda (hook) > (add-hook hook (lambda () >(setq show-trailing-whitespace t > '(python-mode-hook)) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Fwd: Nabble - War on trailing whitespace]
[oops, meant on-list ] On Nov 21, 2007 12:52 PM, Andrew Straw <[EMAIL PROTECTED]> wrote: > Thanks, that works, but unforunately only on emacs21 but not xemacs 21. > Looks like I'll now have to find a way to do the one thing in emacs that > keeps me using xemacs: goto-line bound to M-g. (Any quick tips appreciated.) I recently switched to the 'pretty emacs' from http://peadrop.com/blog/2007/09/17/pretty-emacs-reloaded/ so I could get decent fonts in emacs. I had to tweak my config a bit, and for M-g I put this by hand in my config file: (global-set-key "\M-g" 'goto-line) ; standard XEmacs I can send you my configs which allow me to start this emacs (with "emacs-snapshot-gtk --enable-font-backend") or plain xemacs in a reasonably functional state for both. Cheers, f - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Fwd: Nabble - War on trailing whitespace]
Eric Firing wrote: > Yes, I understand, and I am sorry--but I hope it is one-time pain to > avoid continuing pin-pricks. If svn ignored trailing whitespace, then > there would be no problem; I could continue to use an editor that > removes it, and you could continue to use editors that gratuitously add > it, and usually it would make no difference. This is not the case, > however. As it is now, if a file comes into svn without any trailing > whitespace, and one of you loads it up, maybe makes a trivial change > after running your cursor through it, and saves it--it will end up with > a big changeset--lots of trailing whitespace. This is just plain bad. > All downside, no upside. > FWIW, you can get svn diff to ignore (trailing whitespace) -- by not using svn diff. svn diff --diff-cmd diff -x -uw path/to/file.py With apologies for previously hijacking your thread into an emacs configure-a-thon, :) Andrew - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rgb versus cmyk
Ludwig Schwardt wrote: > Possible solutions: > > - Use colors that are safe for printing and displaying (less saturated > colors?). Avoid the extreme (255,0,0), (0,255,0), (0,0,255) colors, yes. For reasons which are fairly obvious given the physics, RGB devices do better displaying those than CMYK devices. Blues are especially poorly represented in CMYK media. OS X users can play around with these things using the ColorSync Utility.app program. Click on the "Profiles" button. On the left, there is a tree of profiles. Select "Generic RGB Profile". On the 3D plot, click the triangle in the upper left-hand corner and select "Hold for comparison". Now click the "Generic CMYK Profile". This shows a CMYK color gamut and an RGB color gamut in Lab space. The intersection of these two is the "safe region" where the colors on your screen can be represented in print. Of course, that is only if the printer driver knows about both profiles. > - Use Lab color, which is absolute. This is cumbersome, and RGB is > much more commonplace and well-understood in plotting packages, > including Matlab. Yeah, that's probably not too practical. > - Associate a generic ICC profile with the mpl plot, to attach > absolute color values to the RGB values in the plot in a consistent > way. Maybe this is the default in many graphics file formats and > therefore redundant, or maybe it does make a difference specifying it > explicitly, I'm not sure. It might be reasonable to specify that matplotlib uses the W3C standard sRGB colorspace. It was meant to be good for representability on a wide variety of computer monitors. Some monitors may even be manufactured to match that standard. It is the default colorspace for SVG and PNG. It misses a fair chunk of most the usual CMYK space in the greens and cyans, though. Adobe RGB (1998) would be better for print, but that "wastes" a lot of space on greens that most monitors can't represent. Some journals require figures in Adobe RGB (1998). Really implementing this still requires one to apply calibrated ICC profiles of your viewing device and potential output devices, but it does standardize the files matplotlib outputs. I have some code that wraps the lcms library for applying ICC profiles to numpy arrays. Those who saw my lightning talk at SciPy '07 saw an app I had for showing colormaps in perceptual colorspaces like Lab and with transformations to simulate colorblindness. I'm snowed under work next week, but after that I'll try to clean it up for doing soft-proofs of images. Maybe I'll even get to integrating that soft-proofing with matplotlib such that every interactive plot can be displayed as if it were printed (or seen through my colorblind eyes). -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
