matplotlib-devel Mailing List for matplotlib (Page 462)

I think a numpy-ism crept into the code-base (not that I particularly 
mind as I will welcome the day matplotlib jettisons it's 3-array support).

In quiver.py, nx.nan is attempted, which raises an error, unless I'm 
missing the definition of nan somewhere.

In SVN, I have imported nan from numpy explicitly

Best,

-Travis

Christopher Barker wrote:
> Darren Dale wrote:
>   
>> Travis says that barring the discovery of some issue during the beta period, 
>> the C API will not change before numpy-1.1. I think an exe may be necessary 
>> as well.
>>     
>
> and an OS-X mpkg, if you're set up to do that -- also, we'd need to 
> build an mpkg of the numpy you used as well.
>
> I don't know if it's time to do that quite yet though.
>
>   
Wait a bit until I get the Numeric backward-compatibility module 
straightened out.  Some name imports in matplotlib may have to change 
again to get it right.

This should be done by the end of the weekend.

-Travis

On 8/4/06, David Flory <li...@th...> wrote:
> At 8/2/2006 3:57 PM Charlie Moad wrote:
> > I have this on hand right now.
> >
> > http://euclid.uits.iupui.edu/~cmoad/matplotlib-0.87.4_r2645-py2.4-win32.egg
> >
> > I could make an exe build if you woudl prefer that.  How long is numpy
> > supposed to be in beta?
> >
> > - Charlie
> >
> > On 8/2/06, Darren Dale <dd...@co...> wrote:
> >> Any chance we can get a binary release together to work with the latest
> >> version of numpy? There are some posts on scipy-user complaining that 0.87.4
> >> wont work with numpy C API version 1000000 (numpy-1.0b1).
> >>
> >> Darren
> >>
>
> Charlie,
>
> I downloaded your egg and tried to Easy_Install it.  I got errors.
> (Warning: total novice at eggs) Below are the errors.  Any suggestions?

I had bed perms on the file.  It's fixed now.  I'm curious how you
downloaded it in the first place?  Ah well.

At 8/2/2006 3:57 PM Charlie Moad wrote:
> I have this on hand right now.
> 
> http://euclid.uits.iupui.edu/~cmoad/matplotlib-0.87.4_r2645-py2.4-win32.egg
> 
> I could make an exe build if you woudl prefer that.  How long is numpy
> supposed to be in beta?
> 
> - Charlie
> 
> On 8/2/06, Darren Dale <dd...@co...> wrote:
>> Any chance we can get a binary release together to work with the latest
>> version of numpy? There are some posts on scipy-user complaining that 0.87.4
>> wont work with numpy C API version 1000000 (numpy-1.0b1).
>>
>> Darren
>>

Charlie,

I downloaded your egg and tried to Easy_Install it.  I got errors.
(Warning: total novice at eggs) Below are the errors.  Any suggestions?

Cheers, David

D:\Software Archive\Python\MatPlotLib>easy_install
matplotlib-0.87.4_r2645-py2.4
-win32.egg
Processing matplotlib-0.87.4_r2645-py2.4-win32.egg
Traceback (most recent call last):
  File "C:\Python24\Scripts\easy_install-script.py", line 7, in ?
    sys.exit(
  File
"c:\python24\lib\site-packages\setuptools-0.6c1-py2.4.egg\setuptools\comm
and\easy_install.py", line 1588, in main
    with_ei_usage(lambda:
  File
"c:\python24\lib\site-packages\setuptools-0.6c1-py2.4.egg\setuptools\comm
and\easy_install.py", line 1577, in with_ei_usage
    return f()
  File
"c:\python24\lib\site-packages\setuptools-0.6c1-py2.4.egg\setuptools\comm
and\easy_install.py", line 1591, in <lambda>
    distclass=DistributionWithoutHelpCommands, **kw
  File "C:\Python24\Lib\distutils\core.py", line 149, in setup
    dist.run_commands()
  File "C:\Python24\Lib\distutils\dist.py", line 946, in run_commands
    self.run_command(cmd)
  File "C:\Python24\Lib\distutils\dist.py", line 966, in run_command
    cmd_obj.run()
  File
"c:\python24\lib\site-packages\setuptools-0.6c1-py2.4.egg\setuptools\comm
and\easy_install.py", line 211, in run
    self.easy_install(spec, not self.no_deps)
  File
"c:\python24\lib\site-packages\setuptools-0.6c1-py2.4.egg\setuptools\comm
and\easy_install.py", line 427, in easy_install
    return self.install_item(None, spec, tmpdir, deps, True)
  File
"c:\python24\lib\site-packages\setuptools-0.6c1-py2.4.egg\setuptools\comm
and\easy_install.py", line 471, in install_item
    dists = self.install_eggs(spec, download, tmpdir)
  File
"c:\python24\lib\site-packages\setuptools-0.6c1-py2.4.egg\setuptools\comm
and\easy_install.py", line 619, in install_eggs
    return [self.install_egg(dist_filename, tmpdir)]
  File
"c:\python24\lib\site-packages\setuptools-0.6c1-py2.4.egg\setuptools\comm
and\easy_install.py", line 670, in install_egg
    dist = self.egg_distribution(egg_path)
  File
"c:\python24\lib\site-packages\setuptools-0.6c1-py2.4.egg\setuptools\comm
and\easy_install.py", line 661, in egg_distribution
    metadata = EggMetadata(zipimport.zipimporter(egg_path))
zipimport.ZipImportError: not a Zip file:
'matplotlib-0.87.4_r2645-py2.4-win32.e
gg'

D:\Software Archive\Python\MatPlotLib>

On 8/2/06, John Hunter <jdh...@ac...> wrote:
> OK, but I reiterate my point from my last post on the subject.  The
> work you have done previously as far as I understand is still not
> usable.  You need to develop a system wherein mathtext can be used
> with a set of unicode fonts, so that when the STYX fonts are released
> we can use them.  Even if the example font set does not have full
> coverage, we need to develop a prototype so that users and developers
> can test your work.  Something like
>
>   - here are a set of test fonts: http://some.web.site
>
>   - here are the changes you need to make to your rc file
>
>   - here is a test script
>

Thanks!
I apologise for keeping the development in obscurity. The procedure
(the best I could come up with):

1) Here are a set of test fonts:
http://download.savannah.gnu.org/releases/freefont/freefont-ttf-20060126.tar.gz

Make sure you extract the files FreeSerif.ttf, FreeMono.ttf to the mpl-data dir.

2) Changes needed to the files: You have to change __init__.py and
mathtext.py (the files are attached) and you also have to add some
lines to matplotlibrc (also attached).
The __init__.py/matplotlibrc changes are trivial:
    # mathtext settings
    'mathtext.unicode'  :   [False, validate_bool], # Needed to enable Unicode
    # fonts used by mathtext
    'mathtext.rm'       :   ['FreeSerif.ttf', str], # Roman (normal)
    'mathtext.it'       :   ['FreeSerif.ttf', str], # Italic
    'mathtext.tt'       :   ['FreeMono.ttf', str],  # Typewriter (monospaced)
    'mathtext.cal'      :   ['cmsy10.ttf', str], # Caligraphic

Although the default setting for 'mathtext.unicode' is False, the
attached matplotlibrc sets it to True.

The mathtext.py changes are also trivial.

3) mathtext_demo.py will do as a test script. I have added some TeX
symbols to the mathtext_demo.py that is attached with this e-mail.
Note that the attached mathtext_demo.py saves a png, svg and ps file
in the working dir.

