As discussed recently, I have changed the zoom levels so that at 100%, one px unit is equal to one screen pixel. This change led to switching all internal calculations from a mix of px and pt to pure px. This simplified code in many places and got rid of lots of ugly 0.8 and 1.25 multipliers that were scattered throughout the codebase.
Correspondingly, the default template now uses the px units. I think that makes sense, given that most people use Inkscape for screen graphics. Now zoom to 100% (the `1' key) and you'll see your graphic exactly as it will look when exported with default resolution (now 90dpi, not 72dpi as before).
This is a pretty big change. I tested everything I touched, but I may have missed something. Please test thoroughly. All old files with saved zoom will now load at 1.25*zoom, but that's inevitable; if you see any other problems, please report here.
On Sun, Jan 02, 2005 at 04:05:11AM -0400, bulia byak wrote:
As discussed recently, I have changed the zoom levels so that at 100%, one px unit is equal to one screen pixel. This change led to switching all internal calculations from a mix of px and pt to pure px.
Thank you!
pjrm.
bulia byak wrote:
As discussed recently, I have changed the zoom levels so that at 100%, one px unit is equal to one screen pixel. This change led to switching all internal calculations from a mix of px and pt to pure px. This simplified code in many places and got rid of lots of ugly 0.8 and 1.25 multipliers that were scattered throughout the codebase.
Hmmm....
The only question that comes to mind is wether or not the proper calculations were preserved.
:-)
That is, since the magic literals were actually representing the ratio of user units to device pixels, at some point in the future (mainly once we tweak the CSS support), we'll probably want to go ahead and support unit ratios determined by the SVG user agent at initialization time as mentioned in the SVG spec. So... did you just refactor the code to remove those values altogether, or did you replace them with a variable or #define and then set that to 1.0?
On Sun, 02 Jan 2005 10:57:06 -0800, Jon A. Cruz <jon@...18...> wrote:
Hmmm....
The only question that comes to mind is wether or not the proper calculations were preserved.
:-)
I hope so. Please test :)
That is, since the magic literals were actually representing the ratio of user units to device pixels,
More precisely, of absolute units to user units (which we call px). User units, in their turn, can have non-1:1 ratio to device pixels, but that's another story, and is much less of a problem since this is supposed to happen on high-resolution devices only, not on screen.
at some point in the future (mainly once we tweak the CSS support), we'll probably want to go ahead and support unit ratios determined by the SVG user agent at initialization time as mentioned in the SVG spec. So... did you just refactor the code to remove those values altogether, or did you replace them with a variable or #define and then set that to 1.0?
Previously the widely used functions such as selection bbox, document width etc. all returned pt, but you needed px to write to repr, hence the conversions. Now all these functions return px, so no converstions are needed. Where conversions are needed (only where the user-selectable units are used), they are all done in a centralized way via SPUnit methods. So about the only place where the ratio is hardcoded is #define DEVICESCALE in unit-constants.h. I have left a couple 1.25s and 0.8s but this is because they are in the code which I don't understand and cannot test (specifically in extension/internal/win32.cpp and extension/internal/gnome.cpp).
bulia byak wrote:
More precisely, of absolute units to user units (which we call px). User units, in their turn, can have non-1:1 ratio to device pixels, but that's another story, and is much less of a problem since this is supposed to happen on high-resolution devices only, not on screen.
Or...
It also happens on screen on low-res displays of many devices (Phones, Blackberrys, etc). Of course, this does not have much immediate bearing on Inkscape display code and such, but we should keep that in mind for created assets. Hmmm... I wonder if we might even want to allow for different 'previewing' modes.
Also... considering that the place these odd displays might be used are also those a bit likely to use SVG Tiny, this might be something of a leverage point for Inkscape.
participants (3)
-
bulia byak -
Jon A. Cruz -
Peter Moulder