Setting map->transparent through mapscript has no effect

[tbonfort]

Reporter: dmorissette Date: 2004/10/20 - 01:01

This issue was raised in bug 425, but it deserves its own bug.

The problem is that setting map->transparent=MS_TRUE in MapScript doesn't result
in a transparent image. After a review of mapfile.c, I see that we should call
msPostMapParseOutputFormatSetup() after any change to map->transparent,
map->interlace and map->imagequality.

Calling selectoutputFormat() from MapScript might do, but I'm thinking of adding
a call to msPostMapParseOutputFormatSetup() in msPrepareImage() to make sure
we're covered in all possible cases.

Frank, do you see any problem with me adding a call to
msPostMapParseOutputFormatSetup() in msPrepareImage()?

[tbonfort]

Author: dmorissette Date: 2004/10/20 - 01:02

Adding Sean to CC as this may have affected SWIG MapScript as well.

[tbonfort]

Author: fwarmerdam Date: 2004/10/20 - 05:50

Daniel, 

While I can't see any obvious problem with it, I have to admit it makes
me nervous to call msPostMapParseOutputFormatSetup() in msPrepareImage(). 
To my mind we should be deprecating the use of the mapObj transparent,
interlace and imagequality  values in favour of direct and explicit changes
to the outputFormatObj itself.  I only retained them for backward compatibility.

OK, looking at the code msPostMapParseOutputFormatsetup() calls
msApplyDefaultOutputFormats() which is relatively expensive and there might be
some slight chance of it gumming up stuff in some circumstances.  

...

Looking through the WMS code, it seems to me that making the change you are
suggesting in msPrepareImage() would cause the map->transparent flag to 
override a TRANSPARENT setting in a WMS GetMap request.  The GetMap request
essentially prepares an outputFormatObj to reflect the GetMap and sets it on
the mapObj assuming it will survive through the msDrawMap() call.  The WMS
code does capture the format name in map->imagetype, but it doesn't try to 
put the transparent flag in mapObj->transparent.  You might be able to work
around this by settig mapObj->transparent to the transparent flag from the
GetMap request. 

But my general concern is that the approach I took with map->outputformat was
that higher level callers could take steps to cause the map->outputformat
to match desired parameters and then proceed with a render in confidence that
it wouldn't be switched around under the covers. 

My preference then would be to have any change to the map->transparent, 
map->interlace or map->imagequality flags from MapScript result in an
immediate call to:

  msApplyOutputFormat( &(map->outputformat), map->outputformat, 
                       map->transparent, map->interlace, map->imagequality);

That is, reapply the "current" outputformat, but ensure the current state
of these override flags is applied.  

Now, you might turn around and tell me that the attribute set methods in
PHP and other mapscript implementations can't easily do extra actions like 
this.  If so, that really sucks and means I think we have painted ourselves
into a corner with all this direct manipulation of objects from mapscript. 
If you can do it, then we are good. 

But, furthermore, I would like to deprecate all use of these three overide
flags in favour of direct manipulation of outputformats.  That is, I would
like the overrides to keep working, but for them to be dropped from all
documentation and discouraged. 

How is that for an earful!

[tbonfort]

Author: sgillies@frii.com Date: 2004/10/20 - 16:38

I've also been instructing users to program using named output formats
rather than changing the map attributes.  This is the way Jan should
be working, and so I think a documentation change and change of use
is needed rather than new code.

[tbonfort]

Author: dmorissette Date: 2004/10/21 - 00:11

I agree with deprecating the map attributes and encouraging use of the
outputFormatObj instead. Unfortunately the outputFormatObj is read-only in PHP
so if we deprecate them then we have no alternate way to operate. 

I have created bug 979 about sync'ing the PHP outputFormatObj with the SWIG
version, making it a blocker for the current bug.

[tbonfort]

Author: fwarmerdam Date: 2004/11/15 - 19:38

Is there any conclusion to this bug report?  Are we changing anything for 4.4?

[tbonfort]

Author: assefa Date: 2004/11/15 - 19:46

We are going to make the Outputformats settable through PHP for 4.4 and add a
note on this in the docs. I think It would be enough for this release.

[tbonfort]

Author: dmorissette Date: 2007/08/08 - 20:19 The members of outputFormatObj are already settable in the current implementation of PHP MapScript. And the mapObj transparent, interlace, imagetype and imagequality have already been marked as deprecated in docs.

We just can't create a new instance of outputFormatObj from scratch, which is the topic of #979.

However we can make changes to the mapObj.outputformatobj so we can mark this fixed.