 viewport
Suggestion by Jean Marie:
The ViewPort si defined as a rectangle
Viewport width = "12 cm" height="8 cm"
A horPos = "3 cm" verPos = "6 cm"
B horPos = "2 cm" verPos = "2 cm"
C horPos = "8 cm" verPos = "2 cm"
This fixes the "location of triangle ABC and so can any geometric object be located in an universal manner no relying on any SW or HW.
The labels could also be located using "offsets" to their parents :
Label A horOff= "0,5 cm" verOff = "0,5 cm"
(The offsets refer to the start of the baseline, NOT to the enclosing topleft corner box
If a construction (or its SW) needs a system of coordinate, it has to be "located" in the viewport in indicating the location of the origin and additional information as needed.
If the coordinate system is Euclidean, rectangular, and aligned on centimeters one might have something like
Euclidean Coordinate System
Origin horPos = "2 cm" verPos = "2 cm"
XunitVector horPos = "3 cm" verPos = "2 cm"
YunitVector horPos = "2 cm" verPos = "3 cm"
If we would stick with en offset concept we could accept
XunitVector horOff = "1 cm" verOff = "0 cm"
YunitVector horOff = "0 cm" verOff = "1 cm"
Comment:
1 All values can be >=0 or <0 with the probable exception of ViewPort width and ViewPort height supposed to be >0.
One could accept negative values to reverse the orientation to have it "computer like" or possibly "Arabic like".
2 We could explicitly introduce the concept of Anchor, in order to be able to redefine it at another position than (0,0)
If we would stick with en offset concept we could accept
XunitVector horOff = "1 cm" verOff = "0 cm"
YunitVector horOff = "0 cm" verOff = "1 cm"
Comment:
1 All values can be >=0 or <0 with the probable exception of ViewPort width and ViewPort height supposed to be >0.
One could accept negative values to reverse the orientation to have it "computer like" or possibly "Arabic like".
2 We could explicitly introduce the concept of Anchor, in order to be able to redefine it at another position than (0,0)

Comment by Maxim:
The most important remarks about units that I can remember are:
 Pixels are not a decent measure, because they are very device dependent. So we need to use some independent measure such as the centimeter (cm).
2. Viewing a construction on devices with significantly varying screen sizes causes a problem, no matter whether pixels or a fixed unit such as the cm is used. If a user saves a construction shown on a 16inch screen and it takes up 15cm there, what size should be used when it is displayed on an iPhone?
My idea is the following:
 I guess the problem mentioned in 2 will persists in any case, because it is not clear what the size of the most important details are that the creator of the resource wants the user to see. However...
 … a solution can be found if we abstract from the unit used. What I mean is that we can start with a small notational improvement borrowed from the LaTeX PStricks package, where a construction starts by defining a unit in more or less the following way: "unit=1cm" (or "15cm", if desired) and then proceeds with data in this abstract unit, saying that a certain circle has radius "3.2 units".
It is now easier to define a dependency of the unit on the screen size. We could e.g. define a "smalldevicesunit", so that the appearance of a resource on a small screen (or a large) can be customized. Going in that direction, we could make a 3case distinction (smalldevices,standarddevices,largedevices).
However, since I foresee that the variety of screen sizes available will only grow (iPads, notebooks, 32inch screens, whatever), I suggest a more flexible approach. We could give a continuous parametrization of the unit according to the screen size, thus achieving for constructions something like nonlinear font scaling: nonlinear construction scaling. Exactly how a given construction scales could be made to depend on one parameter, the scalesensitivity. Let us call that parameter s.
A possible solution is to let a DGS look at the screen width w and calculate:
unit(w) = w^(1s) * unit0.
Here unit0 is the unit used in the construction when displayed on an imaginary standard screen of 1cm in diameter. The user can set the scalesensitivity s in .1? at the beginning of a construction, with default 0.5. With the default value, a construction would show up only 2.14 times as big on a 16inch screen as on an iPhone, and not 16/3.5 = 4.57 times.
The file would then contain something like:
0.2 (the length in cm of a unit size segment in the construction when displayed on a screen of diameter 1cm)
0.5
if then O=(0,0) and P=(1,0), the segment OP would be of length 0.2 * 8.89^0.5 = 0.596 cm on an iPhone, 0.2 * 40.64^0.5 = 1.274 cm on a 16inch screen and 0.2 * 55.88^0.5 = 1.495 cm on a 22inch screen.