v16 - Why are Bullets shown as Hyphens when not non-formatted Notes text?

[Paolo F Cantoni]

I was surprised to see that some Notes field text with bullets wasn't showing up as bullets but as hyphens.  Eventually, we discovered that we'd not set [X] Render as Formatted Notes on the item (as we normally o as a matter of course). Can anyone explain why?  My suspicion is that a different font is used for the two modes.  To me, this seems strange.  Previously, I thought the setting merely suppressed the additional formatting information (but in the same font).

TIA,
Paolo

[Eve]

It's substituted for a character that is available in all fonts.

[Paolo F Cantoni]

It's substituted for a character that is available in all fonts.

Thanks, Eve,
I surmised this was the case, but my question was, Why?  We can set the font we want in the [Ctrl+F9] dialog.  Surely it's our responsibility to ensure the font has the character set we need.  Having established that, why use a different font for the "unformatted" version?  Why not use the same font - without the formatting embellishments?

Paolo

[Eve]

Surely it's our responsibility to ensure the font has the character set we need.

No.

Having established that, why use a different font for the "unformatted" version?  Why not use the same font - without the formatting embellishments?

Not sure what you're referring to.

[Paolo F Cantoni]

Surely it's our responsibility to ensure the font has the character set we need.

No.

Interesting response!  Then why offer us a choice of fonts?  If we choose a font that doesn't contain the character we want and complain, will Sparx accept the accountability?  I suspect not.  Ipso facto, it is our responsibility.[quote]

Having established that, why use a different font for the "unformatted" version?  Why not use the same font - without the formatting embellishments?

Not sure what you're referring to.
This text is rendered as formatted text.   This text is rendered as unformattedtext, but the font is the same!
Does that clarify??

[Eve]

Then why offer us a choice of fonts?  If we choose a font that doesn't contain the character we want and complain, will Sparx accept the accountability?  I suspect not.  Ipso facto, it is our responsibility.

Can't you see the difference between you as the user having explicitly typed a specific character into the notes and the application substituting a character for formatting that was applied? It feels like a disingenuous argument because you personally don't like the way something has produced no complaints for years.

This text is rendered as formatted text.   This text is rendered as unformattedtext, but the font is the same!
Does that clarify??

No. It may surprise you to understand that I understand the concept of formatted text and plain/unformatted text. I even understand having different fonts. Your example is actually wrong though. The second example is still formatted text with no additional formatting applied. On the other hand, when you're not rendering formatted text EA is removing all the formatting and drawing text using a method that has no capability of rendering the formatting that was there.

I don't know why you're saying there are different fonts being used. That's not apparent to me. I don't know if it's actually a font change or a change to how text is rendered with the same font.

[Richard Freggi]

UUhhh... Ehhhrrrr

Some of my work I have to deal with weird characters and formatting from Mickeysoft Office.
So I'm trying to follow this volley, but I'm lost... I thought a bullet was a case of extended ASCII ( CHAR(149)  ), not formatting?  Hyphens are regular ASCII (  CHAR(45)  ).

Changing a character formatting (font bold / regular, using a different color, change Times New Roman into Calibri etc.) is no big deal in my case, but changing a character into another IS a big deal (the user's text is changed).  I understand if the application does not want to deal with extended ASCII, but support for extended ASCII (bullets) would be nice.

Eve can you clarify if you are talking about extended ASCII or about formatting thanks!

p.s. In Paolo's situation could it be a problem with the encoding of the EA database? Since seems to be a character set issue not a formatting issue.

[Eve]

... changing a character into another IS a big deal (the user's text is changed).

The character for the bullet isn't part of the actual text. It's a decoration on the paragraph. Paolo is complaining that the decoration on the paragraph is rendered using a different character when the notes are rendered on a diagram as plain text. Nothing is changed in the actual notes.

[Richard Freggi]

Thanks Eve personally I'm perfectly fine with decorations that are NOT ASCII being ignored or mistreated by EA.

[Paolo F Cantoni]

... changing a character into another IS a big deal (the user's text is changed).

The character for the bullet isn't part of the actual text. It's a decoration on the paragraph. Paolo is complaining that the decoration on the paragraph is rendered using a different character when the notes are rendered on a diagram as plain text. Nothing is changed in the actual notes.

Ah... my bad!  Today, quite coincidentally, EA reinforced that the bullet was the decoration, not a character.  Working with an old item, I ended up with BOTH the Bullet decoration and the bullet character that was originally embedded in the text!

So now, I (and hopefully others) understand what is happening.

Paolo

[qwerty]

It was a huge mistake to step forward from 127 byte ASCII code. Some claim it was even worse to climb down the trees. But honestly, why are so many applications still just work with ASCII code pages? Not that UTF would solve all our problems (it brings different issues). Well, mankind is strange.

q.