[mapguide-internals] Review RFC 108 - support Watermark

[Tom Fukushima]

Jason,

I'll wait for updates to the RFC before replying to some items below.  

With respect to the "Watermark requirements are generally pretty simple" statement; that's true for simple copyrights statements; but for anyone who wants a more professional looking map with, for example, some branding, then a full-fledged vector-based symbol is required and defining it in XML is a pain.

Images do not make good watermarks because they do not print well.

Tom

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: Friday, July 30, 2010 8:30 PM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] Review RFC 108 - support Watermark

Watermark requirements are generally pretty simple, text or image.  I can't
imagine that adding an incredibly simple WaterMark editor that only places
those types into a SymbolDefinition would be too hard, and that folks with
more more complex requirements would be unable to hand-craft the XML in
those cases.

I wasn't questioning the need for an external watermark definition, just the
need for a dedicated resource type for it.  Could the MapDefinition schema
and LayerDefinition WMS header information be updated to point to an
appropriate resource, along with whatever additional positional
information/overrides required?  So add a <Watermark /> entity to the
MapDefinition which contains the symbol definition's ResourceID along with
positional preference (TL, T, TR, L, C, R, BL, B, BR), and dimension/scale
overrides.

I'm assuming that you'd need positional preference rather than precise
placement due to the possible need to stack WaterMarks?  Does the WaterMark
need its own Opacity too?

I'd prefer not to make assumptions about whether DWF was weighed against
SymbolDefinition, and would like to hear whether there is still some
potential to reconsider this decision. If this call is always going to be
made because clients have easy ways of generating DWF symbols, then we're
going to see continued propagation of DWF (which is not under an
OSI-certified license) throughout the code base.  I really, really don't
like this, and would prefer to see the feature deferred if there are
inadequate resources to do it "right" (by my admittedly narrow definition of
right).

Jason

On 30 July 2010 14:06, Tom Fukushima wrote:

> Hi All,
>
> I agree with Jason, Jackie, Trevor,... that SymbolDefinition resources
> should be supported. But I don't think that means we can't also support DWF
> symbols. So I think it should be fine to support DWF now and then not exempt
> ourselves from supporting SymbolDefinitions in the future. (I'm assuming
> that the ADSK team that is working on this has weighed using DWF symbols and
> SymbolDefinitions already and has decided on DWF symbols, and only has the
> development resources for that right now.)  Let me say though, that I'm not
> that keen on propagating the use of DWF symbols in MGOS, and if we had a
> WYSIWYG symbol definition editor somewhere I would be all for
> SymbolDefinitions everywhere.
>
> I wish that the watermark resource could just refer to a DWF Symbol library
> instead of attaching it as DWF symbol data, but I guess this might create a
> pretty unusable UI.
>
> Buddy, I would like to see what the changes to the MapDefinition will be
> for this (XML is API and needs to be documented in the RFC).  Please add
> this to the RFC.
>
> Please also provide the watermark resource schema.
>
> Jason, I was also wondering why a new resource is required, but after
> thinking about it, I think that it will make maintaining a bunch of Maps and
> WMS layers simpler.  Just tweak one place and all other places are adjusted.
> That said, maybe it could be made possible to also allow for inlining the
> watermark specification into the MapDefinition.  If we only had development
> resources for doing one or the other right now, I think I would pick using a
> separate resource; no strong preference here though.
>
> Thanks
> Tom
>
>
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals