Hey Jody, how's everything? I know I've been quite absent over here, but we've actually done some things (just didn't find the time yet to pass them over to you guys).
We've actually detected several bugs/issues, and one of them was exactly this issue that setting an external graphics erases the marks and vice-versa. We've corrected it here (over in GraphicImpl.setExternalGraphics() and setMarks()), but I imagine you've done the same thing over there. My intention was to package things in separate patches, one for each issue, later this week. I'll send a separate e-mail with the list of issues we've detected (the idea is to send one patch for each issue later on). Cheers Milton Andrea Aime wrote: > Jody Garnett ha scritto: >> Thanks for the hunting; this is where I have fun and go check the >> specification -see if we are allowed marks and external graphics at the >> same time. >>> If the Graphic element is omitted from the parent element, then >>> nothing will be plotted. The Mark element is defined and discussed below. >>> Graphics can either be referenced from an external URL in a common >>> format (such as GIF or SVG) or may be derived from a Mark. Multiple >>> external URLs and marks may be referenced with the semantic that they >>> all provide the equivalent graphic in different formats. The “hot >>> spot” to use for positioning the rendering at a point must either be >>> inherent in the external format or is defined to be the “central >>> point” of the graphic, where the exact definition “central point” is >>> system-dependent. >>> >>> The default if neither an ExternalGraphic nor a Mark is specified is >>> to use the default mark of a “square” with a 50%-gray fill and a black >>> outline, with a size of 6 pixels, unless an explicit Size is >> Here is the schema: >> <xsd:element name="Graphic"> >> <xsd:complexType> >> <xsd:sequence> >> <xsd:choice minOccurs="0" maxOccurs="unbounded"> >> <xsd:element ref="se:ExternalGraphic"/> >> <xsd:element ref="se:Mark"/> >> </xsd:choice> >> <xsd:sequence> >> <xsd:element ref="se:Opacity" minOccurs="0"/> >> <xsd:element ref="se:Size" minOccurs="0"/> >> <xsd:element ref="se:Rotation" minOccurs="0"/> >> <xsd:element ref="se:AnchorPoint" minOccurs="0"/> >> <xsd:element ref="se:Displacement" minOccurs="0"/> >> </xsd:sequence> >> </xsd:sequence> >> </xsd:complexType> >> </xsd:element> >> >> So my understanding of this is that we should have multiple external >> graphics and/or marks; but the the first one that is understood should >> be used? So perhaps you could have an order like: >> - svg >> - png >> - gif >> - mark >> >> What do you think? > > By spec, as far as I remember, they have to be tried out in the > order they are defined, the first that can be used wins. There is > no format hierachy. > What is the intention of the patch to the renderer you just committed? > > Cheers > Andrea > -- Milton Jonathan Grupo GIS e Meio Ambiente Tecgraf/PUC-Rio Tel: +55-21-3527-2502 ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
