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

[Joris van der Hoeven]

On Wed, Nov 13, 2013 at 11:37:27AM +0100, Massimiliano Gubinelli wrote:
> PDF has various encoding possibilities for images, some of them corresponds 
> to particular cases of PNG and JPG. In these cases a direct copy of the 
> compressed images and a straighforward translation of the metadata is enough, 
> in the other cases the data has to be reencoded, for example by writing the 
> pixels and then using standard lossless compression methods for PDF streams 
> which are for free already in the library.

I see.

> For JPG I can do without jpg library I found some simple code in pdfTeX to do 
> the job.
> Strangely I didn't found any example to read directly png images, all the 
> software I found uses the png library.
> I'm not sure I want to spend much time on this issue.

Maybe a good compromise would be the following:
whenever it is possible to directly embed the png file into the Pdf file, then 
do so.
Otherwise, load the image as a pixmap and embed it as a raster.
This actually seems to be a good strategy for all formats.

> Also if we decide to use ImageMagick then all this is somewhat useless since 
> ImageMagick can treat all the formats and more. But I'm not sure it will do 
> the best job, especially for lossy formats. I found this page
>
> https://github.com/josch/img2pdf
> 
> which comments how direct inclusion for jpg provide better results than 
> programs like ImageMagick.   

If necessary, then we might use some kind of plug-in mechanism.
If extra utilities are present, then we may use them to
provide better and shorter inclusion of images into Pdf.

I would prefer to keep the number of dependencies of TeXmacs
down to the minimum.  However, we can sometimes break this rule
by directly including small third party binaries into our binary
distributions (as we do with ghostscript).  For instance,
I would be OK with including img2pdf except for its dependency on Python.

> >> The point is that ideally one should keep (lossy and lossless) compressed 
> >> formats compressed. Qt can read all the formats but give back only the 
> >> uncompressed bits, so this is almost useless if you want to put the image 
> >> into a compressed file format like PDF. The point is to try to maintain 
> >> the data compressed without wasting time in uncompressing it and then 
> >> recompressing it (in necessarily unoptimal ways). 
> > 
> > I agree that compressed images should not be touched.
> > But if we do not want to touch them, why do we need libpng?
> 
> As said above: you cannot simply copy the image file, you have to put the 
> metadata in some format and then put elsewhere the compressed streams into 
> proper PDF structures.

So we just need something to extract the metadata and the compressed
streams from the images, as does img2pdf in the case of jpg?
It would be overkill to use libpng or a jpeg library for that, right?

> My main worry is to treat properly (at least in PDF) lossy image formats like 
> JPG and for that I think I found a solution which does not involve the jpg 
> library or external programs. 

OK, so I consider the problem solved for jpg.
What about png?  Is a similar solution hard to achieve?

Best wishes, --Joris