From: j.m.maurer (firstname.lastname@example.org)
Date: Tue Jul 30 2002 - 09:04:31 EDT
On Tue, 2002-07-30 at 14:45, Tomas Frydrych wrote:
> Hi Martin,
> > In my opinion this is part of the way to go but not the whole way. We
> > want to support background images at all levels. From shading in
> > paragraphs to images that cover a whole page. The only to do this
> > successfully is for each run to paint the SEGMENT of the image it
> > covers. So the runs should the paint the image on information provided
> > by it's container.
> It seems to me that what we need is this (on further thought I do not
> like this approach any more, better suggestion is to follow):
> When a run is to draw its bacground, it will check its bacground
> colour and if it is trasparent, it will call drawBackgroundRegion() of
> its parent container, otherwise it will draw with its background colour.
> The fp_Container::drawBackgroundRegion() will do the same: check
> its bacground colour, and if it is not trasparent or image, it will draw
> the region (using _drawBackgroundRegion()), otherwise it will call
> drawBackgroundRegion() of its parent container, and so on.
This approach seems to be exactly what I proposed, and which martin did
not agree on (it was exactly the *opposite*). Can you explain what are
the advantages of your approach over this one martin? (sorry for me
being dumb, just trying to learn).
> The other, I think much better, option would be to use a similar
> mechanism as the current updateBackgroudColor(), but extended it,
Isn't the first appoach a _much_ more general one? This second approach
only allows for images as a background, not an arbitrairely(?)
background. If this is the case, I would go for the first one and try to
implement it as good as possible, so we are not held back in the futute
when we want to implement more advanced layout stuff.
This archive was generated by hypermail 2.1.4 : Tue Jul 30 2002 - 09:10:21 EDT