Re: [Texmacs-dev] Printer widget questions and implementation proposal

[Gubinelli Massimiliano]

Hi,

On 11 nov. 2010, at 14:33, Miguel de Benito Delgado wrote:

Hi,

  now that I'm a trifle more familiar with the code (sorry for the shifting around of things, I hope it's worth it in the future), I'm trying the printing stuff. Please comment as extensively as you can on this:

In src/Edit/Editor/edit_main.cpp line 259 (edit_main_rep::print_buffer (string first, string last)) there's a comment stating that QT printing is supposed to be done from that point on and other related methods in edit_main_rep ignored. I would then more or less create my QTPrintDialog here, and do the actual printing.

this is part of my first attempt to implement a qt print dialog, we will drop it when we will have a working implementation of the print dialog. With Joris we have discussed the problem and he decided  that, at least for the moment, the printing API should be based on the printer_widget function as defined in widget.hpp. That is: Qt receives a pdf or ps representation of the document to print and can use it at will: change pagination, scaling, take a subset, etc.... before sending to the printer. This strategy it is not perfect but is reasonably simple to implement and need minor changes in the texmacs code. On mac for example we can also provide a preview. On the other platform we can provide a preview using ghostscript if available (to convert the ps to images) or Poppler if we decide to support it as a TeXmacs/Qt plugin. 

However, if I were to follow the model of chooser_widget, I think I'd have to do the following:

1. Add a method print_file to server_rep, then implement it in those classes inheriting from it.
2. From within those implementations, proceed like in tm_frame_rep::choose_file, and instantiate a new generic printer_widget.
3. Implement this printer_widget, at least a Qt version of it. It should print the current document or parts of it, etc.
4. #ifdef my way around a bit to leave things as they were before, for other platforms.

If this is the right way to proceed, please confirm. And then comment on this issue, related to the third item:

src/Graphics/Gui/widget.hpp says the following:

widget printer_widget (url ps_pdf_file);

  // widget for printing a file, offering a way for selecting a page range,

  // changing the paper type and orientation, previewing, etc.

But it would be way more reasonable, from a QT point of view, to have the renderer passed as an argument to the printer. Then I could just patch its output to my QPrinter and have the printing done. Since there's not a single implementation of printer_widget that I can find in the code, may I change the prototype to something along the lines of widget printer_widget (renderer r) ?

The printing problem is quite subtle and I do not see how passing a renderer can provide an alternative api. Could you explain me better you rationale for the alternative api?

At the moment the only renderer which produces output which is suitable for printing is the postscript renderer. I'm working on a pdf renderer but it is not ready. The qt renderer is not good for printing since it draw glyphs as bitmaps while we want to send glyphs as native ps fonts to retain the best quality for the printer resolution.

To finalize this goal you will need to implement the printer_widget function and then we have to modify the texmacs side to provide an access point to this function (for example call it in the edit_main_rep::print_buffer function).

best

max

Regards,

________________
Miguel de  Benito.

_______________________________________________
Texmacs-dev mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/texmacs-dev