Again, I didn't want to commit to the svn, because, as a newbie, I'm
not completely sure if the proposed changes will break something, or
if I should have done things differently.

Any feedback is welcome, only note that the current parsing doesn't
allow some things that in plain TeX you take for granted (I'm
developing a new parser already). The changes only show the current
state of Unicode support in the Font classes.

Cheers
Edin

Darren Dale wrote:
> Travis says that barring the discovery of some issue during the beta period, 
> the C API will not change before numpy-1.1. I think an exe may be necessary 
> as well.

and an OS-X mpkg, if you're set up to do that -- also, we'd need to 
build an mpkg of the numpy you used as well.

I don't know if it's time to do that quite yet though.

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Travis says that barring the discovery of some issue during the beta period, 
the C API will not change before numpy-1.1. I think an exe may be necessary 
as well.

On Wednesday 02 August 2006 15:57, Charlie Moad wrote:
> I have this on hand right now.
>
> http://euclid.uits.iupui.edu/~cmoad/matplotlib-0.87.4_r2645-py2.4-win32.egg
>
> I could make an exe build if you woudl prefer that.  How long is numpy
> supposed to be in beta?
>
> - Charlie
>
> On 8/2/06, Darren Dale <dd...@co...> wrote:
> > Any chance we can get a binary release together to work with the latest
> > version of numpy? There are some posts on scipy-user complaining that
> > 0.87.4 wont work with numpy C API version 1000000 (numpy-1.0b1).
> >
> > Darren
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share
> > your opinions on IT & business topics through brief surveys -- and earn
> > cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

