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

[Massimiliano Gubinelli]

Joris,
 
On 11 Nov 2013, at 10:02, Joris van der Hoeven <address@hidden> wrote:

> Hi Max,
> 
> On Sun, Nov 10, 2013 at 02:15:24AM +0100, Massimiliano Gubinelli wrote:
>> Handling of images is a problematic issue. To embed images in PDF we need to 
>> convert them to PDF before, at the moment I use ImageMagik since it is an 
>> easy way to do.  I would like to discuss more deeply the handling of images 
>> in TeXmacs. We rely on various methods and it is quite confusing to me. I 
>> think we should settle down to some standard way of doing, independent of 
>> platform if possible. Our requirements are the following:
> 
> ImageMagick provides the richest set of conversion routines.
> Yet, I am not sure that it handles everything.
> For this reason, I designed our mechanism for easily
> adding converters whenever certain conditions are met.
> The downfall of this method is that conversion becomes
> quite dependent on system installations, which makes
> debugging harder.  We might try to include a small number of
> most powerful tools to the standard distribution so as to
> guarantee minimal correct behaviour.
> 

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. 


>> The graphic backend needs a bitmap for the image.
>> The ps backend needs a eps file for the image.
>> The pdf backend needs a pdf file for the image.
>> 
>> How to proceed to support the largest number of image format in reliable 
>> way? For example if I have a jpg image I would like to retain the 
>> compression in the pdf and in the eps. 
>> 
>> Can we rely on Qt?
> 
> 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.

> 
>> Should we ship ImageMagik and Ghostscript by default to support these 
>> conversions?
> 
> It seems that Ghostscript is still needed for rendering Postscript.
> But maybe Poppler will now be a better option; I don't know.
> In any case, we still want to provide Postscript <-> Pdf converters.
> 

Poppler cannot read ps, just pdf. If I'm not wrong.

>> Should we try to convert the formats to EPS by hand and then use GS to 
>> convert them to PDF?
> 
> We currently do so.
> 

yes. But the current PS output has the following drawback: raster images are 
converted (internally in TeXmacs) to EPS and this means for example that JPG 
images are expanded and put in the final PS file uncompressed or that PNG 
images lost their original alpha channel.


>> I’m a bit lost.
> 
> I understand.  Maybe someone could investigate in detail and
> send us an overview of supported formats and conversions for
> various tools, taking quality (bitmap / vector graphics) into account.
> 

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?

Best,
Max


> Best wishes, --Joris
> 
> _______________________________________________
> Texmacs-dev mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/texmacs-dev