Re: xpdf status ... yet another day.

[Federico Mena Quintero <federico redhat com>]

>      Now, how this interoperates with the zoom factor.  The container
>  can ask the component (often when I say "component," I really mean
>  "one of the GNOME::View interfaces of a server exporting the
>  GNOME::Embeddable interface.") to change its current zoom factor.  The
>  component should change the zoom factor, but in order to accomodate
>  this change, will probably need to increase its in-place size.  It
>  should do this with gnome_view_request_resize().
>  
>      Note that the whole view-factor thing starts to blur the line
>  between Bonobo document embedding and Bonobo conrols: Should the
>  zoom-factor affect printing?  Should it be saved in the compound
>  document along with the rest of the data?  How do we represent it in a
>  moniker?

There are two separate things here.

	1. The coordinate space in real world units.

	2. The coordinate space of views.

(1) is the *only* thing that should be stored in files.  I.e. your
file will say, "I am a word processor document and the user has
embedded a chart component at (50, 60) millimeters, with size (100,
75) millimeters.

Size negotiation should be done with respect to (1), I think.  This is
so that parents know where they can place children in the real world's
coordinate space.  As far as (2) is concerned, screen sizes and
coordinates can be computed from the results of (1).

So the process would be something like

	a. Parent asks children for sizes in real world units.

	b. Parent sizes children to whatever is appropriate.

	c. Parent tells children to update their views at
	   such-and-such sizes, in *pixel* units.

(b) is so that children know how big they are in the real world.  (c)
is for display purposes only.

  Federico