[mapserver-dev] SVG Metadata

Yewondwossen Assefa yassefa at dmsolutions.ca
Mon Nov 9 08:37:33 EST 2009


Thomas,

 That sums up well the state of things. My hope would be to only have 
one option viia cairo for svg/pdf outpupt, so we can realistically 
maintain them in a long term. After the 5.6 release, I will spend a bit 
more time on it and see what would we "loose" by dropping the current 
implementation.

regards,

Thomas Bonfort wrote:
> Hi,
> first off, Assefa correct me or intervene if you see things
> differently, I'm far from claiming having an authoritative role on
> this.
>
> the status of the svg renderer is far from set in stone right now. we
> have essentially three options for the future of the svg renderer:
>
> * drop the current svg implementation and replace it completely with
> the cairo provided one:
>   - advantages: support comes "for free" via the cairo library, as the
> code is essentially the same whatever cairo backend is used
>   - inconveniences: no flexibility as to the form the svg can be
> produced in. your problem is typically concerned here
>
> * port the current svg rendering code to the new rendering architecture:
>   - advantages: support of the future enhancements rendering-wise will
> be "automatic", and this approach allows some liberty in adding extra
> features to the output result (as in your present case)
>   - inconveniences: need to find resources to do the actual port and
> maintain it.
>
> * keep the current svg and cairo implementations in parallel (which
> will probably be the state during the transition) :
>   - advantages and inconveniences derive from above. maintenance
> effort to keep the current svg code updodate featurewise is incertain
> due to lack of resources.
>
>
> so, no real answers to give you concerning your actual problem, but at
> least here is some info to help you make your choice.
>
> regards,
> thomas
>
> ps: if you want to volunteer to help on the subject, please don't refrain ;)
>
> www.camptocamp.com
> +33 5 16 57 01 02
>
>
>
> On Sat, Nov 7, 2009 at 21:28, florent beauchamp <flo850 at free.fr> wrote:
>   
>> Hi,
>>
>>   I'm trying to produce interactives maps with SVG and Javascript and I found
>> the bug 1546, still open.
>>
>>   For this, I need to associate the svg objects to the corresponding
>> geographical object.
>>
>>   On one hand, I'm able to modify mapsvg.c, with something similar to
>> SWFDUMPATTRIBUTES.
>>   On the other hand, it seems that this file will be deprecated for the 6.0
>> release and the cairo renderer.
>>
>>   I asked the cairo mailing list, looking for a way to transmit the id
>> attribute. The answer is clear : there's no way to do this in the current API.
>> Moreover, I found that the SVG renderer of cairo is not as good as the current
>> one, especially for the text rendering (each char is an individual object)
>>
>>   What will the current svg renderer become in the future release ?
>>
>>   Is it usefull to modifiy mapsvg.c to handle this, or should I find a
>> workaround ?
>>
>> Regards
>>
>> Florent BEAUCHAMP
>> _______________________________________________
>> mapserver-dev mailing list
>> mapserver-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>>
>>     
>
>   


-- 
----------------------------------------------------------------
Assefa Yewondwossen           
Software Analyst   

Email: assefa at dmsolutions.ca    
http://www.dmsolutions.ca/

Phone: (613) 565-5056 (ext 14)
Fax:   (613) 565-0925
----------------------------------------------------------------




More information about the mapserver-dev mailing list