[Qgis-developer] Print composer redesign

Tim Sutton tim at linfiniti.com
Wed Oct 10 16:44:40 EDT 2007

Hi Steven

Thanks for a great synopsis. I'm not any expert on SVG, but I believe
the SVG can be dynamically recoloured in a manner similar to using an
external cascading style sheet (css).


I dont know what kind of overhead there is in this and if we find svg
rendering too slow, we may need to reinstate the oversampling and
caching approach that Lars Luthman wrote once.

Regarding user interface issues we did discuss this a bit but for the
benifit of the list I could mention my major desires:

 - map composition integrated into the main window of the application
 - a pallet of map components available in toolbox in a separate tab
(legend one tab, map components other tab)
 - the map composition could be carried out in a separate tab to the
main map canvas tab. I        had some ideas about providing map
composition functionality directly on the canvas for but for now just
using a second tab is probably the more conservative approach
requiring less new code.
 - when dragging items onto the composition area, provide a preview of
the item as you drag it over. Currently you click on a tool and its
not obvious that you need to go and drag a box on the composition area
to place it.

I very much like your idea of using a plugin based approach for
rendering markers since it can allow us to define a number of
different backends to provide markers (truetype, svg, image markers,
qpictures etc).

Best regards


2007/10/6, Hugentobler  Marco <marco.hugentobler at karto.baug.ethz.ch>:
> 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.
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.qgis.org
> http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer

Tim Sutton
QGIS Project Steering Committee Member - Release  Manager
Visit http://qgis.org for a great open source GIS
openModeller Desktop Developer
Visit http://openModeller.sf.net for a great open source ecological
niche modelling tool
Home Page: http://tim.linfiniti.com
Skype: timlinux
Irc: timlinux on #qgis at freenode.net

More information about the Qgis-developer mailing list