Rich Text issues in x13

[Gawdzira]

I have pervasive problems after saving out plan files. See the image where the text box is missing the last letter(s) of most words. Rich Text. Should I be eliminating Rich Text?  

[Kbird1]

No it looks like the age old "resolution" issue with Chief and Text ......... did you get a new monitor? or someone else plan?

 

If you open one and close it again and it fixes itself , then you have the above issue.

 

No other known fix except to Marquee ( Shift) Select the Text > Open the DBX >  and Close it again without doing anything.

 

Mick.

[Chopsaw]

Do you have two computers or two monitors of a different resolution ?

 

No one should have to eliminate Rich Text but it needs to be reported to Chief Architect until it gets fixed or explained as to why it can not be fixed.

[Chopsaw]

No reason why there could not be a setting in Preferences to auto refresh all Rich Text boxes upon opening the plan file if there is not a more elegant way of fixing it for those that have the plaguing issue.

[Kbird1]

4 minutes ago, Chopsaw said:

No reason why there could not be a setting in Preferences to auto refresh all Rich Text boxes upon opening the plan file if there is not a more elegant way of fixing it for those that have the plaguing issue.

 

I like that Idea , put it over in Suggestions , it could go under   Edit > Reset to Defaults  with override Dimension Text...

 

[Richard_Morrison]

I have been reporting this issue since at least 2006 (http://www.chieftalk.com/showthread.php?20199-Weird-text-problem), and the problem was happening with room labels before that. Since nothing has happened in at least 15 years of many multiple bug reports, I wouldn't hold your breath. I've certainly given up. Doug Park completely redid the text generation in 2001 (http://www.chieftalk.com/showthread.php?2325-Text-size-difference-between-CA6-amp-CA7), when he found multiple legacy problems with text, so it's possible that text has NEVER worked properly. 

[Gawdzira]

Unfortunately, the open and close the text DBX is not 100% for me. I have seen it more since going to a wider monitor. I am using a 38" wide screen. I wonder if that has any impact?

[Chopsaw]

9 minutes ago, Gawdzira said:

I am using a 38" wide screen. I wonder if that has any impact?

 

Is that a 16:9 aspect ratio because that may also be a factor and not just the resolution ?

[KBCASC]

3 hours ago, Gawdzira said:

Unfortunately, the open and close the text DBX is not 100% for me. I have seen it more since going to a wider monitor. I am using a 38" wide screen. I wonder if that has any impact?

 

If you have changed monitors recently , then I suspect that is the Issue , I see it only when I open Clients' Plans and usually  I fix it with All Off > turn Text On , and marquee select it all, Open>Ok

 

I wonder if rather than Resolution if it is related to Pixel density of the screen since I think Fonts are based on pixels?

 

Screen Size	Screen Resolution	Pixel Density	Optimal Viewing Distance
24″	1920×1080	92 PPI	37″ (94cm)
24″	2560×1440	122 PPI	28″ (71cm)
24″	3840×2160	184 PPI	19″ (48cm)
27″	1920×1080	82 PPI	42″ (107cm)
27″	2560×1440	109 PPI	32″ (81cm)
27″	3840×2160	163 PPI	21″ (53cm)
32″	1920×1080	70 PPI	49″ (124cm)
32″	2560×1440	93 PPI	37″ (94cm)
32″	3840×2160	140 PPI	25″ (64cm)
29″ UltraWide	2560×1080	96 PPI	36″ (91cm)
34″ UltraWide	2560×1080	82 PPI	42″ (107cm)
34″ UltraWide	3440×1440	110 PPI	31″ (79cm)
38″ UltraWide	3840×1600	111 PPI	31″ (79cm)
43″	3840×2160	104 PPI	33″ (84cm)
49″ 32:9	5120×1440	109 PPI	32″ (81cm)
49″ 32:9	3840×1080	81 PPI	42″ (107cm)

    

[amddrafting]

I've found that going from one resolution to another always creates this problem.  My home monitor and second screen in my office is 1080 but my laptop is 4K.  Most of the other staff on my team had computers that were 1080.  If I open the files they worked on in 1080 with my 4k laptop all of the text would do that.  So after numerous attempts at trial and error to figure this out (since Support had no answer to this issue) I figured out that if I set my second screen (#2 in image) that has a 1080 resolution as the "main display" in the windows settings and use my laptop as the second screen it resolves the issue.  So obviously it's not a Chief architect issue, it's a Windows resolution issue with text boxes. 

 

[Richard_Morrison]

18 hours ago, amddrafting said:

So obviously it's not a Chief architect issue, it's a Windows resolution issue with text boxes.

I have plenty of Windows programs that use text -- including other CAD programs -- that have NEVER exhibited this behavior with multiple resolutions. So, obviously it's a programming issue. I'm not sure why you are so quick to absolve Chief of any responsibility for addressing this issue.

[amddrafting]

Richard,

 

It has to do with the fact that I use the same computer but because I set the Windows default to a second screen at 1080 and I make that my main screen is why I believe this is beyond CA  Because even if I move the screen back to the 4k screen on my laptop it doesn't effect the text boxes when my second screen is the default main screen at 1080.  It only affects the text boxes when the 4k screen in the set as the main screen.  This tells me that Windows is more likely the culprit and not CA because if it was CA then moving from one monitor to the next with different resolutions would have the same effect on the text boxes if it was CA.

[Smn842]

I've developed various software for desktop and web that has had the challenge of rendering rich text within fixed areas without cropping or wrapping at different points when rendered on devices with different screen DPIs, font metrics, browser vs desktop rendering and different OSes.

 

It's true that problems often originate outside of the software presenting the issue, but there are many cases where this is true in software and applications need to work around the problems as I'm sure CA has done for other issues.

 

There are various approaches depending on what is important for the application, such as retaining wrapping locations for multiline text, retaining box size (so shrinking text/spacing) in addition to preventing character cropping.  It's a problem that can be solved although it can be harder than it appears depending on the level of low level access to the rendering system/library used.

 

For the software I worked on in most cases text boxes were effectively resized by small amounts automatically to retain wrapping and avoid character cropping but without impacting the saved size unless edited (to avoid needless saves).  It was also often useful to have an additional small margin inside the box that wasn't considered part of the calculated sizing after editing, but could be used during rendering as this would avoid overall text box size changes where users wanted them to be accurately positioned or aligned

[Richard_Morrison]

16 hours ago, Smn842 said:

It's true that problems often originate outside of the software presenting the issue, but there are many cases where this is true in software and applications need to work around the problems as I'm sure CA has done for other issues.

My point exactly. I hope that Chief's programmers look at your suggestions, or come up with another alternative. I will say that the situation has gotten somewhat better over the years. It used to be that an entire last paragraph could get clipped off in a long text box, whereas now the effect seems to be limited to a single character. I had one instance a number of years ago where a paragraph got truncated without me catching it, and it easily could have cost me a lot more than just the embarrassment it caused.