After thinking and looking at the code a little, I definitely didn't explain that very well...<br><br>As you know, what you see in the main editing canvas is not always what you get in the composer. Likewise,what you see when using the cache preview in 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 units, so when you switch canvases, you change how things look. The map composer uses millimeters - one QGraphicsScene unit is one mm. <br>Printers and PDF output both work with millimeters this way. If I make
a QGraphicsRectItem with a size of 10mm square, it will come out 10mm
square. If the pen width is 1 scene unit (and isn't scaled), it will come out 1 mm wide.<br>
<br>Note that when the composer map cache pixmap is drawn, the sizes are all in pixels again. Thus, as the resolution of the cache image changes, the line widths and symbol sizes all change. This has caused a lot of confusion, because although the rendered preview matches the rendered output, the cached preview does not.<br>
<br>I'm not completely clear on what the DPI setting in the composer actually does when doing a vector output such as SVG or Postscript. Changing that setting doesn't seem to affect them, but the vector output code does reference it. I think the SVG generator needs to know something about the 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, which tells the renderer what units the size is in. The renderer sets a size scale, which is dependent on the scale type, size, and current mupp (map units per pixel). Also, rather than setting a pointer to a pixmap, it sets a pointer to a symbol renderer which will always render the symbol with a size of 1. QgsVectorLayer's drawFeature( ) method scales the 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 need to do some context-dependent caching.<br><br>In the rendering context, we would need to include some information about whether we were rendering in screen units or paper units. Perhaps more correctly, we would like to know the output DPI, which will be one (system-dependent) thing for the editing canvas, 25.4 for the composer canvas, and some variable for the composer map cache. Because of the way the physical output is handled, I don't think we need to know or care what the printer's DPI is.<br>
<br>This should enable the removal of the symbol/line width/text scale options in the composer. This also allows us to use the QgsMapRender class to render the map, rather than having a bunch of almost-duplicate code. The code currently in composer_redesign uses QgsMapRender, but I haven't taken 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 out, either. :-)<br><br>Steven<br><br><br><div class="gmail_quote">On Wed, Mar 5, 2008 at 4:09 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>
<div><br>
> I would remove symbolScale and widthScale in favor of defining the widths<br>
> in terms of concrete units, whether pixels, millimeters, or map units.<br>
<br>
</div>It would be good for me if you could explain this idea in more detail as 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 width?<br>
They would be specified e.g. in mm instead of pixels and when the 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 * 2,<br>
then mResolutionRatio would be 2 and all the width values for QPen, QBrush<br>
and also width/height for images would be scaled by factor 2. 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>
<br>
<br>
<br>
Am Dienstag 04 März 2008 17:26:08 schrieb Steven Bell:<br>
<div><div></div><div>> > 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 different<br>
> > line<br>
> > width / symbol sizes on these output devices.<br>
> ><br>
> ><br>
> >From what I understand, QgsMapToPixel basically holds the information that<br>
><br>
> mResolutionRatio would contain.<br>
><br>
> Martin already mentioned this, but the rendering context needs to have some<br>
> way to tell the renderer whether to use maximum-resolution vector ouput or<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 widths<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 code.<br>
> One of the major problems is that printed millimeters are treated as the<br>
> 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>
<br>
</div></div><font color="#888888">--<br>
Dr. Marco Hugentobler<br>
Institute of Cartography<br>
ETH Zurich<br>
Technical Advisor QGIS Project Steering Committee<br>
</font></blockquote></div><br>