Hi,
A program I've written (timechart, see http://blog.fenrus.org/?p=5 ) has SVG as output format. The idea behind timechart is to show what is happening in a system as part of performance tuning, and to do so in a way that is "infinitely zoomable", that is, if you want more information about a portion of the timechart, all you need to do is zoom in and more small details appear.
With Inkscape being the primary suggested tool for viewing the output, I currently have a problem in that I can't put the finest details into the SVG, because inkscape just won't allow zooming deep enough to be able to see those details.
I made the patch below that bumps the limits on zooming so that users of timechart then can get to the very finest details (if this patch is accepted I'll change timechart to put the details in that I've not been able to put in so far). I hope this (or a change with similar effects) is acceptable for inclusion into Inkscape.
Greetings, Arjan van de Ven Intel Open Source Technology Center
Index: src/desktop-handles.h =================================================================== --- src/desktop-handles.h (revision 22220) +++ src/desktop-handles.h (working copy) @@ -21,8 +21,8 @@ class Selection; }
-#define SP_DESKTOP_ZOOM_MAX 256.0 -#define SP_DESKTOP_ZOOM_MIN 0.01 +#define SP_DESKTOP_ZOOM_MAX 4096.0 +#define SP_DESKTOP_ZOOM_MIN 0.001
#define SP_COORDINATES_UNDERLINE_NONE (0) #define SP_COORDINATES_UNDERLINE_X (1 << Geom::X)
On 9/13/09, Arjan van de Ven <arjan@...2242...> wrote:
I made the patch below that bumps the limits on zooming so that users of timechart then can get to the very finest details
Limits are the easiest part. What actually prevents us from increasing zoom limits is the precision of coordinates. Just apply your patch and you will notice lots of artefacts (missing/wrong parts of paths) at the closest zoom. When we went from 16 to 256 maximum zoom, this necessitated making all coordinates double instead of float. Cairo library that we use for outline mode also had problems at close zooms (in 0.46) until they switched to a higher bit length in their renderer.
On Sun, 13 Sep 2009 08:58:19 -0400 bulia byak <buliabyak@...400...> wrote:
On 9/13/09, Arjan van de Ven <arjan@...2242...> wrote:
I made the patch below that bumps the limits on zooming so that users of timechart then can get to the very finest details
Limits are the easiest part. What actually prevents us from increasing zoom limits is the precision of coordinates. Just apply your patch and you will notice lots of artefacts (missing/wrong parts of paths) at the closest zoom. When we went from 16 to 256 maximum zoom, this necessitated making all coordinates double instead of float. Cairo library that we use for outline mode also had problems at close zooms (in 0.46) until they switched to a higher bit length in their renderer.
I've tried the patch without visible issues, but the output of my tool is mostly lines, rects and text, nothing more fancy. So I suppose I can have missed something. Makes me wonder if all issues have been fixed already by the double thing...
On 9/13/09, Arjan van de Ven <arjan@...2242...> wrote:
I've tried the patch without visible issues, but the output of my tool is mostly lines, rects and text, nothing more fancy. So I suppose I can have missed something. Makes me wonder if all issues have been fixed already by the double thing...
Try some of our example files. Try the outline mode too. I would be surprised if we could go to 4096 without an issue, although it is possible - the codebase has changed a lot since the last time we investigated this.
participants (2)
-
Arjan van de Ven -
bulia byak