[mapguide-internals] MapGuide RFC 67 - Common Print Layout and Print Layout Elements ready for review

[Jason Birch]

It looks like work has gone ahead on this one prior to acceptance; any feedback on my questions?

Jason

-----Original Message-----
From: Jason Birch
Sent: Monday, June 22, 2009 8:50 PM
Subject: RE: [mapguide-internals] MapGuide RFC 67 - Common Print Layout and Print Layout Elements ready for review

I'll reply to the middle one for luck :)

In general, I feel that some parts of this are a bit too tightly bound to client software rather than server software, but perhaps there is some benefit in being able to persist device and media settings on the server side if we ever get a rich client such as Flex or HTML5?  I don't think that we have access to these client settings from the server otherwise.  I also wonder a bit about clarity with this new service having so many overlaps with existing MapGuide funcionality; are any deprecations / rewrites planned?

I jumped the gun a bit while this one was still being formed, and asked a few questions.  These questions and Reva's answers are inline.

- You mention PrintLayout schema and service.  Will the Mapping Service be updated to use these rather than the current combination of programmatic (MgPlotSpecification) and schema (MgLayout) methods?  Is any thought being given to how this could be applied to a generic service that would allow the output of HTML+CSS / PDF / DWF output?

RR: Chris may be better able to answer this

- Are the units for PrintLayout/PaperSize always of a given type (mm?).  If not, should "units" be part of the Size2dType or a separate attribute of the PrintLayout?  The MgPlotSpecification/pageUnits (MgPageUnitsType) exists for this in the mapping service.

RR: Yes, good catch.  The units must be added to the schema.

- Is there a way to add custom graphics (such as a logo)?  I can't find a PrintLayoutElement for this.

RR: Yes, there will be.  It'll be just another PrintLayoutElement.  Note that we have just begin sketching out the base architecture and schema for some of the print layout element types, but haven't thought about all possible kinds of contents yet.  The model, however, is extensible to accommodate these types though.

- Is there a need to store the device name as part of the print definition?  Doesn't this affect the portability of these items?  I think it might be better to maintain the association between a print layout and allowed devices either in a different resource type or at the application level.

RR:  Hmm...interesting.  Yeah, decoupling the device from the print layout might give flexibility with respect to its usage although it'd be hard to determine some of the aspects such as printable area, etc, but maybe that can be handled somehow.

- What does MediaName "the canonical name of the media" mean?  Is there a list of allowed values?  Is this device-specific like the above?

RR:  The canonical media name is the locale-independent name of the media available on the configured plot device.  It'd typically be a list of allowed values such as "Letter", "A4", etc.