<html>
<head>
<style type="text/css">
<!--
body { margin-top: 4px; line-height: normal; margin-left: 4px; margin-bottom: 1px; margin-right: 4px; font-variant: normal }
p { margin-top: 0; margin-bottom: 0 }
-->
</style>
</head>
<body style="margin-top: 4px; margin-left: 4px; margin-bottom: 1px; margin-right: 4px">
<p style="margin-top: 0; margin-bottom: 0">
<font face="Comic Sans MS" size="3">All,</font> </p>
<br>
<p style="margin-top: 0; margin-bottom: 0">
<font face="Comic Sans MS" size="3">Ok, looking through it. . . .BTW, I'm looking at things with respect to PDF output (Including 3D models eventually).</font> </p>
<br>
<p style="margin-top: 0; margin-bottom: 0">
<font face="Comic Sans MS" size="3">Comments on Spec:</font> </p>
<br>
<p style="margin-top: 0; margin-bottom: 0">
<font face="Comic Sans MS" size="3">* Should "DPI" be considered a valid INIT type for resolution? Wouldn't px, em or ?? fit better?</font> </p>
<p style="margin-top: 0; margin-bottom: 0">
<font face="Comic Sans MS" size="3">* Should "width / height" really be "X / Y / (Z)" ?</font> </p>
<p style="margin-top: 0; margin-bottom: 0">
<font face="Comic Sans MS" size="3">* Don't know that the "mapframes" container is needed. Just process each "mapframe" inside of "mapframes" no matter what.</font> </p>
<p style="margin-top: 0; margin-bottom: 0">
<font face="Comic Sans MS" size="3">* Are unique "SECTION name=" defaulted to requiring unique values, should NAME be moved out of PARAM status? For more than one Section of type "LAYOUT" for example.</font> </p>
<p style="margin-top: 0; margin-bottom: 0">
<font face="Comic Sans MS" size="3">* Mapframe Stacking isn't accounted for (z order) for more than one MapFrame, might want to display on mapframe partial over another. Could get away with sending a polygon instead of width / height - X / Y, although that would get messy quick Might have to bite the bullet there though. Another use for this, would be to print out a result on top of a template that might already contain a MAPFRAME of the same name. The stacking would become needed in this situation too I think. Over or under the template?</font> </p>
<p style="margin-top: 0; margin-bottom: 0">
<font face="Comic Sans MS" size="3">* I'm lost on the mapframe>scale value, what to what, relative to what? Should the unit size be passed in for the Model_space_position as well to make this work?</font> </p>
<p style="margin-top: 0; margin-bottom: 0">
<font face="Comic Sans MS" size="3">* Should mapframe properties be referenced to a mapframe like : <map_frame_properties mapframe="Main Map Frame"></font> </p>
<br> <br>
<p style="margin-top: 0; margin-bottom: 0">
<font face="Comic Sans MS" size="3">Suggested additions:</font> </p>
<br>
<p style="margin-top: 0; margin-bottom: 0">
<font face="Comic Sans MS" size="3">* Set up more than one Map view in this example . . . Will help with referencing question I have above.</font> </p>
<p style="margin-top: 0; margin-bottom: 0">
<font face="Comic Sans MS" size="3">* Captioning for Mapframes.</font> </p>
<p style="margin-top: 0; margin-bottom: 0">
<font face="Comic Sans MS" size="3">* Stat's block, for outputting in text form, the descriptive elements of the print.</font> </p>
<p style="margin-top: 0; margin-bottom: 0">
<font face="Comic Sans MS" size="3">* There was mention of adding in the Time of day to the date, I would second this.</font> </p>
<p style="margin-top: 0; margin-bottom: 0">
<font face="Comic Sans MS" size="3">* Add metadata sub section to each layer.</font> </p>
<br> <br>
<p style="margin-top: 0; margin-bottom: 0">
<font face="Comic Sans MS" size="3">bobb</font> </p>
<br> <br><br>
<p style="margin-top: 0; margin-bottom: 0">
<br>
>>> "Landon Blake" <lblake@ksninc.com> wrote:<br> </p>
<div style="margin-top: 0; margin-bottom: 0; margin-left: 15px; padding-left: 7px; background-color: #f3f3f3; margin-right: 0; border-left: solid 1px #050505">
<p style="margin-top: 0; margin-bottom: 0">
I don't think that is the most current XML file. Try the attached.<br><br>Landon<br>Office Phone Number: (209) 946-0268<br>Cell Phone Number: (209) 992-0658<br><br><br>________________________________________<br>From: carto-bounces@lists.osgeo.org [mailto:carto-bounces@lists.osgeo.org] On Behalf Of Bob Basques<br>Sent: Monday, May 03, 2010 11:02 AM<br>To: carto@lists.osgeo.org; Tyler Mitchell (OSGeo)<br>Subject: Re: [Carto] Requesting Tentative Consensus on MRI FileFormat- Version 0.12<br><br>Is this the latest stuff being talked about?<br><br><a href="http://lists.osgeo.org/pipermail/carto/attachments/20100412/a894c7f6/mri_stripped_version_0">http://lists.osgeo.org/pipermail/carto/attachments/20100412/a894c7f6/mri_stripped_version_0</a>-11-0001.xml<br><br><a href="http://lists.osgeo.org/pipermail/carto/attachments/20100412/a894c7f6/MRI_Changes">http://lists.osgeo.org/pipermail/carto/attachments/20100412/a894c7f6/MRI_Changes</a>-0001.obj  (really a PDF . . .)<br><br><br>>>> "Tyler Mitchell (OSGeo)" <tmitchell@osgeo.org> wrote:<br>On 05/03/2010 10:23 AM, Landon Blake wrote:<br>> We could certainly define "dynamic" components using proportions and<br>> anchoring, but that will increase the complexity of the map rendering<br>> engine quite a bit. I'd prefer to see that done in the prior step by<br>> a nother program in the tool chain.<br>><br>> That just my opinion though.<br><br>I sure agree.  Anything that has a user interface can be considered<br>slightly off-topic for now at least.  The hope is to solidify an XML<br>specification and then let others build to the specification.<br><br>Of course, once we have it settled, then I'm sure several of us will<br>want to try various approaches and report back here :)<br>_______________________________________________<br>Carto mailing list<br>Carto@lists.osgeo.org<br><a href="http://lists.osgeo.org/mailman/listinfo/carto">http://lists.osgeo.org/mailman/listinfo/carto</a><br><br><br>Warning:<br>Information provided via electronic media is not guaranteed against defects including translation and transmission errors. If the reader is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this information in error, please notify the sender immediately.
</p>
</div>
</body>
</html>