OSGeo.org › OSGeo Software and Data Projects › MapServer › Mapserver - Dev

SVG Metadata

5 messages

flo850

SVG Metadata

Reply Threaded

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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapserver-dev

Thomas Bonfort-2

Re: SVG Metadata

Reply Threaded

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 <[hidden email]> 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
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>

_______________________________________________
mapserver-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapserver-dev

flo850

Re: SVG Metadata

Reply Threaded

In reply to this post by flo850

I 'm looking further into cairo to integrate svg attributes. If it's too hard for me, I'll give a try to port the svg renderer to the new rendering architecture.

I was wondering : inside : void (*renderGlyphsLine)(imageObj *img,labelPathObj *labelpath,
labelStyleObj *style, char *text);
Is there a way to know the associated object ?

regards

Florent BEAUCHAMP
----- Mail Original -----
De: "Thomas Bonfort" <[hidden email]>
À: "florent beauchamp" <[hidden email]>, "Yewondwossen Assefa" <[hidden email]>
Cc: [hidden email]
Envoyé: Samedi 7 Novembre 2009 22h27:46 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne
Objet: Re: [mapserver-dev] SVG Metadata

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 <[hidden email]> wrote:

_______________________________________________
mapserver-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapserver-dev

Yewondwossen Assefa

Re: SVG Metadata

Reply Threaded

In reply to this post by Thomas Bonfort-2

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 <[hidden email]> 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
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>>
>>
>
>

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

Email: [hidden email]
http://www.dmsolutions.ca/

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

_______________________________________________
mapserver-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapserver-dev

flo850

Re: SVG Metadata

Reply Threaded

In reply to this post by flo850

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" <[hidden email]>
À: "Thomas Bonfort" <[hidden email]>
Cc: "florent beauchamp" <[hidden email]>, [hidden email]
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: