Le mer, aoû 29, 2001, à 10:11:50 +0930, Young, Robert a écrit:
> Yes. I see the problem here - probably two separate issues:
> 1. Initial window size, specified in pixels.
> 2. Initial extents, e.g. 2x2 A4 + 10% bleed or user definable (allow dia to
> decide when to increase this number of pages?) Why? Because I am currently
> frustrated by the diagram always being exactly the diagram extents. Maybe I
> should fix this...
>
> In my mind both should be definable in the Properties dialog.
It should be trivial to do. In fact, the older code did some padding,
but there were some issues (namely, a crasher), which led me to remove this
in order to simplify the code path. And the relationship between the
diagram's actual extents and the scrollable area (the area which was
scrollable through the scrollbars) wasn't obvious.
There indeed should probably be a user-configurable setting, like "diagram
extents":
* match the actual diagram extents (current behaviour)
* pad X% in each direction
* pad N $UNITS in each direction
(both pad options >must< do something sensible when the diagram is empty.)
The padding issue should be clearly separated from the extents calculation,
since we will want no padding at all when printing or exporting to EPS.
One workaround I find handy is to not use "reset after create" (I used to be
a great fan of that option), but to first select the "scroll" tool, select
the desired creation tool, and use the space bar to go back and forth from
the scroll to the creation tool (yes, the space bar is a fresh feature).
> I'm not certain that 1cm on screen = 1cm in diagram is that much of a
> problem - it depends on display device (e.g 17" monitor, 12" LCD display
> both using 800x600 have completely different dimensions for a pixel). The
> only importance is 1cm in diagram must be 1cm on page when printed
> scale=100% in postscript. What do other users think??
anyway, you can query the display for its DPI setting. Most modern DDC2
devices will be able to more or less accurately tell their resolution. This
is what Ghostscript uses, and the special Display Postscript build of dia I
had last winter had real centimetres on all three displays I tried it on.
> Agreed. Let the user select a default unit (I quite like drawing in units of
> light years :-)
This would finally rid us of whiners like
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=61422&repeatmerged=yes (and
mozilla still tells me about printing margins in terms of half of inches
<grumpf/>).
> > We'd also need to add a number of
> > frequently used unit designations, like "ft" and "feet".
> Agreed. It's good that US inches are the same as real proper English inches
> (unlike gallons and other interesting units).
<troll>but inches != cm, so why bother ? </troll>
> The extension of this concept can be seen in a publishing prorgam Ovation
> Pro (http://www.davidpilling.co.uk) which allows a user to enter maths (e.g.
> 10pt+10%) into a field and it will calculate what the user wanted. I think
> this is a version 5.0 milestone though :-)
SolidWorks does that too. It's really a neat feature. But there's even
better: you can define some equations in a (linear ?) solver, and use the
solution variables in fields. Now modify a value, click on "recompute", and
watch your whole model resize its features... (actually, this is a standard
feature of all parametric CAD packages, of which SolidWorks is slick and
easy to use, but by far not the most powerful).
-- Cyrille
--
Grumpf.