2007/11/11, Lars Clausen <lars raeder dk>:
> What you could end up with, is a shape file that looks like this:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <shape xmlns="
http://www.daa.com.au/~james/dia-shape-ns"
> xmlns:dia=" http://www.daa.com.au/~james/dia-shape-ns"
> xmlns:svg="
http://www.w3.org/2000/svg">
> <name>Test - Subshape2</name>
> <icon>Subshape2.png</icon>
>
> <aspectratio type="free"/>
>
> <svg:svg>
>
> <svg:rect
>
> style="fill:#47caf3;fill-opacity:1;stroke:black;stroke-width:0.1;stroke-miterlimit:4;stroke-opacity:1"
> id="rect1874"
> width="12"
> height="9"
> x="0.078606814"
> y="0.062494233 " />
>
> <svg:g
> dia:subshape="true"
> dia:v_anchor="
fixed.top"
> dia:h_anchor="fixed.right"
> dia:default_scale="1.0"
> id="g1894">
1. On attribute naming and values
===========================
While I see that adding some Dia-specific attributes to the SVG tag is
probably the nicest way to go about this, I think the naming could be
improved. Instead of v_anchor and h_anchor, why not just anchor with
possible values northwest, north, northeast etc? What does the "fixed"
in the anchor values mean, and what are the alternatives? Having that
part separate (and perhaps optional, if there's a good default) would
remove the need to parse the attribute value.
First of all, I try to keep the following in mind while designing:
There is always a
trade-off between
flexibility and
ease of use, the aim is to
have an interface that doesn't require an MIT degree to use.
Now, on to your question/remark...
There are two ways to anchor the subshape into the parent shape:
1. fixed
2. proportional
These two ways are
mutually exclusive and
collectively exhaustive,
which makes them good practice (see also:
http://en.wikipedia.org/wiki/MECE_principle)
A
fixed anchor takes the actual offset from the SVG file and fixates it
from a certain side of the parent shape. For each of the two orthogonal
directions in 2D space (horizontal and vertical), there are two anchor
possibilities (
left/
right for horizontal and
top/
bottom for vertical). The
naming is derived from the code, where the original authors chose to
represent a Rectangle with: top, left, bottom, right attributes, which
makes sense in this context, and it is dummy proof.
Besides a fixed anchor, there is also the possibility of a
proportionalanchor. In this case, the subshape is positioned at a position that is
proportional to its position in the original SVG shape. (I.e. if it is in the
middle of the SVG shape, it stays in the middle, if it is at 70% from
the left and 20% from the top it stays there, no matter how the parent
shape is rescaled.
The actual offsets, beit for either fixed or proportional offsets are
derived from the SVG, this makes it a nice separation of concerns,
since we do not have to overcomplicate the additional attributes.
Now, to summarize, for each of the two orthogonal anchor directions
(horizontal and vertical, -hence- h_anchor, v_anchor, for my part,
horizontal_anchor and vertical_anchor), there are three mutually
exclusive values:
v_anchor must be one of: fixed.top, fixed.bottom, proportional
h_anchor must be one of: fixed.left, fixed.right, proportional
Note: because of the orthogonality of the v_anchor and h_anchor,
any combination of proportional and fixed properties can be used
for
any subshape.
Opinion #1: About the naming
--------------
The naming can be changed into fixed.north, fixed.south,
fixed.east, fixed.west, but I see no reason why that would be
better than top/left/bottom/right, making the change more of a
personal preference, in which case my preference is to follow
the Rectangle attribute naming: Top, left, bottom, right.
Advise #1: Do not split into separate attributes/options
--------------
Because of the mutual exclusive property, it seems to me, that it is
unwise to put these into separate XML attributes, because then
an end user will be allowed to specify two conflicting options, yielding
undefined behaviour, or, at best, a defined default behaviour (which
we will expect the user takes notice of (by reading the manual)).
Advise #2: Do not merge into a single attribute/option
--------------
It also seems unwise, to me, to stuff everything in a single attribute,
since both directions (horizontal and vertical) are
orthogonal, this, by itself,
validates the use of a separate attribute.
In addition to this, your suggestions to use: North, south, east, and west,
have no meaning in this matter, unless we decide to give it a meaning
(such as north=hozitonally proportional, but fixed from the top),
but I would advise against that for several reasons:
- By merging into a single option you explode the number of options; or
- By convention you limit the number of options, making a less clean
trade-off between complexity and flexibility.
- The term proportional clearly describes the meaning of the attribute using
common knowledge terminology, in plain english (no need to read the
documentation), whereas north/south/east/west as proportional in one
direction and fixed in another, would be a convention which
does require
reading of the manual. (Let alone it requires
us to document it;) )
2. On the scale of things
===================
The default_scale name
suggests there's a way to set a non-default scale, is that the case?
The default scale is here, for the same reason dia uses a default scale
of 2cm x 2cm for each object that is added to a diagram. Now, if someone
authors an SVG shape (e.g. using inkscape) in a certain scale, using a
certain unit system, say mm (which is the default in many locales),
and the shape is 84x54 (mm), then dia would interpret this, by default,
as 84x54 _cm_. Since the subshape scales independently of the parent shape,
it will take on a default scale.
For example, if the default_scale, in this case, would not have been set
to something like, 0.1 or 0.01 even, then it would have been WAY too
large to even appear inside the parent shape, even with fixed offsets
(the fixed offsets in the original unit system of the SVG shapes (in mm)
would be off the charts when interpreted by dia (in cm).
To see this, assume the left most point of the subshape starts at x=65mm,
dia interprets the SVG shape in cm, so on a typical use we would draw the
parent shape with widths of 2cm-20cm, however, the subshape would, in this
scale and unit system, start at 65cm offset (and be in a different scale as well!),
-hence- the object would not be rendered inside the parent shape, and thus
not be visible. By setting a default scale, we can differentiate the scale and
unit system in which an arbitrary SVG shapes is authored from the particular
scale by which dia interprets the shape, and for this, we use default_scale.
3. Annotations are good to make things readable
(using common sense and common knowledge)
======================================
I would like to be rid of the half-bit subshape attribute, what purpose
does it serve that couldn't be inferred from the presence of anchor and
scale attributes?
Yes you are correct, the fact that we are dealing with a subshape, here,
could, in fact, as well be inferred from the presence of anchor/and or
scale attributes, and I have thought of this.
However, abusing these values for this purpose would make it less
clear for anybody new to dia shapes/SVG in which context the other
attributes need to be placed. In such a case, there will be nothing but
convention that would imply that we are dealing with a subshape
(from dia perspective, but that becomes clear from the namespace to
which the attribute belongs).
So by having this separate attribute, we have:
- An attribute with a clear and distinct purpose: namely, to turn on the
interpretation of a subshape.
- Anyone reading these SVG files would, again by using common knowledge
and terminology, understand in which context the attributes should be placed:
namely "dia is going to interpret this <g> (svg group) as a dia subshape.
- We enforce the above "annotation" rather than have it be optional using
comments (optional things are for optional, not if you want something to be
done properly, then it has to be mandatory).
> As I've said earlier, there are still a few issues left, but a preview
> movie (flash) of the current state of the art can be watched:
>
>
http://krnl.nl/dia_custom_shapes_with_non_uniform_scaling.html
Nice, I can definitely see uses for this.
-Lars
Thanks.
Epilog
=====I would like to conclude this reply by saying that, even though in this
reply I may seem a bit stubborn, I
*am* open for suggestions. After
all, I can't foresee every type of usage upfront. However, I
*have* given
the current design decisions and naming/value schemes quite some
thought, so certain choices are likely to be less arbitrary than they, at
first glance, seem.
I hope that this reply is clear to everybody interested in this subject,
if not, please do no hesitate to ask more questions. I will try to explain
or clearify anything that has remained unclear.
