Home |
Search |
Today's Posts |
#1
Posted to microsoft.public.word.docmanagement
|
|||
|
|||
Be consistent with Unicode codepoints!
When I want to insert a character via its Unicode codepoint, I type the HEX
code, select it, and Alt+X toggle it back and forth to the character/glyph. This seems to be the easiest method in general of dealing with Unicode one character at a time - since I can get the Unicode for any character already existing in a document I 'inherit' with that toggle. BUT when I want to use the Search/Replace feature to look for a specific character by its Unicode codepoint, that feature requires me to use the DECIMAL version of the codepoint with a little identifier character in front of it. I'm sure there are reasons for both of these conventions, but it makes the interface simply infuriating to use - constantly having to convert back and forth from decimal to hexadecimal. It would be MUCH easier to deal with Unicode if: a) I could universally depend on on using ONE numbering convention for codepoints, b) if the Search/Replace feature had a 'mode' or at least a simpler, more clearly explained method for searching on codepoints, possibly allowing multi-character string searches with less cumbersome syntax. Also, when I (rarely) use the Insert Symbol tool to insert a character _in the Symbol font_ - I cannot toggle those characters with Alt+X. Why not? What's different about them? I know that Symbol font is not Unicode compliant, but why make it harder to figure out what codepoint is behind the character? And why do they show up as being in the same font as the surrounding text that I was editing, rather than actually showing up as Symbol font, which is what the Insert tool told me I was using? This makes it difficult if not impossible (haven't figured out the trick yet) to use Search/Replace to scrub out the non-Unicode compliant characters. ---------------- This post is a suggestion for Microsoft, and Microsoft responds to the suggestions with the most votes. To vote for this suggestion, click the "I Agree" button in the message pane. If you do not see the button, follow this link to open the suggestion in the Microsoft Web-based Newsreader and then click "I Agree" in the message pane. http://www.microsoft.com/office/comm...ocmanagemen t |
#2
Posted to microsoft.public.word.docmanagement
|
|||
|
|||
Be consistent with Unicode codepoints!
You can use the Alt+X toggle in the "Find what" box as well as the document.
Symbols are rather more complex - to put it mildly! There is some information about finding them, he http://www.word.mvps.org/FAQs/Macros...aceSymbols.htm -- Enjoy, Tony www.WordArticles.com "da9ve" wrote in message ... When I want to insert a character via its Unicode codepoint, I type the HEX code, select it, and Alt+X toggle it back and forth to the character/glyph. This seems to be the easiest method in general of dealing with Unicode one character at a time - since I can get the Unicode for any character already existing in a document I 'inherit' with that toggle. BUT when I want to use the Search/Replace feature to look for a specific character by its Unicode codepoint, that feature requires me to use the DECIMAL version of the codepoint with a little identifier character in front of it. I'm sure there are reasons for both of these conventions, but it makes the interface simply infuriating to use - constantly having to convert back and forth from decimal to hexadecimal. It would be MUCH easier to deal with Unicode if: a) I could universally depend on on using ONE numbering convention for codepoints, b) if the Search/Replace feature had a 'mode' or at least a simpler, more clearly explained method for searching on codepoints, possibly allowing multi-character string searches with less cumbersome syntax. Also, when I (rarely) use the Insert Symbol tool to insert a character _in the Symbol font_ - I cannot toggle those characters with Alt+X. Why not? What's different about them? I know that Symbol font is not Unicode compliant, but why make it harder to figure out what codepoint is behind the character? And why do they show up as being in the same font as the surrounding text that I was editing, rather than actually showing up as Symbol font, which is what the Insert tool told me I was using? This makes it difficult if not impossible (haven't figured out the trick yet) to use Search/Replace to scrub out the non-Unicode compliant characters. ---------------- This post is a suggestion for Microsoft, and Microsoft responds to the suggestions with the most votes. To vote for this suggestion, click the "I Agree" button in the message pane. If you do not see the button, follow this link to open the suggestion in the Microsoft Web-based Newsreader and then click "I Agree" in the message pane. http://www.microsoft.com/office/comm...ocmanagemen t |
#3
Posted to microsoft.public.word.docmanagement
|
|||
|
|||
Be consistent with Unicode codepoints!
You can use the Alt+X toggle in the "Find what" box as well as the document.
Symbols are rather more complex - to put it mildly! There is some information about finding them, he http://www.word.mvps.org/FAQs/Macros...aceSymbols.htm -- Enjoy, Tony www.WordArticles.com "da9ve" wrote in message ... When I want to insert a character via its Unicode codepoint, I type the HEX code, select it, and Alt+X toggle it back and forth to the character/glyph. This seems to be the easiest method in general of dealing with Unicode one character at a time - since I can get the Unicode for any character already existing in a document I 'inherit' with that toggle. BUT when I want to use the Search/Replace feature to look for a specific character by its Unicode codepoint, that feature requires me to use the DECIMAL version of the codepoint with a little identifier character in front of it. I'm sure there are reasons for both of these conventions, but it makes the interface simply infuriating to use - constantly having to convert back and forth from decimal to hexadecimal. It would be MUCH easier to deal with Unicode if: a) I could universally depend on on using ONE numbering convention for codepoints, b) if the Search/Replace feature had a 'mode' or at least a simpler, more clearly explained method for searching on codepoints, possibly allowing multi-character string searches with less cumbersome syntax. Also, when I (rarely) use the Insert Symbol tool to insert a character _in the Symbol font_ - I cannot toggle those characters with Alt+X. Why not? What's different about them? I know that Symbol font is not Unicode compliant, but why make it harder to figure out what codepoint is behind the character? And why do they show up as being in the same font as the surrounding text that I was editing, rather than actually showing up as Symbol font, which is what the Insert tool told me I was using? This makes it difficult if not impossible (haven't figured out the trick yet) to use Search/Replace to scrub out the non-Unicode compliant characters. ---------------- This post is a suggestion for Microsoft, and Microsoft responds to the suggestions with the most votes. To vote for this suggestion, click the "I Agree" button in the message pane. If you do not see the button, follow this link to open the suggestion in the Microsoft Web-based Newsreader and then click "I Agree" in the message pane. http://www.microsoft.com/office/comm...ocmanagemen t |
#4
Posted to microsoft.public.word.docmanagement
|
|||
|
|||
Be consistent with Unicode codepoints!
da9ve wrote:
Also, when I (rarely) use the Insert Symbol tool to insert a character _in the Symbol font_ - I cannot toggle those characters with Alt+X. Why not? What's different about them? Because they do not have unique character values. They are "ANSI" characters formatted via a font change to look like another character. When you insert a "character" from the symbol, webding, or wingding fonts, the character codes are all 255 and below. So an alpha has the same character code as a (97); mu, the same as m (109); the serifed circle R, the same as cap O with grave; and the webding snowflake and the wingding ship on ocean, the same as T (84). This is the older, pre-Unicode, method for obtaining special characters. At one time you could toggle these characters to get the hex code. For the last few years MS has protected them to avoid losing the formatting (& making the character look like what it is). Needless to say, the whole point of Unicode is to have a unique character code for each character (or glyph) in the set. Pam -- Message posted via OfficeKB.com http://www.officekb.com/Uwe/Forums.a...ement/201004/1 |
#5
Posted to microsoft.public.word.docmanagement
|
|||
|
|||
Be consistent with Unicode codepoints!
da9ve wrote:
Also, when I (rarely) use the Insert Symbol tool to insert a character _in the Symbol font_ - I cannot toggle those characters with Alt+X. Why not? What's different about them? Because they do not have unique character values. They are "ANSI" characters formatted via a font change to look like another character. When you insert a "character" from the symbol, webding, or wingding fonts, the character codes are all 255 and below. So an alpha has the same character code as a (97); mu, the same as m (109); the serifed circle R, the same as cap O with grave; and the webding snowflake and the wingding ship on ocean, the same as T (84). This is the older, pre-Unicode, method for obtaining special characters. At one time you could toggle these characters to get the hex code. For the last few years MS has protected them to avoid losing the formatting (& making the character look like what it is). Needless to say, the whole point of Unicode is to have a unique character code for each character (or glyph) in the set. Pam -- Message posted via OfficeKB.com http://www.officekb.com/Uwe/Forums.a...ement/201004/1 |
Reply |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Forum | |||
dealing forcefully with Unicode and non-Unicode characters | Microsoft Word Help | |||
TOC results not consistent | Microsoft Word Help | |||
Printed margins not consistent on different PCs | Page Layout | |||
Footnote numbers not consistent | Microsoft Word Help | |||
Consistent style for autoshapes | Microsoft Word Help |