Advanced symbols in comparison with other Esri APIs with regard to printing

Question

Hello,
please take this as a suggestion and/or a feature request. I would greatly appreciate if someone from Esri could provide some insight as to whether there are any plans to address the following issue in a future release.

Symbols in the current (3.0) Silverlight API do not support the whole set of properties defined in the REST API symbol objects specification. One example of this is Angle on marker symbols and text symbols. It seems that the other APIs, such as Esri Javascript API, do support these properties, e.g. the esri.symbol.TextSymbol has angle, rotated, align properties, among others.

Now, in Silverlight, one can add rotation and other capabilities to, say, a text symbol by adjusting the control template. This works in most cases, except it is extremely clumsy and overly complicated. It seems to me the symbol API in Silverlight should be on par with other Esri APIs in which these capabilities are supported.

More importantly, the current implementation prevents us from taking advantage of the new PrintTask capabilities. Since TextSymbols do not have rotation properties, they are naturally not serialized to JSON sent to the print service, event though they are supported by the REST API. The resulting document is thus of course rendered incorrectly. The problem pertains not only to TextSymbols, but other symbol types as well.

This makes it impossible to use the print service in more advanced scenarios. Constructing the JSON ourselves from scratch is not really an option since nearly all of the JSON serialization code is internal and cannot be easily reused or adjusted.

Is there a chance this will be fixed in a near future?

Thanks,
Petr Krebs

JenniferNery · Answer

TextSymbols are supported. You can try the following code-snippet: xmlns:esri="http://schemas.esri.com/arcgis/client/2009">

HyrumErnstrom · Answer

On Custom Symbols you can implement a IJsonSerializable to create your own .toJson method. This should allow you to add your own json values to send to the print. Since the TextSymbol doesn't have a angle property there is no reason for the default toJson to have one.