matplotlib-devel Mailing List for matplotlib (Page 3)

Darren Dale wrote:
[...]
> 
> Could MANIFEST also be removed? I think it is generated from MANIFEST.in.
It is, but it is not clear to me when or how this occurs. Does 
distutils do it? MANIFEST seems to have special significance, but I 
don't know anything about it beyond that.
Eric

Michael Droettboom <md...@st...> writes:
> There was a small typo in the recently added support for non-rectangular 
> clip paths. Fixed in r3829.
>
> (Jouni -- you may want to review this and verify that my change is
> correct.)
Yes, your change fixes a bug; thanks. Strangely enough, Apple's
Preview.app (Version 3.0.9 (409)) displayed the buggy version of e.g.
polar_demo_pdf.pdf just fine.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On Saturday 08 September 2007 09:08:12 pm Eric Firing wrote:
> Michael Droettboom wrote:
> > lib/matplotlib/mpl-data/matplotlibrc is generated at build time by
> > interpolating some fields in matplotlibrc.template.
> >
> > Since it always get changed, it always shows up as a modified file by
> > svn status. This is only a minor annoyance when working on the trunk.
> > However, when working on a branch with svnmerge, svnmerge won't let me
> > merge from trunk if I have any modified files at all, so every time I
> > want to merge, I have to be sure to revert that file.
> >
> > Is there any reason not to just remove this file from SVN?
>
> I could not think of any reason, and I did not see any message to the
> contrary, so I went ahead and removed it.
Could MANIFEST also be removed? I think it is generated from MANIFEST.in.
Darren

Did r3829 not work for you? (Or did you miss that in my earlier post?)
I don't think anything related to Lengths has changed recently, and it 
did work at one point...
Cheers,
Mike
Paul Kienzle wrote:
> On Tue, Sep 11, 2007 at 10:57:18AM -0400, Paul Kienzle wrote:
>> I'm not sure yet how to fix the problem, but in the sample I sent
>> earlier if I change:
>>
>> 5 0 obj
>> << /Length 11 0 R >>
>> endobj
>>
>> to
>>
>> 5 0 obj
>> << /Length 1239 >>
>> endobj
>>
>> then both gv and acroread can process the file without error.
>>
>> 	- Paul
> 
> If I change every instance beginStream in backend_pdf.py to use None 
> rather than a reserved object for the length of the stream then 
> acroread/gv can process the resulting pdf files.
> 
> I'm guessing this will be less efficient for the writer since it has
> to keep the entire stream in memory in order to compute its length
> prior to writing it. The alternative would be to reserve space,
> write the stream, rewind to write the length then seek forward to
> the end, but that won't work if e.g., the pdf is sent to a pipe.
> 
> Let me know if I should post the changes.
> 
> 	- Paul
-- 
Michael Droettboom
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Tue, Sep 11, 2007 at 10:57:18AM -0400, Paul Kienzle wrote:
> I'm not sure yet how to fix the problem, but in the sample I sent
> earlier if I change:
> 
> 5 0 obj
> << /Length 11 0 R >>
> endobj
> 
> to
> 
> 5 0 obj
> << /Length 1239 >>
> endobj
> 
> then both gv and acroread can process the file without error.
> 
> 	- Paul
If I change every instance beginStream in backend_pdf.py to use None 
rather than a reserved object for the length of the stream then 
acroread/gv can process the resulting pdf files.
I'm guessing this will be less efficient for the writer since it has
to keep the entire stream in memory in order to compute its length
prior to writing it. The alternative would be to reserve space,
write the stream, rewind to write the length then seek forward to
the end, but that won't work if e.g., the pdf is sent to a pipe.
Let me know if I should post the changes.
	- Paul

I'm not sure yet how to fix the problem, but in the sample I sent
earlier if I change:
 5 0 obj
 << /Length 11 0 R >>
 endobj
to
 5 0 obj
 << /Length 1239 >>
 endobj
then both gv and acroread can process the file without error.
	- Paul
