Opened 20 years ago
Closed 17 years ago
#977 closed defect (fixed)
Setting map->transparent through mapscript has no effect
Reported by: | dmorissette | Owned by: | mapserverbugs |
---|---|---|---|
Priority: | high | Milestone: | 5.0 release |
Component: | MapScript-PHP | Version: | 4.3 |
Severity: | normal | Keywords: | |
Cc: | sgillies@… |
Description (last modified by )
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()?
Change History (7)
comment:2 by , 20 years ago
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!
comment:3 by , 20 years ago
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.
comment:4 by , 20 years ago
dependson: | → 979 |
---|
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.
comment:5 by , 19 years ago
Is there any conclusion to this bug report? Are we changing anything for 4.4?
comment:6 by , 19 years ago
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.
comment:7 by , 17 years ago
Description: | modified (diff) |
---|---|
Resolution: | → fixed |
Status: | assigned → closed |
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.
Note:
See TracTickets
for help on using tickets.