texmacs-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Massimiliano Gubinelli
Subject: Re: [Texmacs-dev] [TeXmacs] New experimental Pdf export facility
Date: Tue, 12 Nov 2013 23:22:40 +0100

Hi  Joris,

On 12 Nov 2013, at 17:58, Joris van der Hoeven <address@hidden> wrote:

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.


ok. that is fine with me. only advantage with static linking is that we will not have problems dealing with the right ghostscript in actual installations but if at the moment there are no such issues we can continue with the command line interface. 

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.


I think is the best solution. Note that we need ghostscript also to convert eps->pdf for pdf inclusion of eps images. 

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.


I was looking to how pdftex handle the problem. If I understand well their code they can include directly jpg images without any external support (and without uncompressing the jpg stream). For png they rely on libpng to read the files. I think I can use Qt to read the actual bits and obtain enough information (DPI, color depth, color map, to reconstruct a faithful representation of the png data inside the pdf). 

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). 

We can put them uncompressed, but this is not optimal and I would avoid that as much as possible. 

ImageMagick can produce EPS/PDF from any raster image file (I assume it does the correct thing, that is keep the lossy compressed formats, compressed, to be checked). So maybe we should rely on it. However I was encountering some scaling problems. I should investigate them fuller. In some sense we need in any case to read the images to get info about sizes and dpi etc... to be able to produce the right PDF commands to scale them correctly.


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_?


Qt can produce images (especially raster) to any common format (png, maybe jpg, pdf and eps) so I think there are no problem producing them. 

best
Max


Best wishes, --Joris


reply via email to

[Prev in Thread] Current Thread [Next in Thread]