Re: [Texmacs-dev] [TeXmacs] New experimental Pdf export facility

[Joris van der Hoeven]

On Mon, Nov 11, 2013 at 11:49:23PM +0100, Massimiliano Gubinelli wrote:
> one drawback of this approach is that the capabilities and output of TeXmacs 
> will depend on which system it is installed. I think we should support a 
> number of formats in a standardized way and then have the opportunity of 
> handling some more specialized formats on a optional basis. Even if I do not 
> see much gain in doing so. 

Yes, the set of formats which are supported in a standard manner needs to be as 
large as possible.

> > I think that it does not support all possible formats.
> > There is also SVG, for instance.
> 
> Qt has a pluging to load SVG, so it can convert it to PDF also.

OK, good to know.

> In general I would like to avoid post-processing of images in PDF output, 
> ideally images should be put in PDF with the minimum number of modification. 
> For example it is possible to put JPG directly in PDF without any post 
> processing. Curiosly PNG is a very complicate format to read and all the 
> software I've checked (including Ghostscript) use libpng to read png. 
> 
> I think we should support at least 4 kind of input formats:
> 
> png - for uncompressed bitmap images
> jpg - for compressed bitmap images
> eps - for vector graphics and backward compatibility
> pdf - for modern vector graphics
> 
> optional formats:
> svg - maybe with the help of Qt 
> jbig2, tiff - seems common compressed formats for which reliable libraries 
> exists.
> 
> we need three kind of output: bitmaps (for onscreen rendering), ps and pdf.
> 
> relying on libpng and libjpg will allow to export images into ps and pdf 
> output direclty and in a standard way.
> ghostscript (which anyway depends on libpng and jpeg library) is needed to 
> rasterize ps (and pdf?) images and to convert ps to pdf for pdf output.
> 
> we cannot simply rely on poppler since we need ghostscript anyway for ps (it 
> is the only software able to interpret ps files).
> 
> ghostscript can be called via its C API instead of via system commands, this 
> will allow us to static link ghostscript and avoid many problems and ensure 
> uniform output across architectures.
> 
> so my proposal is to ship ghostscript and libpng and jpeg library with 
> TeXmacs (eventually via static linking on Mac and Windows) and to rely on 
> them for the basic conversions. Other formats can then handled as usual via a 
> plugin mechanisms (for example use Qt to input other formats beyond the basic 
> four).
> 
> My main motivation is the following: Qt can handle png and jpeg but I need 
> the libraries anyway to be able to include in an optimal way the images into 
> PS and PDF. A supporting argument is that we cannot do without Ghostscript if 
> we want to support eps and to build a ghostscript inside a given system one 
> has to build anyway libpng and the jpeg library so we can safely assume that 
> we dispose of such libraries in the developing environment of TeXmacs.
> 
> Joris, what do yo think?

At least one things seems clear: we still need Ghostscript for postscript 
support.
I think that using the binary works fine, so best would be to change nothing to
the way we handle Postscript.

Another thing that is clear is that we want to rely on your new exporter
for producing Pdf.  Importing Pdf can still be done via Ghostscript,
at least for the moment.

As to pure image formats (jpg, png, tiff, svg, etc.), I would like to avoid
depending on too many libraries.  Ideally, Qt should be able to do them
all for us.  If not, Qt in combination with a tool such as ImageMagick
which supports many different formats.  I agree that it is best to touch
images files as little as possible when including them in Pdf output.
Is there a way to include them in some kind of verbatim/escaped fashion?
I still don't understand why libpng and the jpeg library would be necessary.

There is also the question of producing image files directly from TeXmacs,
for instance when exporting mathematical formulas to Html.  What exactly
does Qt provide for the manipulation of image _files_?

Best wishes, --Joris