-- 
Darren S. Dale, Ph.D.
Cornell High Energy Synchrotron Source
Cornell University
200L Wilson Lab
Rt. 366 & Pine Tree Road
Ithaca, NY 14853

dd...@co...
office: (607) 255-9894
fax: (607) 255-9001

I have this on hand right now.

http://euclid.uits.iupui.edu/~cmoad/matplotlib-0.87.4_r2645-py2.4-win32.egg

I could make an exe build if you woudl prefer that.  How long is numpy
supposed to be in beta?

- Charlie

On 8/2/06, Darren Dale <dd...@co...> wrote:
> Any chance we can get a binary release together to work with the latest
> version of numpy? There are some posts on scipy-user complaining that 0.87.4
> wont work with numpy C API version 1000000 (numpy-1.0b1).
>
> Darren
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Any chance we can get a binary release together to work with the latest 
version of numpy? There are some posts on scipy-user complaining that 0.87.4 
wont work with numpy C API version 1000000 (numpy-1.0b1).

Darren

Darren Dale wrote:
> I'm actually very hopeful. It's because the TeX code is so well written and 
> documented that the algorithms can (hopefully) be easily ported to Python. 

Good point. I've never looked deep enough to know how complicated the 
algorithms really are -- and we're not trying to build something that 
will run LaTeX here. Although, It would be very useful to be able to use 
add-on packages -- amsmath, if nothing else.

