ms_newMapObj('') does not create the default outputformats

[bear@…]

ms_newMapObj('') does not create the default outputformats, however
ms_newMapObj('test.map') does, even if test.map has only one line ('END').

[jlacroix]

First problem, the msPostMapParseOutputFormatSetup() function that create all
the default output format, is call when the END of the mapfile is encountered
and there's no format declared. Second problem, the mapscript.i loadMap function
call initMap() if the file has a size of zero.

To solve this problem, we can move the format declaration in mapscript, but if
we want to create mapObj anywhere else we would have to always keep the format
declaration. 

Or we can put the format declaration in the initMap() function. But I think the
goal of initMap() is to set all value to zero. As a side effect, this way will
prevent mapserver from losing default formats if we create one format and this
implied to parse existing format to have a way to overwrite the default value.

[dmorissette]

I would like to always create the default output formats even if the mapfile 
contains at least one output format.  Any format with the same name defined in 
the mapfile would take precedence of course.  (Right now if the mapfile contains 
one output format defn then none of the default output formats are created.)

This would allow us to more easily fix this bug with the creation of an empty 
mapObj in memory, and would prevent the annoying side effect that happens if you 
create a custom output format for SWF for instance, and then you lose all the 
default output formats for GD image types that used to be available by default.

Any objections with this change?

[fwarmerdam]

I think this change would be fine. 

[jlacroix]

All default output format are now created with mapscript even if output format
are specified. For this I created a new function in mapfile.c (called by
mapscript), msNewMapObj() that call initMap and
msPostMapParseOutputFormatSetup(). Mapscript call this function if there's no
mapfile specified with ms_newMapObj().

I also create a new driver for the 24bit png. GD/PNG24. I don't close the bug as
docuentation for this new driver is not update.

[fwarmerdam]

Julien / Daniel, 

I have redone some of the work in mapoutput.c.  Some issues where:

 o Daniel's addition of PNG24 support would produce an extra, potentially 
   unreferenced, PNG24 outputFormatObj if msCreateDefaultOutputFormat()
   was called from elsewhere with "GD/PNG" as the driver (which it is). 

 o Julien's logic put all the testing for existing drivers in
   msCreateDefaultOutputFormat(), instead of msApplyDefaultOutputFormats() 
   which would break stuff that tries to create alternate outputFormatObj's for
   the given drivers. 

 o The changes resulted in outputFormatObjs with odd driver names 
   like "GD/PNG24" which is not legitimate.  Instead there should be two
   outputFormatObj's with the driver "GD/PNG", one named "png" with 8bit
   characteristics, and one named "png24" with 24bit characteristics. 

The key to remember is that msCreateDefaultOutputFormat() is not just for
creating the default list attached to a map.  It is also used anytime someone
creates an outputFormatObj.  The idea is they create a default one, and then
modify the parameters of interest. 

I have modified some of the autotests to verify that:

 o The "PNG24" format is being created, and operates in 24bit mode. 
 o The default formats are created even if the user defines custom formats. 
 o The users custom format definitions will be used in preference to any
   default format definitions. 

I encourage you to review the current mapoutput.c code and ensure it does what
you need.  Thanks for ensuring he ms_newMapObj() aspect works properly now. 

[dmorissette]

Sorry about the mess, and thanks for fixing it.  I made a few tests and the 
formats are still created by default, including the PNG24 format when GD2 is 
available.

Marking bug as fixed.