Hi Jason,
I apologize for not responding sooner - I just got back from vacation.
The existing PrintLayout schema is very rigid, and very limited. The intention in creating a new schema (and a new service to support creation and management of the corresponding resources) is to provide a solid foundation for printing and plotting that is capable of supporting a wide variety of graphical objects (maps, north arrows, scale bars, various types of adornment, annotations etc.) and to be applicable in as many environments as possible, including both desktop applications and web applications (so some settings may not be applicable in all environments).
The most important thing in the design of the schema is to ensure that it can be used in the future as the single underlying format for essentially anything that we want to print or publish, and I believe that should include basic printing, DWF export, HTML, PDF etc. The idea of using it as the basis for web layouts has also come up, though I think that may introduce a level of complexity that would interfere with its overall usefulness (not to mention the vast amount of work that would be required to something like the Fusion framework to make that actually happen).
So, to answer one of your questions - I would love to see this replace the use of MgLayout and MgPlotSpecification in the mapping service. And I also think it would be great to have some kind of generic publishing service to output these layouts in a variety of formats. There would certainly be a lot of work involved in achieving these goals, and I'm not sure that the MGOS community has the resources to address them in the short term. But I feel that it is important to do everything we can to ensure that the print layout schema and service design provides the necessary base functionality to enable the achievement of these goals in the future.
Thank you very much for your previous comments, by the way - I'm in the process of updating the proposed schema to address the issues that you raised.
In a separate email you raised a concern about the recent submissions against the as-yet-unapproved RFC. The purpose of these submissions was to allow collaboration between various developers at remote sites, allowing them to gain access to, and to build upon the underlying print-layout-related classes. The classes in question are essentially isolated from the rest of the MapGuide code base, and any APIs they contain are internal. So there is very low risk of their introducing any destabilization. I appreciate that in order to conform strictly to the open source development process, these submissions should not have occurred prior to the final approval of the RFC, or should have been made in a sandbox project. Unfortunately, by delaying the collaboration process, or by adding the additional overhead of updating the build processes and related projects to reference a sandbox, the entire development on this feature would have been jeopardized. The code submitted so far should be considered an initial revision, and will be updated as necessary to reflect changes that stem from the review of the RFC. If you still have concerns over the presence of this code in the subversion vault, please let me know.
Thank you again for your help in ensuring that we design this the right way!
Cheers,
Chris.
-----Original Message-----
From:
[hidden email] [mailto:
[hidden email]] On Behalf Of Jason Birch
Sent: Monday, June 22, 2009 9:50 PM
To: MapGuide Internals Mail List
Cc: Reva Revadigar
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.
________________________________________
From: Bruce Dechant [
[hidden email]]
Sent: Monday, June 22, 2009 1:54 PM
Subject: [mapguide-internals] MapGuide RFC 67 - Common Print Layout and Print Layout Elements ready for review
Please review MapGuide RFC 67 - Common Print Layout and Print Layout Elements.
http://trac.osgeo.org/mapguide/wiki/MapGuideRfc67_______________________________________________mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
