Re: [Tcl-soc2008] GSoC 2008

[Clif F. <cl...@cf...>]

Hello Kryzysiek, 

  Thanks for joining us.  I've attached some thoughts about the
Printing project.  I'm going to try to put them into the wiki 
later today.

  One reason that printing support has languished for so many years is
that everyone has a different idea of what's needed, and some of the
underlying features (add a print command to every widget?) become large
and have implications for extension writers.

  I'm certain that my thoughts aren't complete.  They represent what
I'm seeing as customer needs.  I welcome any comments, suggestions or
outright laughter.

  The complete project is likely to be more than a summer's work.
On the good side, there is potential for non-google money to complete
the project.

On Thu, Mar 27, 2008 at 11:31:15PM +0100, krzysztof blicharski wrote:
> my name is Krzysiek Blicharski.
> I'm interested in two projects:
> "Cross-platform framework for database application GUI development based
> on Tcl/Tk + Tile" and "Printing Support".
> I'd like to ask for more information about
> "Printing Support" project - for some further details.
> 
> Moreover, while reading the description of the project,
> a question I came to my mind:
> why such an impotrant project hasn't been realized for 15 years? :)

Clif

One of Tcl/Tk's strong suits is how easy it is to develop complex
graphical applications.  A shortcoming is how difficult it is to get
the information the user sees onto a static representation that can be
sent to others.

Printing support for Tcl/Tk sounds simple.  It's actually a large,
multifaceted problem.  

The three main facets are:
  1) Convert the contents of the Tcl/Tk application to a printable
     format.  This may be Postscript, PDF, Gif, or printer commands.

  2) Transmit the intermediate format data to a printer, interacting
     with whatever facilities are offered by the operating system. 

  3) Code layer interfaces for application developers.  This could
     include adding print subcommands to all Tk widgets, or a print
     subsystem capable of understanding the contents of all widgets.
     
  4) User layer interface that a developer can include in an application
     to give users access to printing.

1. Converting Tcl/Tk data to printable format:

The current Tcl/Tk printing support is limited to generating Postscript
documents from a canvas.  This is solution works well for vector
images, the lines, circles, etc are reproduced accurately for a printer
driver to transfer to paper.  It can work poorly if there is text in
the canvas, as the fonts used on the canvas may not be available to the
printer.

A big advantage for postscript that it's a vector format for
reproducing the image, and is thus very easy to scale the contents
of a canvas to fit a sheet of paper.

Disadvantages for postscript include the font problem and the lack of
general support and potential security problems for postscript images.

The Img extension allows any Tcl/Tk window to be converted to a 
pixel-by-pixel represntation and saved as a .gif image.

The advantage of this is that it provides an exact image of what
the user sees.  Gif images are well understood by most applications
(allowing the contents of a Tcl/Tk canvas to be easily merged into
a Powerpoint or Word document), and the Gif format has fewer security
problems associated with it.

The disadvantages are that the image is a raster image, and scales
poorly.  The Img extension interacts with the screen memory, and can
only render the visible portion of an image.  If the canvas is obscured
by other windows, or is larger than the screen, the conversion to a 
Gif image fails.

There are at least 3 attempts to generate PDF output from Tcl/Tk
windows.  I've developed one, and there are also the Trampoline, Snit,
pdf4tcl and pdfcanvas.  None of these are complete.

A complete solution to the conversion problem needs to include:
  A) Support for all types of Tcl/Tk Windows, not just canvas.

  B) Support for all window options - borderwidth, bordercolor, etc.

  C) Exporting fonts for all textual data

  D) Support for embedded windows

  E) Support for generating raster images to different scales without
     losing resolution

  F) Select a subsection of a window to be rendered.  This will allow a
     huge canvas to be printed to multiple sheets of paper that the
     user can cut and paste together to render mural sized documents.
     (Yeah, it sounds crazy, but even shops with 4' roll printers end
     up needing 8' wide documents some days.)

The ability to generate a PDF output from any window or set of windows,
and/or a PPM, GIF, or PNG output that can be scaled to XxY pixels would
support this phase of the project.

My primary interest in this phase is in generating a PDF or other
vector format output.  If the font problem is truly intractable, then
generating a scaled raster image is a suitable option.

2) This is an area I can't discuss in detail, because I know 
nothing about the API for  Windows and Linux printer drivers.  I know
that if we want a user to be able to click a "Print" button and have
something show up on paper we need more than "exec lpr".  

  A student who is interested in this phase of the project would need to
investigate the Windows API and the Linux and OS/X printing APIs, determine
a common framework, and generate the code to interface with them.

  This phase of the project could be started without the conversion
step by using the currently available export (postscript or Img/Gif) features
of Tcl/Tk.

3) The API to the printing subsystem requires a design document and discussion
with the Tcl Core Team.  It should provide the flexibility to do everything
we understand today, and extend to things nobody knows they need yet.

This facet can be done independantly of the others.  The output document
would be useful to someone developing the first facet (exporting the
Tcl/Tk data) and the fourth facet (developing a user GUI).

This API should support 
  A) scaling the output to a given size in various coordinates (pixels,
     English, Metric, etc).

  B) Rotating the output

  C) Selecting an area of the window to print.
  
  D) Color correction might be useful, depending on what features are
     supported by the printer or printer drivers.

4) A user layer widget will probably be the final piece developed.  It
must allow the user set any of the features supported by the API.  An
additional code snippet to allow a user to easily select the portion of
a canvas to print would be useful.

This is the part of the printing support that will be seen by users,
and thus needs to be well thought out from the HCI perspective. This
will probably be the smallest amount of code when it comes to
implementation.

Nathaniel Borenstein has investigated printing GUI's in the past and may
have some input for a student interested in this facet of the project.



-- 
.... Clif Flynt ... http://www.cflynt.com ... cl...@cf... ...
.. Tcl/Tk: A Developer's Guide (2nd edition) - Morgan Kauffman ..
... 15'th Annual Tcl/Tk Conference:  Oct 2008,  Somewhere, USA... 
.............  http://www.tcl.tk/community/tcl2008/  ............