[mapserver-dev] SVG Metadata

[flo850 at free.fr]

Hi, 

     As far as I understand the way cairo generate SVG, the  main difference with the current svg rendering engine is the way cairo render text.

     In the current engine, a text object contains the entire label(mapsvg.c,line 1000). 
     That way,  the font rendering is done client side. It can drive to inconsistency if the font is not installed on the user system but the server cost is extremely low.
     It's not possible to draw a FOLLOW label for directly, but it seems  possible to make it with the svg element textPath, granted we can know the object referenced by a label.
    
     In the cairo engine, teh label is drawn serverside : each glyph is rendered either as a path or a symbol (cairo-svg-surface.c _cairo_svg_document_emit_font_subset call  _cairo_svg_document_emit_glyph for each glyph ) . That way, there can't be any problem of non existent font  on the user system. On the other hand, the semantic of the label is lost. 

     regards,

----- Mail Original -----
De: "Yewondwossen Assefa" <yassefa at dmsolutions.ca>
À: "Thomas Bonfort" <thomas.bonfort at camptocamp.com>
Cc: "florent beauchamp" <flo850 at free.fr>, mapserver-dev at lists.osgeo.org
Envoyé: Lundi 9 Novembre 2009 14h37:33 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne
Objet: Re: [mapserver-dev] SVG Metadata

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
----------------------------------------------------------------