[Gnome-print] Re: GnomePrintSettings

[Chema Celorio <chema celorio com>]

Lauris Kaplinski wrote:
...............
> > do everything below that node. So the app would do something like :
> >
> > node = xmlNewChild (node, gmr, "PrinterSettings", NULL);
> > if (!gnome_print_settings_xml_write (node))
> >        return NULL;
> 
> 1. Better to give _write toplevel settings node (not parent) - gives us
> cleaner structure for handling options partially by app, partially by gpa.
> 2. There should be a way to ask writing per key ("paper", "color", etc.)
> in case application is not interested in embedding full printer
> specification (location etc.).

ok

> I.e. the generic rule about gpa stands - you can get/set/interpret all
> setting in gpa manually if you know the keys. Some of the keys are
> generally known (like paper size etc.), some are meaningful only to
> gpa/gnome-print library internals.

ok.

> 
........
> > layouts for this widgets. One can set a Paper Size that includes a Visual
> > representation of the  paper, or the orientation in a GtkOptionMenu or
> > GtkRadio buttons etc..
> 
> Hmmm...
> Why not to use gtktypes here.
> I.e. gnome_print_settings_new (GtkType type, gps);
> And every _settings widget should simply implement
> ::build (GPSWidget * w, GnomePrintSettings * gps)
> class method for initialization.
> This would compact API a lot - we will have on single public
> get_type () method per widget class and very common few base methods.
> Everything else can be private.

I am not sure what you mean by this.

Because the GnomePrintSettings object, is NOT
a Widget at all. One thing is the GnomePrintSettings object
and another one the GnomePrintSettingsWidget (which goes
on the dialog). Apps may use the GnomePrintSettings without
having to use their widgets, (the widgets will be created
by gnome-print-admin).

> 
> > When the app prints
> > ===================
> > Since the App no longer handles print orientaion/Paper Size. Before it
> > prints it queries gnome-print for the print Bounding Box (margins
> > substracted / margins NOT substracted ). With :
> >
> > void     gnome_print_get_print_bbox (GnomePrintContext *pc,
> >                                      gboolean substract_margins,
> >                                      gdouble *widht,
> >                                      gdouble *height);
> >
> > (do we need the substract margins ??? )
> >
> > The substract_margins is a flag to get the Page size, v.s. the printable
> > size. I am not sure we need this, but there needs to be a way for the
> > app to get the area in which it can actually draw inside the paper.
> 
> Wait...
> Why to handle that through PrintContext at all? After all PrintContext
> is simply a driver and cannot know anything more than gps already does
> about printer/page/... capabilities.

ok. We can also get the bbox from the GnomePrintSettings object.

> I would instead use:
> ArtDRect pgrect, vrect;
> gnome_print_settings_get (gps, "page-size", &pgrect, "printable-size",
>   &vrect, NULL);
> gdouble affine[6];

Hmm. I am not sure we want to get settings like this.
I would prefer having specific functions for gettting
info from the GnomePrintSettings. 

I would go more for something like :

gnome_print_settings_get_page_size (gps, &pgrect);
gnome_print_settings_get_printable_size (gps, &vrect);
gnome_print_settings_get_raster_transform (gps, affine);

> gnome_print_settings_get (gps, "raster-transform", affine, NULL);
> to get the actual affine transform from base page (72dpi) coordinate
> system to actual output pixel coordinate system.
> NB! Getting only dpi_x and dpi_y is not sufficent for specific raster
> output contexts, where we are actually interested in pixel boundaries.


Chema