Re: Feature requests for custom shapes

[Hans Breuer <hans breuer org>]

Am 03.12.2014 um 12:41 schrieb Nico Rikken:
> [...]
>
> 1) Is it possible to create a custom dash-array as is part of the
> svg-specifications? I am now limited to the predefined dashes, which
> does not included an alternating dash style of a repeating short dash
> and long dash.
The full flexibility of custom dash-array is not available due to 
restrictions in Dia's rendering interface. But looking at the code (
  grep set_linestyle objects/custom/*.c
and
  grep _parse_dasharray lib/dia_svg.c
) the style you request should be possible with Dia master.

> 2) Can I define one-dimensional lines rather than shapes? I'd like to
> include lines with the same specifications (dash-length) as squares and
> brackets, which are after all part of the specs I'm recreating. 1-D
> elements however don't seem to render.
Sorry, I don't understand what you are asking for. Of course you can use 
lines within shapes, but a custom shape will always behave like a box. For 
connection-like custom shapes see the custom_lines plug-in.

> 3) Can I define user-fillable text-boxes? Creating custom shapes for
> each specific text is cumbersome, especially if such texts very per
> placed shape. Basically I'd like to specify the starting-point of text
> and optionally the formatting. This includes values added on specific
> places around a shape, for which the placement and alignment is also
> specified in various norms.
Having multiple text fields available for shapes looks like an interesting 
addition (Maybe Dia can become a form editor;)).
There is at least one object already usable with two text fields: 'UML - 
Object' (obects/UML/object.c). But implementing something like that plus 
additional constraints coming from SVG is probably not an easy task.

> 4) Can the alignment of a shape to the grid be specified explicitly?
> Some shapes have elements in dimensions inbetween a normal grid,
> although the alignment of the shape to the standard grid is defined.
Grid snapping is implemented by restricting handle movement. The handle 
positions of custom shapes are derived from the bounding box of the shape,
see: custom_object.c(custom_update_data)

> 5) Can a stroke-width be defined in a relative fashion? I have shape
> 02-02-04 which is intended to be used together with text, but now the
> stroke-width is to thin compared to the text (like in 02-02-05).
> Explicitly defining it causes problems when scaling.
IIRC stroke-width is defined in a relative fashion, but only relative to 
previous stroke-width in the shape. If I understand you correctly you want 
the line-width to be relative to the text size? Before implementing that we 
should find a good answer to:
https://mail.gnome.org/archives/dia-list/2008-July/msg00084.html

> 6) Can text be specified in other font-styles like italic, ideally
> varying within a text-field? Text related to an element can cover
> 'variable = value' where the variable in some cases needs to be italic,
> whilst the value is a normal font for readability.
The shape <textbox/> is not SVG but directly maps to the Dia Text 'class'.
So none of the SVG text attributes apply to it.
But if your variable name is constant per shape it might be possible to 
combine static SVG text (with all it's supported options) and the textbox 
Text with it's limitations. But still there is only one textbox per shape. 
Extending Dia's text layout capabilities to support different text styles 
would require changes in a lot of places in the code base (app/ lib/ 
plug-ins/).

> 7) Will hatching be available in Dia and can hatchings be
> custom-defined? ISO-standards specify different hatchings for different
> materials, for which it would be great if they were available to apply
> to shapes.
With the current pace not before 2030 ;)

> 8) I've read that in the next version of Dia rotation will be available
> via a Python plugin. How will it handle text embedded in shapes, since
> sometimes texts needs to rotate and sometimes it doesn't. Will there be
> a way to explicitly define this for a shape, which could possibly also
> be specified for flipping, especially for text definitions.
You should definitely look at the development version. It has text rotation 
for the 'Standard - Text' and almost complete rotation support for other 
Standard elements. The shape's SVG does not support transform, though.
I don't know of any Python plugin doing text rotation, but there is some 
attempt to do generic roation via Pythong at:
 http://dia-installer.de/doc/rotation.html.en

> Furthermore I have some more generic questions:
>
> a) Earlier I've asked about dealing with different representations of a
> shape. Shape 06-09-01 is one form of a transformer, whilst 06-09-02 is a
> second form of the exact same thing, and 06-09-03 is an extension on
> 06-09-02 with the explicit mention of the polarity. I guess this help
> clarify my earlier questions. In terms of hierarchy: Power systems >
> energy conversion > transformers > 2-pole transformer > type of symbol
> (form 1 or form 2) > additional indications (polarity, screen, variable
> coupling). The form and the type of transformer (2-pole/3-pole) relates
> to the number of connections of the shape and therefore might need to be
> the most explicit definitions, all other aspects could be changed. So
> rather than having a long list of icons it might be more convenient to
> have some options within the shape, but as far as I understand this
> currently requires writing custom code for Dia. Are there any related
> best-practices?
https://wiki.gnome.org/Apps/Dia/HowToSubmitPatches ?

> b) In the case of changing text in shapes, the dimensions of some
> drawing elements of the shape should ideally adjust to match the text.
> Is there a way to cope with that by using say subshapes? (this question
> is hypothetical, since I haven't run into this problem yet).
Than let's postpone the attempt of an answer;)

> If someone can address at least some of the questions I'd be glad. It
> seems I'm now experiencing the limits of Dia and I'm curious what limits
> can be stretched and what limits I should cope with (at least for the
> moment).
>
> Thanks in advance.
>
> Nico Rikken
>
> [1]
> https://dl.dropboxusercontent.com/u/9238838/dia-nico-dev-2014-12-03.zip
HTH,
        Hans

-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to
get along without it.                -- Dilbert