> The problem I have with TeX is 
> that it has a lot of overhead (it's not meant to be used as a daemon), is not 
> intended to be used as a library (as far as I have been able to discern),

These are key -- and what I've been fantasizing for years is that 
someone will re-write to be used as a library.

> and 
> still requires interpretation once the results are produced

DVI is actually pretty simple -- I don't think that's the hard part of 
the problem.

>  The usetex option, which produces excellent
> results, has been an absolute headache to maintain across platforms.

I'm sure! dependency on an external TeX distribution is not a good 
long-term option.

 > Which other projects did you have in mind?

I've seen a couple that are trying to make a version of TeX that can be 
used as a lib -- with just this kind of thing in mind. How active they 
are, and whether they will get anywhere remains to be seen.

Here's one that doesn't look active:
http://www.metatex.org/

and another: but JAVA? argg!
http://www.extex.org/index.html

That might still be a good site to check out if one is to re-write the 
TeX layout engine in Python...

Even if there aren't any other projects to leverage, while less fun, I 
expect that making a library version of TeX from the existing code base 
would result in a far more robust result.

Another option is to build a stripped down TeX distribution that we 
would deliver with MPL. Also a lot of work, but it could be restricted 
to only a small number of fonts, packages, etc.

Anyway, anything that someone will do (and get paid for!) is fine with me!

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

On Wednesday 02 August 2006 11:59, Christopher Barker wrote:
> John Hunter wrote:
> > the STYX fonts are released
>
> did you mean the STIX fonts?
>
> http://www.stixfonts.org/
>
> >   - here are a set of test fonts: http://some.web.site
>
> Is that really the link?

"Please repeat after me: I, say your name..."

"I, say your name..."

John Hunter wrote:
> the STYX fonts are released

did you mean the STIX fonts?

http://www.stixfonts.org/

>   - here are a set of test fonts: http://some.web.site

Is that really the link?

-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

>>>>> "Edin" =3D=3D Edin Salkovi=A7 <edi...@gm...> writes:

    Edin> I'm still alive ;) Although I still haven't received any
    Edin> payments from Google (they are doing their best to solve
    Edin> this), I've began working on implementing the Knuth's layout
    Edin> algorithms.

OK, but I reiterate my point from my last post on the subject.  The
work you have done previously as far as I understand is still not
usable.  You need to develop a system wherein mathtext can be used
with a set of unicode fonts, so that when the STYX fonts are released
we can use them.  Even if the example font set does not have full
coverage, we need to develop a prototype so that users and developers
can test your work.  Something like

  - here are a set of test fonts: http://some.web.site

  - here are the changes you need to make to your rc file

  - here is a test script

I think it is unproductive to move on to new projects before the first
one is completed and usable.  Or if am missing something and the work
is usable, please provide a brief set of instructions as above so we
can test it.

JDH

I'm still alive ;)

Although I still haven't received any payments from Google (they are
doing their best to solve this), I've began working on implementing
the Knuth's layout algorithms.

I have studied a bit the TeXbook, the existing mathtext parsing code,
and I have decided to rewrite the parsing almost from scratch.
Although I don't no too much about parsing, I think it won't be that
much of a problem.

My idea is to first transform a TeX string to a Python list (tree-like
structure), which can be composed of strings, commands, and/or other
lists, and so on.

Then, I plan to write some classes to trasnform this list/tree to the
actual boxes needed for displaying.

The first part is done (although bugs are possible). Now I'm
concetrating on the remaining part.

The current module is attached. It doesn't need any third-party
libraries currently.
The following works:
Going from:
r"asdf { \horse{}\ \zztop{} \ Hello\^^a^{b_c}}"

to:
['asdf', ' ', [' ', '\\horse', [], '\\space', '\\zztop', [], ' ',
'\\space', 'Hello', '\\circumflex', '\\superscript', 'a',
'\\superscript', ['b', '\\subscript', 'c']]]


Please John, do comment (others with spare time are welcome too :).

> There are two kinds of images in matplotlib -- AxesImage and
> FigureImage.  By definition, the AxesImage is interpolated to fit into
> the Axes box.  You can control the aspect ratio of the interpolation,
> but it will be interpolated.  FigureImage, on the other hand, performs
> a pixel dump to the postscript canvas at the location you tell it to
> -- see examples/figimage_demo.py.  It should like you are more
> interested in the latter.
I've had a play with FigureImage and I can't see how to make it draw
the image inside the axes, it seems to only draw it in the background.

> If the figure image doesn't work for you, describe your use-case in
> some detail and why neither work and we'll see if we can accommodate
> it.
OK, so imshow does exactly what I want. The only problem is the
resampling. Each pixel represents a value calculated at a point on a
318x301 grid, so in resampling I loose or distort some of the fine
detail. I do not understand why the image need to be resampled when
using a vector based backend. I understand this is necessary for a
raster backend, but surely with a vector backend you can just scale
the image keeping the 318x301 resolution. I know this is possible in
Postscript at least as I've produced the desired output by
amalgamating two files. See

http://jimmacdonald.co.uk/matplotlib/image_CORRECT_ps_hacked.eps

I looked at using pcolor instead, but the postscript files where too
big (~20MB) due to the large number of tiles (this is how I used to do
it in matlab).

JIM
----

