Breaking long element names

[brback]

When modelling an element you will at times experience that the element name is too long to fit inside the element figure, the element name label will then extend beyond the figure borders. So far I have solved this manually by inserting a Space in the element name, which makes the element name fit inside the figure and easier to read in a diagram, but harder to read in the Project browser. For example the element name "TooLongElementNameDoesNotFitInFigure", I would manually break into "TooLongElementName- DoesNotFitInFigure", which will fit into the element figure but create an unwanted spacing for the element in the Project browser.

Does there exist a way for Sparx to automatically break such element names into several lines, so they will fit into the element figure?

[qwerty]

Nope. You just can control wrapping of features with Feature Visibility/When Resizing. The element name is only wrapped when it contains spaces, hyphens, and eventually other special chars I'm not aware of.

q.

[Simon M]

It could probably be done by adding aBreak Permitted Here or Zero Width Space character in the name.

But I'm not sure how to do that, and it will probably break code engineering (if it's being used) and copy and paste could behave weirdly.

Another alternative is to use a friendly/wrappable name as an alias, and show aliases on your diagram.

[Paolo F Cantoni]

It could probably be done by adding aBreak Permitted Here or Zero Width Space character in the name.

But I'm not sure how to do that, and it will probably break code engineering (if it's being used) and copy and paste could behave weirdly.

Another alternative is to use a friendly/wrappable name as an alias, and show aliases on your diagram.

While the idea is seductive, "there be dragons..."   It seems to me this would cause more problems than it fixes.

@brback is essentially asking for a solution to a rendering problem, not a naming problem

It seems to me that if a name uses both upper and lower case characters and NO spaces then it is (by definition) a Cased name.  Using Convention over configuration, one can legitimately "wrap" at the interface between a lowercase character and an uppercase character (for left to right scripts). 

@brback, you could submit a feature request and we could then support it.

Paolo

[Glassboy]

It seems to me that if a name uses both upper and lower case characters and NO spaces then it is (by definition) a Cased name.  Using Convention over configuration, one can legitimately "wrap" at the interface between a lowercase character and an uppercase character (for left to right scripts). 

Surely you mean camel-cased name (he says only in the interest of being accurate).

[Paolo F Cantoni]

It seems to me that if a name uses both upper and lower case characters and NO spaces then it is (by definition) a Cased name.  Using Convention over configuration, one can legitimately "wrap" at the interface between a lowercase character and an uppercase character (for left to right scripts). 

Surely you mean camel-cased name (he says only in the interest of being accurate).

camel-cased is a insufficiently accurate name.  We allow: Standard Camel Cased, Complex Camel Case, Standard Pascal Cased, Complex Pascal Cased names.  The definition, in some sources, of camel case includes Pascal Cased (and also appears to have changed over the decades) and in other sources, they are related by quite distinct - so we use the more generic Cased Name to cover the "multitude of sins".

(in the "Standard" forms, acronyms and initialisms etc. are cased with uppercase first letter, the rest lower case, in "Complex" forms, the acronyms etc. are all in uppercase.)

HTH,
Paolo

[Glassboy]

camel-cased is a insufficiently accurate name.  We allow: Standard Camel Cased, Complex Camel Case, Standard Pascal Cased, Complex Pascal Cased names.  The definition, in some sources, of camel case includes Pascal Cased (and also appears to have changed over the decades) and in other sources, they are related by quite distinct - so we use the more generic Cased Name to cover the "multitude of sins".

Any proper noun is "cased", so your contraction seems to be unnecessarily  ambiguous :-)

[Simon M]

While the idea is seductive, "there be dragons..."   It seems to me this would cause more problems than it fixes.

Absolutely. I mentioned two of the potential issues of the first approach. The second recommendation deals only with the rendering, but that in itself may be an issue in other places.

It seems to me that if a name uses both upper and lower case characters and NO spaces then it is (by definition) a Cased name.  Using Convention over configuration, one can legitimately "wrap" at the interface between a lowercase character and an uppercase character (for left to right scripts).

I strongly disagree. This may be a rule that makes sense for a small subset of English speakers,  but it certainly doesn't apply in general. EA uses Windows APIs to detect where it can wrap lines. I don't even know all the rules that they have to obey, but I know it depends on the language of the text.