On Tue, Sep 11, 2007 at 08:49:05AM -0400, Michael Droettboom wrote:
> This seems to be a cross platform bug and unrelated to fonts -- at least 
> I am able to reproduce it on Linux.
> 
> There was a small typo in the recently added support for non-rectangular 
> clip paths. Fixed in r3829.
> 
> (Jouni -- you may want to review this and verify that my change is correct.)
> 
> Cheers,
> Mike
> 
> Paul Kienzle wrote:
> > On Mon, Sep 10, 2007 at 04:19:24PM -0400, Michael Droettboom wrote:
> >> Can you set "pdf.compression : 0" and send me a copy of the troublesome 
> >> PDF (probably best off list if it's a large file.)?
> > 
> > I used the following:
> > 
> > import pylab
> > pylab.rc('pdf',compression=0)
> > plyab.plot([1,2,3],[1,2,3])
> > pylab.savefig('simple.pdf')
> > 
> > See attached.
> > 
> >> Do you know what set of fonts are getting embedded? If their not in the 
> >> mpl set, it's possible they haven't been tested.
> > 
> > Should be the standard set, but I haven't verified.
> > 
> > - Paul
> 
> -- 
> Michael Droettboom
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA

This seems to be a cross platform bug and unrelated to fonts -- at least 
I am able to reproduce it on Linux.
There was a small typo in the recently added support for non-rectangular 
clip paths. Fixed in r3829.
(Jouni -- you may want to review this and verify that my change is correct.)
Cheers,
Mike
Paul Kienzle wrote:
> On Mon, Sep 10, 2007 at 04:19:24PM -0400, Michael Droettboom wrote:
>> Can you set "pdf.compression : 0" and send me a copy of the troublesome 
>> PDF (probably best off list if it's a large file.)?
> 
> I used the following:
> 
> import pylab
> pylab.rc('pdf',compression=0)
> plyab.plot([1,2,3],[1,2,3])
> pylab.savefig('simple.pdf')
> 
> See attached.
> 
>> Do you know what set of fonts are getting embedded? If their not in the 
>> mpl set, it's possible they haven't been tested.
> 
> Should be the standard set, but I haven't verified.
> 
> - Paul
-- 
Michael Droettboom
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Paul Kienzle wrote:
> A further comment on the windows PDF problems. 
> 
> PDF output generated by matplotlib on Windows and on OS X is readable 
> in Preview.app on OS X but is not readable in Acrobat 8.1.0 or 7.0.5 
> on Windows.
> 
> Adobe 7.0.5 produces the message "There were too many arguments".
> 
> At this point I have no idea how to proceed, but I will at least post
> the correct to ttconv.
Can you set "pdf.compression : 0" and send me a copy of the troublesome 
PDF (probably best off list if it's a large file.)?
Do you know what set of fonts are getting embedded? If their not in the 
mpl set, it's possible they haven't been tested.
Cheers,
Mike
-- 
Michael Droettboom
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

A further comment on the windows PDF problems. 
PDF output generated by matplotlib on Windows and on OS X is readable 
in Preview.app on OS X but is not readable in Acrobat 8.1.0 or 7.0.5 
on Windows.
Adobe 7.0.5 produces the message "There were too many arguments".
At this point I have no idea how to proceed, but I will at least post
the correct to ttconv.
	- Paul

I've resolved part of the PDF font problem on windows --- ttconv was not
opening the font file with "rb". I'll send a patch later as soon as I
figure out why acrobat is saying "too many arguments" when opening the
resulting pdf file. Preview.app on OS X opens the files without difficulty.
	- Paul

Hi,
We are having trouble with PDF generation on Windows (see below).
Python 2.4.3 - Enthought Edition 1.1.0
freetype 2.5.3 (GnuWin32 package)
Anyone experienced similar problems?
Meanwhile I'm modifying ttconv to include the font name in the error message.
	- Paul
 
Traceback (most recent call last):
 File "_tmp_alignment_test.py", line 87, in ?
 savefig("alignment_test_pdf", dpi=150)
 File "c:\python24\Lib\site-packages\matplotlib\pyplot.py", line 274, in savefig
 return fig.savefig(*args, **kwargs)
 File "c:\python24\Lib\site-packages\matplotlib\figure.py", line 770, in savefig
 self.canvas.print_figure(*args, **kwargs)
 File "c:\python24\Lib\site-packages\matplotlib\backend_bases.py", line 1195, in print_figure
 orientation=orientation,
 File "c:\python24\Lib\site-packages\matplotlib\backends\backend_pdf.py", line 1943, in print_pdf
 file.close()
 File "c:\python24\Lib\site-packages\matplotlib\backends\backend_pdf.py", line 406, in close
 self.writeFonts()
 File "c:\python24\Lib\site-packages\matplotlib\backends\backend_pdf.py", line 475, in writeFonts
 fontdictObject = self.embedTTF(realpath, chars[1])
 File "c:\python24\Lib\site-packages\matplotlib\backends\backend_pdf.py", line 918, in embedTTF
 return embedTTFType3(font, characters, descriptor)
 File "c:\python24\Lib\site-packages\matplotlib\backends\backend_pdf.py", line 732, in embedTTFType3
 rawcharprocs = ttconv.get_pdf_charprocs(filename, glyph_ids)
RuntimeError: TrueType font may be corrupt (reason 2)

Hi Eric, Mike,
On Monday 10 September 2007 08:08:42 am Michael Droettboom wrote:
> Eric Firing wrote:
> > There is an inconsistency between mpl-data/matplotlib.conf and
> > config/mplconfig.py. The former has [[math]] under [text], but the
> > latter is based on a separate [mathtext]. It would be trivial to
> > resolve the inconsistency, but I don't know which way it should be
> > resolved, so I will leave this to you or Mike.
> >
> Darren,
>
> I trust your judgement on which way to go, as you have a better sense of
> how other settings have been laid out. I'm happy to do the work -- I
> just don't know which is correct going forward (these are new settings,
> so backward compatibility isn't a concern.)
>
> The values in matplotlib.conf should also should be updated to match
> mplconfig.py.
Eventually, matplotlib.conf should be autogenerated when setup.py is run. I 
have not tried to do this yet, maybe I can spend some time on it next 
weekend.
The mathtext settings are more like font.* settings than text.*, so I think 
they should get their own section (like in matplotlib.conf) instead of a 
subsection of text (like in mplConfig).
As for the greater organization of mplConfig, I laid things out in a way that 
made sense to me, but this organization is completely hidden right now, and I 
think we should discuss it before it congeals. For example, some might feel 
strongly that we should stick to the rcParams organization, to make a 
possible future transition as easy as possible. Here is what I changed:
rcParams mplConfig
-----------------------------|-----------------------------------
backend backend.use
font.sans-serif font.sans_serif
text.dvipnghack text.latex.dvipnghack
polaraxes.grid axes.polargrid
cairo.* backend.cairo.*
tk.* backend.tk.*
ps.* backend.ps.*
ps.usedistiller backend.ps.distiller.use
ps.distiller.res backend.ps.distiller.resolution
pdf.* backend.pdf.*
svg.* backend.svg.*
Darren

Darren,
I trust your judgement on which way to go, as you have a better sense of 
how other settings have been laid out. I'm happy to do the work -- I 
just don't know which is correct going forward (these are new settings, 
so backward compatibility isn't a concern.)
The values in matplotlib.conf should also should be updated to match 
mplconfig.py.
Cheers,
Mike
Eric Firing wrote:
> Darren,
> 
> There is an inconsistency between mpl-data/matplotlib.conf and 
> config/mplconfig.py. The former has [[math]] under [text], but the 
> latter is based on a separate [mathtext]. It would be trivial to 
> resolve the inconsistency, but I don't know which way it should be 
> resolved, so I will leave this to you or Mike.
> 
> Eric
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Michael Droettboom
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

John Hunter wrote:
> On 9/9/07, Eric Firing <ef...@ha...> wrote:
>> The Axes.panx() method and several others contain calls to
>> _send_xlim_event() and similar methods. These methods don't seem to be
>> defined anywhere.
> 
> These methods (panx, zoomx) are from the very old toolbar, which
> should be deprecated and removed in my option. It doesn't look like
> they work anyhow, because as you note they rely on the nonexistant
> _send_xlim_event. The xlim callbacks are handled by the
> 'xlim_changed' notification of the callbacks attribute. I think all
> the methods that contain this (panx, zoomx and PolarAxes.set_xlim can
> either be removed entirely or have the _send_xlim_event call removed.
These methods have been broken for a long time, which is a crude form of 
deprecation. I am simply removing them now. Same for the old toolbar. 
 Given that the pan and zoom functions have been broken for so long, I 
don't see how anyone could be using it, so I don't see any point in 
keeping it around with a deprecation warning.
Eric
> 
> JDH

The pylab namespace has gradually gotten messier and messier, with all 
sorts of things dumped into it. A number of people have asked for a 
smaller module that would contain only the state-machine plotting part 
of pylab--that is, the figure, show, plot, contour, etc. sorts of 
functions. The name "pyplot" was suggested. I have made a first cut at 
this in svn, and I hope interested people will take a look and try it 
out. Here are the changes:
1) pylab is still present as a namespace aggregator, importing things 
from numpy and pyplot. So as to avoid breaking existing code that uses 
it, I have kept the numpy.oldnumeric imports rather than importing from 
 numpy itself, but it is done explicitly rather than via numerix. We 
will want to make a transition away from oldnumeric, but I did not want 
to force that immediately. The present pylab should work like the old 
one, except that I removed a few redundant imports. It is possible that 
some user code was using them and will therefore fail, but I expect such 
cases, if any, to be rare and easy to fix.
2) matplotlib.pyplot has all the basic function-based plotting and 
global things like rc and rcParams. If you want a fully modern version 
of pylab in interactive mode, then instead of
from pylab import *
you would do
from numpy import *
from matplotlib.pyplot import *
The latter may be what pylab itself evolves into.
Note that although pylab.py gets installed as a top-level module, 
pyplot does not; you have to qualify it with "matplotlib".
pyplot imports a number of classes from matplotlib in addition to the 
basic functions. If there is a consensus that this should not be 
done--that pyplot should be a smaller and cleaner namespace--it would be 
easy to take out those imports.
I have not written a docstring for pyplot.py yet. I will do that once 
it has been checked out and the design has settled down.
Eric

John Hunter wrote:
> On 9/9/07, Eric Firing <ef...@ha...> wrote:
>> The Axes.panx() method and several others contain calls to
>> _send_xlim_event() and similar methods. These methods don't seem to be
>> defined anywhere.
> 
> These methods (panx, zoomx) are from the very old toolbar, which
> should be deprecated and removed in my option. It doesn't look like
> they work anyhow, because as you note they rely on the nonexistant
> _send_xlim_event. The xlim callbacks are handled by the
> 'xlim_changed' notification of the callbacks attribute. I think all
> the methods that contain this (panx, zoomx and PolarAxes.set_xlim can
> either be removed entirely or have the _send_xlim_event call removed.
> 
> JDH
John,
OK, thanks, I will try to clean this up soon. I stumbled over it 
because one of the wx examples has its own toolbar with buttons that 
call these methods.
Eric

On 9/9/07, Eric Firing <ef...@ha...> wrote:
> The Axes.panx() method and several others contain calls to
> _send_xlim_event() and similar methods. These methods don't seem to be
> defined anywhere.
These methods (panx, zoomx) are from the very old toolbar, which
should be deprecated and removed in my option. It doesn't look like
they work anyhow, because as you note they rely on the nonexistant
_send_xlim_event. The xlim callbacks are handled by the
'xlim_changed' notification of the callbacks attribute. I think all
the methods that contain this (panx, zoomx and PolarAxes.set_xlim can
either be removed entirely or have the _send_xlim_event call removed.
JDH

The Axes.panx() method and several others contain calls to 
_send_xlim_event() and similar methods. These methods don't seem to be 
defined anywhere.
Eric

Michael Droettboom wrote:
> lib/matplotlib/mpl-data/matplotlibrc is generated at build time by 
> interpolating some fields in matplotlibrc.template.
> 
> Since it always get changed, it always shows up as a modified file by 
> svn status. This is only a minor annoyance when working on the trunk. 
> However, when working on a branch with svnmerge, svnmerge won't let me 
> merge from trunk if I have any modified files at all, so every time I 
> want to merge, I have to be sure to revert that file.
> 
> Is there any reason not to just remove this file from SVN?
> 
I could not think of any reason, and I did not see any message to the 
contrary, so I went ahead and removed it.
Eric

Darren,
There is an inconsistency between mpl-data/matplotlib.conf and 
config/mplconfig.py. The former has [[math]] under [text], but the 
latter is based on a separate [mathtext]. It would be trivial to 
resolve the inconsistency, but I don't know which way it should be 
resolved, so I will leave this to you or Mike.
Eric

Yes, the mathtext should be red. I was testing color and forgot I had deviated from what's checked in for that example.
Thanks for the news. It's great that it's working in so many places now with your help.
Cheers,
Mike

On Fri, Sep 07, 2007 at 04:04:28PM -0400, Michael Droettboom wrote:
> Paul Kienzle wrote:
> > It looks the same as the version without embedded fonts, which is that it
> > chooses some incorrect default font with the wrong character codes as I
> > showed earlier.
> 
> That's very surprising, since when the characters are embedded, there's 
> no notion of characters (<text> elements) in the file at all -- it just 
> uses references to paths in the file that have non-meaningful names like 
> c_a2.
Too many variations --- yes embedded fonts work fine on Adobe SVGViewer.
> >> Do you know if the SVG output from Cairo works with Adobe? They use a 
> >> similar (but not identical) approach to embedding the character outlines.
> > 
> > I'm not set up to run Cairo, but I can check if someone sends me an svg.
> 
> Attached (gzipped).
The mathtext comes through in red on Safari, Adobe and Firefox. 
Is this intended?
	- Paul

Michael Droettboom <md...@st...>
writes:
> I couldn't find references anywhere to \angstrom being a real command
> in LaTeX (and it doesn't work by default on my LaTeX installation when
> I tried it.) But I may just not be Googling right. If you can find a
> reference, I'm happy to make the one-line change to support it.
In The Comprehensive LaTeX Symbol List, the entry for Ångström points to
\mathring (for math mode) and \AA (for text mode), so \angstrom is
probably not in any widely used package:
http://www.ctan.org/tex-archive/info/symbols/comprehensive/symbols-a4.pdf
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

As of r3815, you can do \AA in a mathtext expression.
It would be very easy to support both \angstrom and \AA, but in the 
interests of trying to be as LaTeX-like as possible, I think we should 
just do \AA, though IMHO \angstrom is easier to remember. I couldn't 
find references anywhere to \angstrom being a real command in LaTeX (and 
it doesn't work by default on my LaTeX installation when I tried it.) 
But I may just not be Googling right. If you can find a reference, I'm 
happy to make the one-line change to support it.
Cheers,
Mike
william ratcliff wrote:
> It may be a hassle, but perhaps you could allow
> \AA and \angstrom to both represent angstrom.
> 
> Thanks!!!
> 
> William
> 
> On 9/7/07, *Michael Droettboom * <md...@st... 
> <mailto:md...@st...>> wrote:
> 
> Sorry -- that used to work, but fell through the cracks in the recent
> mathtext rewrite. It shouldn't be difficult to add back in. I'll let
> you know when that's done.
> 
> Cheers,
> Mike
> 
> william ratcliff wrote:
> > Maybe I'm doing something wrong, but is there support for \AA {the
> > angstrom} symbol within mathtext for any of the backends? If
> not, would
> > it be difficult to add?
> >
> > Thanks,
> > William
> >
> > On 9/7/07, *Paul Kienzle* < pki...@ni...
> <mailto:pki...@ni...> <mailto:pki...@ni...
> <mailto:pki...@ni...>>>
> > wrote:
> >
> > On Fri, Sep 07, 2007 at 03:09:10PM -0400, Michael Droettboom
> wrote:
> > > Paul Kienzle wrote:
> > > > On Fri, Sep 07, 2007 at 12:09:01PM -0400, Michael
> Droettboom wrote:
> > > >> Paul Kienzle wrote:
> > > > Note: Adobe SVGViewer doesn't see the embedded fonts,
> but it
> > works if I
> > > > have the fonts installed. Oh, well!
> > >
> > > With the embedded fonts, you mean the text just doesn't
> show up
> > at all?
> >
> > It looks the same as the version without embedded fonts,
> which is
> > that it
> > chooses some incorrect default font with the wrong character
> codes as I
> > showed earlier.
> >
> > I thought unicode was supposed to give unique codes to the
> characters
> > so that even if the font was wrong, at least you would get
> the correct
> > glyph from the font. Or does this only happen at a higher level?
> >
> > > Do you know if the SVG output from Cairo works with
> > Adobe? They use a
> > > similar (but not identical) approach to embedding the
> character
> > outlines.
> >
> > I'm not set up to run Cairo, but I can check if someone sends
> me an svg.
> >
> > - Paul
> >
> > 
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems? Stop.
> > Now Search log events and configuration files using AJAX and
> a browser.
> > Download your FREE copy of Splunk now >> http://get.splunk.com/
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> <mailto:Mat...@li...>
> > <mailto: Mat...@li...
> <mailto:Mat...@li...>>
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
> >
> 
> -- 
> Michael Droettboom
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
> 
> 
-- 
Michael Droettboom
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

It may be a hassle, but perhaps you could allow
\AA and \angstrom to both represent angstrom.
Thanks!!!
William
On 9/7/07, Michael Droettboom <md...@st...> wrote:
>
> Sorry -- that used to work, but fell through the cracks in the recent
> mathtext rewrite. It shouldn't be difficult to add back in. I'll let
> you know when that's done.
>
> Cheers,
> Mike
>
> william ratcliff wrote:
> > Maybe I'm doing something wrong, but is there support for \AA {the
> > angstrom} symbol within mathtext for any of the backends? If not, would
> > it be difficult to add?
> >
> > Thanks,
> > William
> >
> > On 9/7/07, *Paul Kienzle* <pki...@ni... <mailto:pki...@ni...>>
> > wrote:
> >
> > On Fri, Sep 07, 2007 at 03:09:10PM -0400, Michael Droettboom wrote:
> > > Paul Kienzle wrote:
> > > > On Fri, Sep 07, 2007 at 12:09:01PM -0400, Michael Droettboom
> wrote:
> > > >> Paul Kienzle wrote:
> > > > Note: Adobe SVGViewer doesn't see the embedded fonts, but it
> > works if I
> > > > have the fonts installed. Oh, well!
> > >
> > > With the embedded fonts, you mean the text just doesn't show up
> > at all?
> >
> > It looks the same as the version without embedded fonts, which is
> > that it
> > chooses some incorrect default font with the wrong character codes
> as I
> > showed earlier.
> >
> > I thought unicode was supposed to give unique codes to the
> characters
> > so that even if the font was wrong, at least you would get the
> correct
> > glyph from the font. Or does this only happen at a higher level?
> >
> > > Do you know if the SVG output from Cairo works with
> > Adobe? They use a
> > > similar (but not identical) approach to embedding the character
> > outlines.
> >
> > I'm not set up to run Cairo, but I can check if someone sends me an
> svg.
> >
> > - Paul
> >
> >
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems? Stop.
> > Now Search log events and configuration files using AJAX and a
> browser.
> > Download your FREE copy of Splunk now >> http://get.splunk.com/
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > <mailto:Mat...@li...>
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
> >
>
> --
> Michael Droettboom
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>