Just to clarify, QGraphicsScene by itself doesn't have any particular units. The composer treats scene units as millimeters, but I don't think there's anything special about millimeters in particular.<br>I'm a little confused as to why you wouldn't put the units in QgsSymbol. I see it as an attribute just like size or color. In theory, we might want a uniqueValueRenderer which renders different objects with different scale types. This seems harder to do if a higher-level class is doing the scaling.<br>
Steven<br><br><div class="gmail_quote">On Fri, Mar 7, 2008 at 2:46 AM, Marco Hugentobler <<a href="mailto:marco.hugentobler@karto.baug.ethz.ch" target="_blank">marco.hugentobler@karto.baug.ethz.ch</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Steven,<br>
<br>
Many thanks for pointing this out. I was not aware that QgsGraphicsScene<br>
always has mm units.<br>
<br>
It would be a possibility that QGIS main map also switches to mm units. In<br>
this case QgsMapCanvasMap would determine the scale factor to transform pixel<br>
to mm and configure a QgsMapRenderContext containing this factor. I think it<br>
is not necessary that QgsSymbol knows its units. Higher level classes that<br>
configure the rendering context could do this and just pass the scale factor.<br>
<br>
The other way round would be that QGIS main canvas still has pixel units and<br>
print composer queries dpi of the map image and scales its widths and sizes<br>
to achieve wysiwyg. In my opinion, the global mm approach seems more general.<br>
<br>
Regards,<br>
Marco<br>
<br>
<br>
<br>
<br>
Am Donnerstag 06 März 2008 01:08:46 schrieb Steven Bell:<br>
<div><div></div><div>> After thinking and looking at the code a little, I definitely didn't<br>
> explain that very well...<br>
><br>
> As you know, what you see in the main editing canvas is not always what you<br>
> get in the composer. Likewise,what you see when using the cache preview in<br>
> the composer is not what you get when you render.<br>
><br>
> The root of the problem is that QGIS does all of its drawing in canvas<br>
> units, so when you switch canvases, you change how things look. The map<br>
> composer uses millimeters - one QGraphicsScene unit is one mm.<br>
> Printers and PDF output both work with millimeters this way. If I make a<br>
> QGraphicsRectItem with a size of 10mm square, it will come out 10mm square.<br>
> If the pen width is 1 scene unit (and isn't scaled), it will come out 1 mm<br>
> wide.<br>
><br>
> Note that when the composer map cache pixmap is drawn, the sizes are all in<br>
> pixels again. Thus, as the resolution of the cache image changes, the line<br>
> widths and symbol sizes all change. This has caused a lot of confusion,<br>
> because although the rendered preview matches the rendered output, the<br>
> cached preview does not.<br>
><br>
> I'm not completely clear on what the DPI setting in the composer actually<br>
> does when doing a vector output such as SVG or Postscript. Changing that<br>
> setting doesn't seem to affect them, but the vector output code does<br>
> reference it. I think the SVG generator needs to know something about the<br>
> size/dpi so that rasterizers/renderers can render them properly.<br>
><br>
> What I did in the composer redesign branch was add an enum, mScaleType,<br>
> which tells the renderer what units the size is in. The renderer sets a<br>
> size scale, which is dependent on the scale type, size, and current mupp<br>
> (map units per pixel). Also, rather than setting a pointer to a pixmap, it<br>
> sets a pointer to a symbol renderer which will always render the symbol<br>
> with a size of 1. QgsVectorLayer's drawFeature( ) method scales the<br>
> painter by the size scale and calls the symbolRenderer's render( ) method.<br>
><br>
> Since this appears to be much slower than the current code, we probably<br>
> need to do some context-dependent caching.<br>
><br>
> In the rendering context, we would need to include some information about<br>
> whether we were rendering in screen units or paper units. Perhaps more<br>
> correctly, we would like to know the output DPI, which will be one<br>
> (system-dependent) thing for the editing canvas, 25.4 for the composer<br>
> canvas, and some variable for the composer map cache. Because of the way<br>
> the physical output is handled, I don't think we need to know or care what<br>
> the printer's DPI is.<br>
><br>
> This should enable the removal of the symbol/line width/text scale options<br>
> in the composer. This also allows us to use the QgsMapRender class to<br>
> render the map, rather than having a bunch of almost-duplicate code. The<br>
> code currently in composer_redesign uses QgsMapRender, but I haven't taken<br>
> the time to remove the scale boxes in the map control pane.<br>
><br>
> Let me know if this still isn't clear. I haven't completely sorted it all<br>
> out, either. :-)<br>
><br>
> Steven<br>
><br>
><br>
> On Wed, Mar 5, 2008 at 4:09 AM, Marco Hugentobler <<br>
><br>
> <a href="mailto:marco.hugentobler@karto.baug.ethz.ch" target="_blank">marco.hugentobler@karto.baug.ethz.ch</a>> wrote:<br>
> > Hi Steven,<br>
> ><br>
> > > I would remove symbolScale and widthScale in favor of defining the<br>
> ><br>
> > widths<br>
> ><br>
> > > in terms of concrete units, whether pixels, millimeters, or map units.<br>
> ><br>
> > It would be good for me if you could explain this idea in more detail as<br>
> > I'm<br>
> > still not sure my understanding is correct.<br>
> ><br>
> > Do you mean that QgsSymbol should have its own pen width and stroke<br>
> > width? They would be specified e.g. in mm instead of pixels and when the<br>
> > symbol is<br>
> > applied, transformed to pixels according to the ouput device dpi?<br>
> ><br>
> ><br>
> > The idea that i had was to just work on pixel level with one scalefactor<br>
> > (mResolutionRatio). So if e.g. a printer has a resolution of screen dpi *<br>
> > 2,<br>
> > then mResolutionRatio would be 2 and all the width values for QPen,<br>
> > QBrush and also width/height for images would be scaled by factor 2.<br>
> > Caching pixmaps<br>
> > would only be alloud if mResolutionRatio is 1.<br>
> ><br>
> > I think that would be doable without many code changes. But it is not as<br>
> > generic and clean as working with real units (e.g. mm) in the qgis core.<br>
> ><br>
> > Regards,<br>
> > Marco<br>
> ><br>
> > Am Dienstag 04 März 2008 17:26:08 schrieb Steven Bell:<br>
> > > > So my suggestion is to have the rendering context somehow like this:<br>
> > > ><br>
> > > > class QgsMapRenderContext<br>
> > > > {<br>
> > > > QgsMapToPixel mMapToPixel;<br>
> > > > QgsCoordinateTransform mCoordTransform;<br>
> > > > QgsRect mExtent;<br>
> > > > bool drawEditingInformation;<br>
> > > > bool mRenderingStopped;<br>
> > > > double mResolutionRatio;<br>
> > > > };<br>
> > > ><br>
> > > > The resolution ratio is usually 1, except when drawing to a different<br>
> > > > paint<br>
> > > > device (like QPrinter). I hope it will allow to consider for<br>
> > > > different line<br>
> > > > width / symbol sizes on these output devices.<br>
> > > ><br>
> > > ><br>
> > > >From what I understand, QgsMapToPixel basically holds the information<br>
> ><br>
> > that<br>
> ><br>
> > > mResolutionRatio would contain.<br>
> > ><br>
> > > Martin already mentioned this, but the rendering context needs to have<br>
> ><br>
> > some<br>
> ><br>
> > > way to tell the renderer whether to use maximum-resolution vector ouput<br>
> ><br>
> > or<br>
> ><br>
> > > cached pixmaps. I would also add something about what the output units<br>
> > > are, whether pixels or millimeters. Both of the above might be done<br>
> > > together with an "are we printing to ps/pdf/svg" bool.<br>
> > ><br>
> > > I would remove symbolScale and widthScale in favor of defining the<br>
> ><br>
> > widths<br>
> ><br>
> > > in terms of concrete units, whether pixels, millimeters, or map units.<br>
> > > This is what I have attempted to do in the current composer_redesign<br>
> ><br>
> > code.<br>
> ><br>
> > > One of the major problems is that printed millimeters are treated as<br>
> > > the same as screen pixels, rather than a separate but similar type of<br>
> > > measurement.<br>
> > ><br>
> > > I hope this makes sense. Let me know if I need to clarify anything.<br>
> > > Steven<br>
> ><br>
> > --<br>
> > Dr. Marco Hugentobler<br>
> > Institute of Cartography<br>
> > ETH Zurich<br>
> > Technical Advisor QGIS Project Steering Committee<br>
<br>
<br>
<br>
</div></div>--<br>
<div><div></div><div>Dr. Marco Hugentobler<br>
Institute of Cartography<br>
ETH Zurich<br>
Technical Advisor QGIS Project Steering Committee<br>
</div></div></blockquote></div><br>