Currently, inserting a special character always results in DF (direct-formatting) of that character to the chosen font, even if it's the same font that's used in the surrounding text (i.e. the active CS font). Users typically do not realize this is happening and will continue typing away in DFed font, which will then continue to spill onwards. This does not immediately become a problem, but once a style change is made which involves the choice of another font - those DFed segments maintain the old font. That should not happen. The solution is that when a special character is inserted, even though it's DFed to a certain font - subsequent characters typed (assuming no cursor repositioning) should have the same CS and DF they would have, had the special character not been inserted.
I agree that SC should not do DF, if possible (inserting some OpenSymbol char in Liberation text would be an exception, for example). But I don't see what UX can contribute here neither why we need another ticket when bug 139359 is about the same issue (and has some discussion) and bug 155274 apparently too. => DUP
(In reply to Heiko Tietze from comment #1) > I agree that SC should not do DF, if possible (inserting some OpenSymbol > char in Liberation text would be an exception, for example). This is for when DF does need to be inserted. The point is _how_ it's inserted. > But I don't see what UX can contribute here Well, I guess perhaps a referral to the right developer? But maybe that's too flimsy. Let's just call it a regular bug then. > neither why we need another ticket when bug > 139359 is about the same issue (and has some discussion) Oh no, it is not! That one is about what DF is inserted which covers the special character; this is about ensuring that DF doesn't affect characters typed past the special char.