<div>Hey Paul,</div><div><br></div>Hmm. So, two things:<div><br></div><div>- If I were to add it to the &quot;simple&quot; metadata editor (as is currently the case with slideshow stuff, I think?) wouldn&#39;t that force a key name?<br>
- similarly, fine-grained behaviour (code but not output, output but not code) seems hard to accomplish in a generic way.</div><div><br></div><div>Thoughts?</div><div><br></div><div>David</div><div class="gmail_extra"><br>
<br><div class="gmail_quote">On Thu, Nov 15, 2012 at 6:01 PM, Paul Ivanov <span dir="ltr">&lt;<a href="mailto:pivanov314@gmail.com" target="_blank">pivanov314@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Thu, Nov 15, 2012 at 2:44 PM, David Warde-Farley <span dir="ltr">&lt;<a href="mailto:d.warde.farley@gmail.com" target="_blank">d.warde.farley@gmail.com</a>&gt;</span> wrote:<br></div>
</div><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I just had an idea for a feature and wanted some feedback before I implement it.<div><br></div><div>There&#39;s a pull request in the nbconvert queue to suppress certain content types at export time. I was wondering if it would make sense to use the new cell metadata mechanism to allow selective suppression of individual cells at export time: either the input, the output, or both.</div>


<div><br></div><div>I guess my thought is that sometimes, you don&#39;t want to know how the sausage is made; sometimes you just want the image and not the code to generate it to be displayed in the tutorial/book/etc. Things like %pylab inline don&#39;t necessarily add much to a printed document either. Of course, if they  grab the ipython notebook format, that code will all be there.</div>


<div><br></div><div>Thoughts? Any preferences on key names, values, etc.?</div></blockquote><div><br></div></div></div><div>Hi David!</div><div><br></div><div>this sounds great. My understanding is that there should be no strict/formal structure to metadata, so in light of the perfectly legitimate scenario you describe, it would be best that provide generic converters, which subclass the ones we have available, and then decide to only include, or selective exclude content based on the cell metadata. This might even be a mixin for the converter classes we have now, so at the command line you could do something like --ignore-metadata=&#39;solution&#39;, or --only-metadata=&#39;awesomeness&#39;</div>
<span class="HOEnZb"><font color="#888888">
<div><br></div></font></span></div><span class="HOEnZb"><font color="#888888"><div><br></div>-- <br>Paul Ivanov<br>314 address only used for lists,  off-list direct email at:<br><a href="http://pirsquared.org" target="_blank">http://pirsquared.org</a> | GPG/PGP key id: 0x0F3E28F7<br>


</font></span></div>
<br>_______________________________________________<br>
IPython-dev mailing list<br>
<a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
<br></blockquote></div><br></div>