#2195 closed defect (fixed)
AGG and output formats
Reported by: | assefa | Owned by: | sdlime |
---|---|---|---|
Priority: | normal | Milestone: | 5.0 release |
Component: | AGG | Version: | |
Severity: | normal | Keywords: | outputformat |
Cc: | warmerdam |
Description
There are few drivers dified in mapoutput.c for AGG such as AGG/PC256, AGG/GIF, AGG/PNG, AGG/PNG24 AGG/JPEG AGG/WBMP. Do we intend to support all of these. Those that really work right now are AGG/PNG24 (or AGG/PNG with IMAGEMODE "RGB" or) and AGG/JPEG.
I think we should clean this up and have only AGG/PNG24 and AGG/JPEG. Having AGG/PNG with imagemode is kind of confusing.
We should also add the creation of the AGG/PNG24 and AGG/JPEG as part of the default formats so that we can use the imagetype agg/png24 and agg/jpeg without defining an outputformat in the map file.
Change History (9)
comment:1 by , 17 years ago
comment:2 by , 17 years ago
Yes, that makes good sense. Frank, I see you've taken ownership. That's fine. Let me know if you'd like me to make the changes.
Steve
comment:3 by , 17 years ago
Keywords: | outputformat added |
---|
Steve,
I didn't actually take ownership - it is still assigned to you. But to expedite things I have committed an updated mapoutput.c (r2195) that removes the not-sensible agg/ options and that, by default, registers output formats named "aggjpeg" and "aggpng24". Note that the names of the output formats can't conflict with the gd cases so output format "jpeg" will use driver "GD/JPEG" while output format aggjpeg will use driver "AGG/JPEG".
I presume that till now folks have been explicitly declaring their AGG outputformat blocks, right? If so, the existing agg maps should continue to work normally.
Could one of you confirm that this is working fine and close the ticket?
comment:4 by , 17 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Actually, I've added a quicky test of aggpng24 output in msautotest (msautotest/misc/agg_poly.map) and it seems to work fine. Closing...
comment:5 by , 17 years ago
What do you think about retaining the / in the name? (e.g. agg/png24) A trivial point but it will set a standard. Personally I like a seperator between the driver and the format. We could create gd/gif, gd/png, gd/png24, etc... as well...
Steve
comment:6 by , 17 years ago
Steve,
There are two things in play here. The output format name and the driver name used with it. So the driver names are things like "AGG/JPEG" and "GD/GIF" but the output format names are things like "gif" and "aggjpeg". So aggpng24 and aggjpeg are outputformat names, not driver names. The outputformat name is the name you would put after the IMAGETYPE keyword.
comment:7 by , 17 years ago
Yes, I know. I like the seperation in the format names (e.g. IMAGETYPE) too. The format name AGG/PNG24 just refers to the default format using the AGG/PNG driver. In hindsight I would thing that in an outputformat block we should have split driver into driver and format (e.g. DRIVER AGG, FORMAT PNG)...
Steve
comment:8 by , 17 years ago
I'd be concerned about having slashes in output format names. Since the output format name is an identifier (it can be used unquoted in places like IMAGETYPE) I don't think it can have special characters like a slash in it.
comment:9 by , 17 years ago
Just to add a note that AGG/PNG is the driver and AGG/PNG24 would not work.
From what I see I agree with Assefa's assessment and suggestion.