[Qgis-developer] Print composer redesign

[Marco Hugentobler]

Hi Steven and Martin,

I also like the idea of converting between different units to make the maps 
look the same on different output devices.

> Symbols would probably use some type of plugin, which would be able to
> paint themselves without being tied to a specific resolution.  Tim has
> mentioned preferring to use SVG for all of the symbols.  Unfortunately, SVG
> doesn't allow user-defined colors (at least by default; it might be
> possible to write code which could re-color an SVG).

At the very beginning of the point symbol implementation, QPicture (a vector 
format) has been used. It has been replaced by QImage because of performance 
issues and because the Qt3 implementation of QPicture was not very good. I 
don't know what the current status is.

> Is this reasonable?  Is it doable, and a direction QGIS should go in?  I'll
> try to put together an official RFC soon, as I figure out some more details
> of how the code will actually work.

Yes, a RFC would be great.

Regards,
Marco  

On Friday 05 October 2007 04:41:14 Steven Bell wrote:
> I've been trying to think about an improved design for the print composer.
> Currently, there are two major issues: print fidelity and ease of use.
> I find the current composer paradigm to be fairly common and intuitive.
> Several drawing programs (such as Inkscape or OOo Draw) use this basic GUI
> design.  Tim had some other ideas for the GUI design, which I'm also
> thinking about.
>
> Most of the printing issues are results of inconsistent scaling between the
> screen and the printer (or PDF, which acts the same as a printer).
>
> There are at least four ways I would like to be able to specify sybolology
> size:
>   -Map units (e.g, 20 meters)
>   -Scale-relative paper units (.5mm at 1:15000)
>   -Paper units (3mm, regardless of scale)
>   -Screen units (5 pixels, regardless of scale)
>
> Right now, only the last one is implemented, so this would probably
> represent a major change in the way vector layers are rendered.  I don't
> know a lot about this, so I'd especially like some input as to how hard
> this would be to implement, and how it would fit in with the rest of QGIS.
>
> Symbols would probably use some type of plugin, which would be able to
> paint themselves without being tied to a specific resolution.  Tim has
> mentioned preferring to use SVG for all of the symbols.  Unfortunately, SVG
> doesn't allow user-defined colors (at least by default; it might be
> possible to write code which could re-color an SVG).
>
> The code to render the map would hopefully be exactly the same for the map
> canvas and the composer's render and cache modes.  The caller would specify
> the size of the device to be painted on, and the map would correctly scale
> itself.
>
> Ideally, the cache/render difference would become invisible to the user,
> with QGIS automatically updating the cache when something changes.  There
> may still need to be a "hard cache" mode for times when rendering a map
> takes a very long time.
>
> Many of the usability problems could be fixed by adding more tips to the
> user such as tool-dependent cursors and possibly a status bar.   I'd like
> to be able to resize the map by dragging the bounding boxes.  More
> importantly, the user should be able to redefine the area a map displays.
>
> The current way the scalebar, legend and labels appear as soon as the user
> clicks their buttons seems a little goofy.  It might be better to pop up a
> dialog with the options, and let the user click ok before creating the
> item.
>
> Is this reasonable?  Is it doable, and a direction QGIS should go in?  I'll
> try to put together an official RFC soon, as I figure out some more details
> of how the code will actually work.
>
> Steven
>
> By the way, I've think I've figured out the problem with the map labels not
> printing correctly.  Unfortunately, it doesn't appear completely
> straightforward to solve.



-- 
Dr. Marco Hugentobler
Institute of Cartography
ETH Zurich
Technical Advisor QGIS Project Steering Committee
marco.hugentobler at karto.baug.ethz.ch