PS. "Cased" seems so ambiguous as to mean nothing to someone who doesn't know your particular lexicon. "THIS TEXT" is upper case, "this text" is lower case, "This Text" is title case, "This text" is sentence case, "thisText" is camel case to me and "ThisText" is Pascal case to me. But they are all cased.

[Geert Bellekens]

Taking distance from the intellectual masturbation around cased, camel, pascal or otherwise, it would seem a good idea to allow a break in long names whenever a lowercase-Uppercase difference is found.

ThatMakesSenseToMe

Geert

[Paolo F Cantoni]

PS. "Cased" seems so ambiguous as to mean nothing to someone who doesn't know your particular lexicon. "THIS TEXT" is upper case, "this text" is lower case, "This Text" is title case, "This text" is sentence case, "thisText" is camel case to me and "ThisText" is Pascal case to me. But they are all cased.

Agreed,  I should have said Cased Unspaced.  The first three in your example are "spaced".  The last two are unspaced.

And although EA uses Windows APIs to tell it where to break lines in text, names are not (narrative) "text", they are "tokens".  The Windows APIs can happily apply to the Notes, they shouldn't apply to the Names.  We are discussing the wrapping of tokens.  Now the rules around wrapping of tokens and narrative text may have a large overlap, but they aren't the same.

All names in our repository are "tokenised",  so that they may be compared correctly.

Paolo

I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced

[Paolo F Cantoni]

Taking distance from the intellectual masturbation around cased, camel, pascal or otherwise, it would seem a good idea to allow a break in long names whenever a lowercase-Uppercase difference is found.

ThatMakesSenseToMe

Geert

Gets my vote....  But not it needs to be the right transition:

ThatMakes
SenseToMe

Not:

ThatMakesS
enseToMe


Paolo

[brback]

Lots of answers... thank you guys

Another alternative is to use a friendly/wrappable name as an alias, and show aliases on your diagram.

This seems to be the best solution for me at this moment, which I just found out there is an "Use Alias if Available" option for 

Taking distance from the intellectual masturbation around cased, camel, pascal or otherwise, it would seem a good idea to allow a break in long names whenever a lowercase-Uppercase difference is found.

ThatMakesSenseToMe

Geert

I agree, even though that was not part of my original intention. I used the lowercase-Uppercase difference only to make the word more readable in this example. Usually we would name an element "Thismakessensetome", but I guess it would be hard to break this without a dictionary or such. I would guess that this challenge is more prominent in my language (norwegian) as we tend to concatenate a lot of words that are splitted in english.

[qwerty]

Which designates you to be a Donaudampfschiffahrtsgesellschaftskapitän. However, English is the lingua franca in the IT world. And what Geert said MakesAbsolutelySense. Instead of a complicated set of non-working rules I'd prefer a simple rule. Occam's razor cuts best!

q.

P.S. Obviously the wrapping is treated differently with labels: http://sparxsystems.com/forums/smf/index.php/topic,37288.0.html

[Paolo F Cantoni]

Which designates you to be a Donaudampfschiffahrtsgesellschaftskapitän. However, English is the lingua franca in the IT world. And what Geert said MakesAbsolutelySense. Instead of a complicated set of non-working rules I'd prefer a simple rule. Occam's razor cuts best!

q.

P.S. Obviously the wrapping is treated differently with labels: http://sparxsystems.com/forums/smf/index.php/topic,37288.0.html

Interestingly, Google translate CAN'T translate Donaudampfschiffahrtsgesellschaftskapitän to English. But to Italian, it translates it as (English equivalent) Danube Steamship Company Captain - which to my very limited Gerglish seems right enough.

Paolo

[Simon M]

When I said that it's following a lot of rules, it should be an implementation of http://www.unicode.org/reports/tr14/.

I can't see anywhere that breaks tokens (or prevents then being broken) based on character case, but I wouldn't rule out that something like that could be happening inside the implementation. Besides the fact that the original question turns out to not be after it, that's why I don't think implementing a break at new camel case (general sense) word would be a good idea.

Usually we would name an element "Thismakessensetome", but I guess it would be hard to break this without a dictionary or such. I would guess that this challenge is more prominent in my language (norwegian) as we tend to concatenate a lot of words that are splitted in english.

Interesting.

The unicode line wrapping algorithm supports that option (as has been implemented by Microsoft) for South East Asian languages. Unfortunately, I don't see any way that we could implement that style of wrapping for you.