Joris, On 11 Nov 2013, at 10:02, Joris van der Hoeven <vdhoe...@texmacs.org> 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 > Texmacs-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/texmacs-dev _______________________________________________ Texmacs-dev mailing list Texmacs-dev@gnu.org https://lists.gnu.org/mailman/listinfo/texmacs-dev