Andrew Straw wrote:
> I was thinking I want an exact a replica of the wx API as possible,

well, I'm a big fan of wx.Sizers, but we all know that they confuses folks.

Given that grid-like layouts are likely to be the most common with MPL, 
maybe just make a GridBagSizer, and forget the rest? All the other 
sizers are just a simplification of that anyway.

just my $0.2

Despite that small suggestion -- very nice work!

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Hi Ken,

Thanks for your comments.

Ken McIvor wrote:

>1. It appears that as_sizer_element() uses the _axes_sizer_elements  
>dictionary to cache MplAxesSizerElement instances.  Using a  
>WeakKeyDictionary from the "weakref" module instead of a regular  
>dictionary may be necessary to allow the garbage collection of the  
>MplAxesSizerElements when their associated Axes gets GC'd.
>  
>
I'll check into this.

>2. Convenience MplBoxSizer subclasses that let you omit the "orient"  
>keyword might be nice:
>
>     class MplHBoxSizer(MplBoxSizer):
>         def __init__(self):
>             MplBoxSizer.__init__(self, orientation='vertical')
>  
>
I was thinking I want an exact a replica of the wx API as possible,
simply so my feeble mind doesn't get (more) confused. Is there anything
like this in stock wx? I think it's a decent enough idea, but I'd rather
not cause namespace bloat. But, if you're really into it, let's do it.

>3. Couldn't you just drop mplsizer.py into the "matplotlib.toolkits"  
>virtual package?  Maybe you can't -- I'm pretty new to applied python- 
>eggery.
>  
>
I think this is possible, and I hope for not too much effort. This is
the result of historic accident and personal time-allocation issues.
Mplsizer started life as a private setuptools-ized package, and I'm not
spending my time to de-setuptools-ize software -- I see setuptools as
the way forward, not something (I will spend my time) to remove. I
understand that some people aren't too fond of setuptools, and to them,
I say, "patches welcome".

>4. I feel we should avoid the whole European/American spelling  
>problem that WX has.  Why not make both 'align_centre' and  
>'align_center' do the same thing?
>  
>
Same answer as to point 2...

>5. Why not use shorter names, with less redundancy? (e.g.  
>"matplotlib.toolkits.sizer", FigureSizer, Box, HBox, Grid, etc)
>  
>
Same answer as to point 2... (I'd be happy to drop the "Mpl" prefix,
though.)

>>>>> "JIM" == JIM MacDonald <ji...@ji...> writes:

    JIM> My second problem involved the resolutions of the image.  I'd
    JIM> like to preserve the resolution of my image in the PS output,
    JIM> but I can't figure out how to stop the image being resized
    JIM> and interpolated.  Obviously you need to do this for the


There are two kinds of images in matplotlib -- AxesImage and
FigureImage.  By definition, the AxesImage is interpolated to fit into
the Axes box.  You can control the aspect ratio of the interpolation,
but it will be interpolated.  FigureImage, on the other hand, performs
a pixel dump to the postscript canvas at the location you tell it to
-- see examples/figimage_demo.py.  It should like you are more
interested in the latter.

If the figure image doesn't work for you, describe your use-case in
some detail and why neither work and we'll see if we can accommodate
it.

JDH

> I don't think this is a problem with the postscript backend. You're rescaling
> the image in your script. Try something like this:
>
> from pylab import *
>
> rc('text', usetex=True)
> rc('ps', usedistiller="xpdf")
>
> figure(1,figsize=(6, 4))
> im=imread('image.png')
> imshow(im,interpolation='nearest')#,extent=[0.98, 20, 0.01, 0.5])
> #axis('normal');
> savefig('image.eps')

I just tried that and it still rescales the image, this time to
243x230. I've found I can use the figsize kwarg to control the
resolution of the embedded image, but of course this means I can't
have the figure the size I want it.

JIM
---

> Would you post an example where the ps2pdf flags make a big difference on the
> output? I just tried with the above png, but I cant tell the difference
> between the results with/without the new flags.
http://jimmacdonald.co.uk/matplotlib/MPD_SinPulse_g0.500.png

