[Qgis-developer] Print composer redesign

[Hugentobler Marco]

Hi Steven,

Thanks for pointing this out. I'm just about to leave for holidays, so I will give my comments and come up with questions in a week.

cheers,
Marco


-----Ursprüngliche Nachricht-----
Von: qgis-developer-bounces at lists.qgis.org im Auftrag von Steven Bell
Gesendet: Fr 05.10.2007 04:41
An: qgis-developer at lists.qgis.org
Betreff: [Qgis-developer] Print composer redesign
 
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.