ipynb -> tex converter

[Carreau]

Hi,

I love your notebooks on nbconvert.

We are working on the brand new nbconvert to convert IPython noteboko files, and especially latex here , pinging @jdfreder that he is the most involved in the latex converter. I thought this might interest both you to convert to latex, and us to have a nice example to get feedback and refine the settings.

Also, if/when you wish I can also put you on the home page of nbconvert.

[CamDavidsonPilon]

I do plan, eventually, to convert them all to latex/pdf, and nbconvert would have been my first choice. I'd love to offer my assistance. How can I help?

I'm fine with being add to the home page. Thanks for the contact!

[Carreau]

I do plan, eventually, to convert them all to latex/pdf, and nbconvert would have been my first choice Great ! Hopefully nbconvert 2.0 will be integrated in the next versin of IPyhton !

How can I help?

Depending on how much you like to dive in code from :

• Try to convert your files to tex @jdfreder have some new stuff and might guide you on that and tell us what does not work, what you wish to change.

to

• Wrinting your own templates/transformer and submitting pull request. :-) That's not too hard :-)

We can also just use your book to test and send you the PDFs for comment :-)

As for nbviewer, tell me if you want to do a screenshot yourself or if I do, and when you are "ready" to be added (ie so that the url will not change) and I'll take care of the rest when I have some time.

[CamDavidsonPilon]

Cool! I'll probably aim for the former, and let you and @jdfreder know how it goes.

Also, please add

with the (permanent) url below. Thanks Matthias!

http://nbviewer.ipython.org/urls/raw.github.com/CamDavidsonPilon/Probabilistic-Programming-and-Bayesian-Methods-for-Hackers/master/Chapter1_Introduction/Chapter1_Introduction.ipynb

[jdfreder]

Hi @CamDavidsonPilon

It's been a while since there has been any conversation in here.

Like @Carreau mentioned I'm adding a PDF/Latex output template powered by Sphinx. I've approached a place in the development where I'm polling different notebook users about the output. Your notebook is absolutely beautiful. It is actually my favorite to show off because of the color scheme you chose for your plots. I'm experimenting with two output styles. I'm looking for feedback on which of the two styles you prefer, why, and any suggestions you may have.

The two styles included are,