JIM
---

On Mon, Jul 31, 2006 at 10:19:46AM -0400, Darren Dale wrote:
> I see. Thanks for pointing this out and providing the solution. The fla=
gs you=20
> suggested are passed to ps2pdf as of svn 2639.

    Great ! Thanks.

    I like open source software so much because of these little details
:->.

--=20
    Ga=EBl

On Monday 31 July 2006 10:05, Gael Varoquaux wrote:
> On Mon, Jul 31, 2006 at 10:01:23AM -0400, Darren Dale wrote:
> > Would you post an example where the ps2pdf flags make a big difference on
> > the output? I just tried with the above png, but I cant tell the
> > difference between the results with/without the new flags.
>
> Last image of http://scipy.org/GaelVaroquaux, the example script. You
> can also have a look at the "pylab2pdf2 script, where I use
> environmental variables to get a proper behaviour from GS and avoid this
> problem.

I see. Thanks for pointing this out and providing the solution. The flags you 
suggested are passed to ps2pdf as of svn 2639.

Darren

On Mon, Jul 31, 2006 at 10:01:23AM -0400, Darren Dale wrote:
> Would you post an example where the ps2pdf flags make a big difference =
on the=20
> output? I just tried with the above png, but I cant tell the difference=
=20
> between the results with/without the new flags.

Last image of http://scipy.org/GaelVaroquaux, the example script. You
can also have a look at the "pylab2pdf2 script, where I use
environmental variables to get a proper behaviour from GS and avoid this
problem.

--=20
    Ga=EBl

Great.  Thanks John.
There was one other thing I forgot to mention.
I added two lines (+comment) in the backend_wx.py to select the
Pan/Zoom tool by default.
If you don't like that, then obviously just leave those lines out,
But I find that pan/zoom is what I want to do 90% of the time, and
zoom is the other 10%.  "No tool" is what I want pretty much 0% of the
time (is there some use for no-tool mode that I'm missing?)

--bb

On 7/31/06, John Hunter <jdh...@ac...> wrote:
> >>>>> "Bill" == Bill Baxter <wb...@gm...> writes:
>
>    Bill> Ok.  Such a pain though...  Are whole files acceptable
>    Bill> instead of diffs?  It's relatively easy to do a windiff or
>
> Multiple contributions per patch are fine, just do like you did and
> list what is in them.  If there is an objection to part of the patch,
> you may be asked to resubmit w/o the controversial parts, but if all
> the changes look good the whole thing can go in.  And we prefer svn
> diffs over individual files.
>
> Ken, would you like to be added to the devel list to handle some of
> these patches.  Just email me your sf id if so.
>
> JDH
>

On Monday 31 July 2006 09:32, JIM MacDonald wrote:
> > I'll look into this soon. I'm hesitant to add another rc option, maybe we
> > can consider using these settings as the defaults. I'll post again after
> > I have had a chance to play with it.
>
> Defaulting to lossless FlateEncode compression seems like a good idea,
> if the file is too big you can always run another distill cycle after
> wards manually.
>
> Another possibility would be to set the option based on the format of
> the image loaded (I'm  sure I read somewhere that it is planned to
> support formats other than PNG). ie FlateEncode for GIF's and PNG's
> and DCTEncode for JPEG's.

[...]

> Sure,
> http://jimmacdonald.co.uk/matplotlib/image.png
> http://jimmacdonald.co.uk/matplotlib/image.eps
> http://jimmacdonald.co.uk/matplotlib/image.py
>
> image.py generates image.eps from image.png. image.png is simple
> enough for ps2pdf not to use DCT encoding. Looking at the postscript
> shows that the image has resolution of 335x230 compared to the
> original of 318x301.

Would you post an example where the ps2pdf flags make a big difference on the 
output? I just tried with the above png, but I cant tell the difference 
between the results with/without the new flags.

Darren