Re: handling background images

From: j.m.maurer (j.m.maurer@student.utwente.nl)
Date: Tue Jul 30 2002 - 09:04:31 EDT

  • Next message: Jordi Mas: "Commit: Paste BMP support under win32"

    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):
    >
    > fp_Container::_drawBackgroundRegion(x,y,width,height);
    > fp_Container::drawBackgroundRegion(x,y,width,height);
    >
    > 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,

    [snip]

    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.

    Marc



    This archive was generated by hypermail 2.1.4 : Tue Jul 30 2002 - 09:10:21 EDT