Re: [Texmacs-dev] pdf & texmacs

[Massimiliano Gubinelli]

Dear Philippe,

> On 14. Feb 2022, at 11:31, Philippe Joyez <philippe.joyez@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