fix SVG2PDF

[minrk]

there were some logical issues, with SVG2PDF assuming it was run
both before and after figure extraction.

Also makes the inkscape command configurable,
in case it doesn't work some places.

Adds pdf block for output in latex templates.

closes #3693

[jdfreder]

Looks good to me. I can open a PR later adding Win support.

[Carreau]

You could have waited a little before merging this...

Adding this kind of things was exactly what I was hopping to avoid.
The display data priority should match 1 to 1 with the mimetype of the notebook.
If we add PDF, for latex, then why not add :

• tif
• gif
• bmp
• ps
• dvi
• ...

This was the point of the configurability of ext-map that @ellisonbg wanted to remove. The png/jpg/latex/text/... block should insert into the template the name of the converted figure not the name of the original figure.

[minrk]

it is a bug that the notebook doesn't support
arbitrary mine types, that is mainly a result

[Carreau]

So you basically thing we should have almost infinite kind of _repr_mimetype_ ?

[minrk]

mainly a result of a poor decision in the JavaScript, where we convert mine type keys in the display protocol to short keys. We will remove this transform in the next nbformat, thus adding support for all mine types to the notebook document.

[minrk]

So you basically thing we should have almost infinite kind of repr_mimetype ?

The display protocol and display formatted are already extensible to support this. it's just a bug in the notebook document spec that it doesn't reflect this.

[jdfreder]

A possible solution for the scenario with infinite mime-types would be to add another transformer, one that performed the same mapping functionality @Carreau implemented in the original extract figure transformer. Maybe a FileRenameTransformer... Like @minrk said, something else will be required in 2.0

[Carreau]

Hum I don't quite see how this works from end to end, But we'll have the wek to discuss that then.

[minrk]

For now, we can call the writing the new key in the notebook structure instead of resources for the transforms a sub-optimal implementation, and next week we can discuss how we want to deal with the fact that the notebook can contain arbitrary mime-types in 2.0.