Bottom bullet is different size than the rest

[Anonymous]

I am having a problem with bulleted lists in the drawing.

Every time I make a list the bottom bullet is always bigger than all the others. I have tried turning the bullets on and off, changing the font size on different lines, trying to force it to correct itself but have not had much luck. Every once in awhile it'll come out right at first but 90% of the time it doesn't.

Has anyone come across this error before or has any tricks to stop it from happening? Attached is a picture of the problem.  Thank you in advance for your help.

kelly.young has embedded your image for clarity.

[johnsonshiue]

Hi! I guess the last line has a slight different font size or line spacing. Could you share the example file here?

Many thanks!

[jtylerbc · Accepted solution]

A coworker here discovered this issue a couple of weeks ago and told me about it.  Somehow he had figured this out by accident, and wanted to pass it along.

This only happens when you change the text size in the Editor from whatever the default size is for the Text Style.  It seems like the last bullet (or number in a numbered list) continues to be controlled by the Style's specified size, unless you do a very specific (and rather silly) thing to resolve it.

When you select your text to change the size, select from Top to Bottom, instead of from Bottom to Top.  You'll find that it appears to select an additional "space" character at the end of the text.  This character doesn't actually exist in the text, and isn't selectable if you select in the opposite direction.  But if you get it selected, then change the text size, then whatever evil curse is causing the last bullet or list number to be enlarged goes away.

[Anonymous]

LOL Wow! Thank you so much. This was driving me crazy. 

[SBix26]

This actually behaves just like MS Word- the paragraph (line break) character, which is not visible, carries the formatting for the bullet.  It's important to select the entire line including that last invisible character when you want to change the formatting of the entire line.  The difference with Word, of course, is that you have a control to make all those invisible characters visible so you know exactly what you're getting.

Try this experiment on your example: select only the last (invisible) character of the line and change its size (or bold/unbold); you will see the bullet change size, but not the letters in between.

---

Sam B
Inventor Pro 2019.0.1 | Windows 7 SP1
LinkedIn

[mcgyvr]

---

@johnsonshiue wrote:

Hi! I guess the last line has a slight different font size or line spacing. Could you share the example file here?

Many thanks!

---

@johnsonshiue Johnson can you please confirm if this bug as reported by jtylerbc is in your "bug tracker" and provide an update on what if anything can be done or is being done about it....

As pointed out in another post about it this bug has been around for a while and really needs to get "squashed"...

https://forums.autodesk.com/t5/inventor-forum/last-bullet-does-not-follow-font-size-changes-in-2016-...

[jtylerbc]

@mcgyvr's linked thread also has a post from me, which explains the way I went about fixing this before my coworker stumbled upon the magic invisible space.  Prior to this discovery, I was working around the issue by creating a Text Style of the desired size when a bulleted or numbered list gave me trouble.

[-niels-]

---

@jtylerbc wrote:

When you select your text to change the size, select from Top to Bottom, instead of from Bottom to Top.  You'll find that it appears to select an additional "space" character at the end of the text.

---

Wouldn't it be easier/better to use the "CTRL+A" keyboard shortcut to "select all" when changing the text size?

Not saying this bug shouldn't be fixed, just making a suggestion to help with the work-around...

[jtylerbc]

---

@-niels- wrote:

---

Wouldn't it be easier/better to use the "CTRL+A" keyboard shortcut to "select all" when changing the text size?

Not saying this bug shouldn't be fixed, just making a suggestion to help with the work-around...

---

Yeah, that probably would be more efficient. People who normally select the text that way probably don't even know that the bug exists.

The drag direction explanation was offered mainly as background for why this happens, in addition to being a possible workaround.  Without knowing the effect of the drag direction, the behavior may seem inconsistent, when in reality it is very predictable.

In my opinion, the bug isn't necessarily the existence of the extra space (which I assume is really a formatting character).  It's the inability to select it when dragging from bottom-to-top.  I see no real reason why this should behave differently than top-to-bottom selection or CTRL+A.

[SBix26]

While I agree that the text editor could use some work, I don't see this as a bug.  As I wrote above, the extra space at the end of each line is the line break character.  If you highlight one of those "spaces" and delete it, you've just merged the two lines, because you took out the line break between them.  The line break character carries the formatting for the the bullets.

This is exactly how Microsoft Word works.  If you click at the end of a paragraph, your cursor is sitting between the last character in the line and the line break character (which Word shows, when asked, as "¶").  Word makes it a bit easier to select that line break character, though in Word 2007 (my current version) it errs in the opposite direction: I can't select just the text in a line, it always wants to select the line break, too.

So I'm not seeing anything in text selection that is broken, just not as slick as it might be.

---

Sam B
Inventor Pro 2019.0.1 | Windows 7 SP1
LinkedIn

[mcgyvr]

---

@SBix26 wrote:

While I agree that the text editor could use some work, I don't see this as a bug. 

---

So you don't expect that if one were to select all 4 lines as shown in the image and then change the font size that they should all be changed?

What about in this case?

If I select all the text as shown you don't expect the last line to inherit the same font size changes?

I expect identical functionality in both cases.. Currently there is not.... They function differently.. 

If I have highlighted multiple lines/words/items/whatever.. I fully expect ALL objects in my selection to obey the commands I'm applying to them..

[SBix26]

@mcgyvr In both examples it is perfectly clear that the line break character at the end of the last line didn't get selected.  In the first example it matters, because there is a bullet that will not be changed; in the second example, there is nothing visible that depends on that line break character's formatting, so it won't matter.

I grant you it's annoying to have to select and format that character separately, but it's consistent behavior.  Using left-to-right swiping or Ctrl-A avoids the annoyance, but you have to remember to do it.  Again, not much different from Word, just not as polished.

---

Sam B
Inventor Pro 2019.0.1 | Windows 7 SP1
LinkedIn

[mcgyvr]

---

@SBix26 wrote:

@mcgyvr In both examples it is perfectly clear that the line break character at the end of the last line didn't get selected.  In the first example it matters, because there is a bullet that will not be changed; in the second example, there is nothing visible that depends on that line break character's formatting, so it won't matter.

I grant you it's annoying to have to select and format that character separately, but it's consistent behavior.  Using left-to-right swiping or Ctrl-A avoids the annoyance, but you have to remember to do it.  Again, not much different from Word, just not as polished.

---

Sam B
Inventor Pro 2019.0.1 | Windows 7 SP1
LinkedIn

---

While I fully understand what you are saying the fact that the end result in one case is different from the other to me indicates an undesired functionality which I would classify personally as a "bug"..  Potato/Potatoe... sadly neither matters as it hasn't been fixed since bullets have been around so this undesired functionality has continued to effect users negatively...

I will certainly agree though that Inventor needs "polishing"  

I'd love a polish year where many "limitations/issues" like this are buffed right out... 

As I've stated in the past the limitations/issues like this cost me more time than any new feature is saving me..