• Notebook default (http://bitplexity.com/notebook%20Chapter1_Introduction.pdf) Input/Output cells are treated the same way they are treated in the notebook. Both cell types are indented and 'prompts' (I.E. “In [#]:”) are added in the margin as necessary. The input cells are encapsulated in a light gray box with slightly rounded corners.
• Simple (http://bitplexity.com/simple%20Chapter1_Introduction.pdf) Input/Output cells are labeled by a small font “Input” / “Output” underscored by a thin horizontal break. The contents of the cell share the same margins as the rest of the document. This is useful for displaying large blocks of input and output.

Note that the images in the output look like they are being scaled up in size. This is because of the DPI setting of matplotlib. Since I converted the file directly from the gallery, the source is unmodified. To adjust DPI settings of the notebook's output, refer to @minrk 's post here – http://mail.scipy.org/pipermail/ipython-user/2011-October/008699.html.

As an iPython notebook contributor, your input is not only valued but very influential. Any comments, concerns, or suggestions are greatly appreciated! Thank you in advanced for your feedback.

CC: @ellisonbg

[CamDavidsonPilon]

Hi Jonathan,

First let me say thank you for making beautiful pdfs of the book. There has been interest in pdf versions, see 1 and 2 plus personal requests, so I think people will be happy to see the great progress here. (Also thanks for the compliments about the book and continued sharing, I appreciate it =)

Overall, I preferred the styling of Simple. But I'll go into detail about both:

1. Default notebook:
   • A common issue is that the box style cuts of the code. This should be an authors fix (by adhering to PEP standards), but a safety net for misses is probably a good idea.
   • The In [56] etc. are not need. Not only are they rarely correctly sequential, but the require a lot of white space and end up uncentering the images.
2. Simple style
   • I prefer this style of code i/o. It looks cleaner, more book-like/professionally done, and it doesn't suffer from the cutoff's that were present in Default style. The only downside are instances of repeated code i/o can be hard to distinguish (see Section 1.3). The Default style does not suffer from this (compare with Section 1.3 in that pdf).

A few comments overall:

• Page numbers are definitely needed.
• I'm curious about the behaviour of the shortened hrule (see the 3rd last page).
• A much preferred font would be the native Latex font or Modern Computer (or the ability to set fonts in the meta-data).
• Instead of An Introduction to Bayesian Methods, can it be switched to Bayesian Methods for Hackers?

The project looks great, and I'm happy you know how to do this! (I resorted to chrome -> print as pdf, which is pretty tech-less.) Thanks Jonathan.

Also, I'll add some code to increase the DPI.

[Carreau]

The In [56] etc. are not need. Not only are they rarely correctly sequential, but the require a lot of white space and end up uncentering the images.

That would probably be a 1 line template change (and you can inherit from other template so it won't be hard) but I think that by default we should provide a style close to notebook as we'll try to add a "download as PDF" button.

Also, I'll add some code to increase the DPI.

I would also suggest to switch InlineBackend to SVG. nbconvert shoud be able (in the end) to extract svg, convert them to pdf and re-include them. Then they wouldn't be any issues with DPI. Still I'm not sure if alpha channel svg->pdf and all pdfreader support it well.

[ellisonbg]

Cameron,

First of all, we love your notebooks! They are one of the best examples of how the notebook can be used to deliver book like content. Awesome work!

1.Default notebook:

• A common issue is that the box style cuts of the code. This should be an authors fix (by adhering to PEP standards), but a safety net for misses is probably a good idea.
• The In [56] etc. are not need. Not only are they rarely correctly sequential, but the require a lot of white space and end up uncentering the images.
  1. **

Our goal with the notebook style is to reproduce the look of the notebook as much as possible. When people are preparing a notebook for output to pdf, they will probably want to rerun the entire notebook starting from a fresh kernel to make sure the prompts are sequential and start with 1. We really view the prompt numbers as important information - they allow you to reference individual bits of code in the narrative text ("The algorithm we have implemented in input 1 shows that..."). As Matthias describes, it will be possible to override this in the templates, but as a default, I think we do want them in the output.

1. Simple style
   • I prefer this style of code i/o. It looks cleaner, more book-like/professionally done, and it doesn't suffer from the cutoff's that were present in Default style. The only downside are instances of repeated code i/o can be hard to distinguish (see Section 1.3). The Default style does not suffer from this (compare with Section 1.3 in that pdf).

I agree. It is a really tough balance game and we are trying to focus our efforts on developing two default styles that will work for most usage cases. (maybe we are crazy...) But for users who need more control, they will have to dig into the code and customize the templates.

A few comments overall:

• Page numbers are definitely needed.
• I'm curious about the behaviour of the shortened hrule (see the 3rd last page).
• A much preferred font would be the native Latex font or Modern Computer (or the ability to set fonts in the meta-data).
• Instead of An Introduction to Bayesian Methods, can it be switched to Bayesian Methods for Hackers?

Great catch on the page numbers, we will make sure to add those.

The shortened hrule is part of the sphinx latex template we are using.

In terms of font's you can probably change that in the templates, but we will probably stick with these defaults (the sphinx template sets all of that).

Adjusting the title shouldn't be a problem.

The project looks great, and I'm happy you know how to do this! (I resorted

to chrome -> print as pdf, which is pretty tech-less.) Thanks Jonathan.

Cheers,

Brian

Also, I'll add some code to increase the DPI.

— Reply to this email directly or view it on GitHubhttps://github.com/CamDavidsonPilon/Probabilistic-Programming-and-Bayesian-Methods-for-Hackers/issues/5#issuecomment-16091341 .

Brian E. Granger Cal Poly State University, San Luis Obispo bgranger@calpoly.edu and ellisonbg@gmail.com

[CamDavidsonPilon]

@Carreau @ellisonbg @jdfreder ok, thanks for the responses and overall project. I am unfamilar with Sphinx templates, but they sounds quite flexible. @Carreau is working on styling for the browser and nbviewer: will these custom styles be auto-generated for nbconvert, or will a seperate sphinx template need to be built?

[Carreau]

@Carreau https://github.com/Carreau is working on styling for the browser and nbviewer: will these custom styles be auto-generated for nbconvert, or will a seperate sphinx template need to be built?

No I guess the templates will have to be built. it shoudl be pretty strait forward to say to user, 'put this file here and you now have acces to template'.

But that's really a detail about which nbconvert lib does not care.

On Wed, Apr 10, 2013 at 6:12 AM, Cameron Davidson-Pilon < notifications@github.com> wrote:

@Carreau https://github.com/Carreau @ellisonbghttps://github.com/ellisonbg @jdfreder https://github.com/jdfreder ok, thanks for the responses and overall project. I am unfamilar with Sphinx templates, but they sounds quite flexible. @Carreau https://github.com/Carreau is working on styling for the browser and nbviewer: will these custom styles be auto-generated for nbconvert, or will a seperate sphinx template need to be built?

— Reply to this email directly or view it on GitHubhttps://github.com/CamDavidsonPilon/Probabilistic-Programming-and-Bayesian-Methods-for-Hackers/issues/5#issuecomment-16154485 .

[jdfreder]

@CamDavidsonPilon Yeah, the styles will have to be written by hand.

The current template is special in that it actually inherits directly from the Sphinx source code. In essence, it provides a way of bringing Sphinx Latex capability to iPython Notebooks. Sphinx already supports multiple document formats and two major output types ( a book type and report type ) , all of which are available through NBconvert now. As Sphinx is expanded, the new template will not need to be adjusted to accommodate the new styles... They should just work.

What the NBconvert Sphinx-Latex template does is fill the document using Sphinx appropriate Latex commands. The task currently at hand is to tweak how we utilize Sphinx and it's Latex template with our own Latex. When I get some time this week I'll upload some of the other Sphinx styles for you, I think they may use different fonts. I know they do have different header styles at least.

Also, Thank you for pointing out the page numbers! They should be working, somewhere along the line I must have managed to break that (Latex can be very ... fragile.) Like @ellisonbg said, the title is not a problem and normally it is set in the metadata of the NB. Since a lot of the NBs in the gallery do not have proper titles (plagued with underscores), I overrode all of them using the titles of the links I found in the gallery.

-Jon

[ghost]

Re the usage of the "In[56]" numbering as references in the text, that really breaks down badly when the user is encouraged to experiment and rerun the code cells, these notebooks being an obvious example.

Having latex-like anchors for cells (which markdown cells can reference) would be very useful for doing long documents, but the "In[]" headers aren't it IMO.