Dear Philippe, > On 14. Feb 2022, at 11:31, Philippe Joyez <philippe.jo...@cea.fr> wrote: > > Hi Max, > > Yes, at present we cannot ensure a reproducible image handling across > users because we use a collection of external tools that are not always > present and that can differ in version numbers. I would be very much in > favor of handling images with less variability, and independently of the > GUI. Also, in addition to the formats you mention I think we should > support svg because it is the standard vector format for the web. >
yes, I agree, we should need some strong support for PDF, PNG, JPG, SVG which is independent on other libraries like Qt. > > In the repo, I have noticed that some work was made on a Cairo renderer > in the past, and I am surprised you do not explicitly consider this as > an option in your post. Indeed, Cairo is versatile in terms of output > formats (ps, pdf, svg, bitmap), and good libraries exist to put anything > we need onto cairo surfaces (poppler for pdf, librsvg for svg). Is there > a major roadblock that prevents using this already started Cairo > renderer to achieve what you have in mind (and support svg at the same > time)? > There is no particular reason. Actually I would like to discuss here what the other developers thinks. What I do not like right now is that some Qt code start to affect other parts like the PDF renderer, due to need to handle images, and that we have image handling logic here and there in our code, at least in two places: in image_files.cpp and in qt_utilities.cpp and some other qt files etc... In my mind we cannot really ship TeXmacs without some basic and uniform image support, including vector formats like PDF and SVG, so I would like to rethink how things are organized and make them independent of Qt. My reason not to use the cairo renderer is the following: if we want to be able to "read" PDF then we need to include already some PDF input library like poppler, mupdf or pdfium. All these libraries have their own internal graphics API to convert PDF into bitmaps (pdfium uses AGG or experimentally Skia). So if we use one of these libraries we do not really need to add another dependence on a "large" library like cario. All these dependences also make more complex to support wasm since they make our executable bigger. My current attempt is to use mupdf, it is well done and we could include it statically. It provides PDF input and also some SVG support. And I'm trying to use it also to draw on screen by having a renderer which interprets TeXmacs commands and create calls to PDF graphic operators into mupdf which then produces a bitmap which we can put on screen. In this way we can make our "core" independent of Qt or any other UI library, and at the same time avoid depending on Cario or other graphics library, and be able to import PDF and SVG. To read other image formats I guess we will have to include libpng and libjpg, but they are small and a tiny price to pay. Of course on Linux we can use the system ones, but on Windows and Mac it is easier to just bundle the libraries with our code. Suggestions, opinions are welcome. Best Max > Best, > > Philippe > > > _______________________________________________ > 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
