[Qgis-developer] Re: composer redesign branch

[Steven Bell]

After thinking and looking at the code a little, I definitely didn't explain
that very well...

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.

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.
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.

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.

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.

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.

Since this appears to be much slower than the current code, we probably need
to do some context-dependent caching.

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.

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.

Let me know if this still isn't clear.  I haven't completely sorted it all
out, either. :-)

Steven


On Wed, Mar 5, 2008 at 4:09 AM, Marco Hugentobler <
marco.hugentobler at karto.baug.ethz.ch> wrote:

> Hi Steven,
>
> > I would remove symbolScale and widthScale in favor of defining the
> widths
> > in terms of concrete units, whether pixels, millimeters, or map units.
>
> It would be good for me if you could explain this idea in more detail as
> I'm
> still not sure my understanding is correct.
>
> Do you mean that QgsSymbol should have its own pen width and stroke width?
> They would be specified e.g. in mm instead of pixels and when the symbol
> is
> applied, transformed to pixels according to the ouput device dpi?
>
>
> The idea that i had was to just work on pixel level with one scalefactor
> (mResolutionRatio). So if e.g. a printer has a resolution of screen dpi *
> 2,
> then mResolutionRatio would be 2 and all the width values for QPen, QBrush
> and also width/height for images would be scaled by factor 2. Caching
> pixmaps
> would only be alloud if mResolutionRatio is 1.
>
> I think that would be doable without many code changes. But it is not as
> generic and clean as working with real units (e.g. mm) in the qgis core.
>
> Regards,
> Marco
>
>
>
>
> Am Dienstag 04 März 2008 17:26:08 schrieb Steven Bell:
> > > So my suggestion is to have the rendering context somehow like this:
> > >
> > > class QgsMapRenderContext
> > > {
> > >        QgsMapToPixel mMapToPixel;
> > >        QgsCoordinateTransform mCoordTransform;
> > >        QgsRect mExtent;
> > >        bool drawEditingInformation;
> > >        bool mRenderingStopped;
> > >        double mResolutionRatio;
> > > };
> > >
> > > The resolution ratio is usually 1, except when drawing to a different
> > > paint
> > > device (like QPrinter). I hope it will allow to consider for different
> > > line
> > > width / symbol sizes on these output devices.
> > >
> > >
> > >From what I understand, QgsMapToPixel basically holds the information
> that
> >
> > mResolutionRatio would contain.
> >
> > Martin already mentioned this, but the rendering context needs to have
> some
> > way to tell the renderer whether to use maximum-resolution vector ouput
> or
> > cached pixmaps.  I would also add something about what the output units
> > are, whether pixels or millimeters.  Both of the above might be done
> > together with an "are we printing to ps/pdf/svg" bool.
> >
> > I would remove symbolScale and widthScale in favor of defining the
> widths
> > in terms of concrete units, whether pixels, millimeters, or map units.
> > This is what I have attempted to do in the current composer_redesign
> code.
> > One of the major problems is that printed millimeters are treated as the
> > same as screen pixels, rather than a separate but similar type of
> > measurement.
> >
> > I hope this makes sense.  Let me know if I need to clarify anything.
> > Steven
>
>
>
> --
> Dr. Marco Hugentobler
> Institute of Cartography
> ETH Zurich
> Technical Advisor QGIS Project Steering Committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/qgis-developer/attachments/20080305/b927ed3d/attachment.html