Bug 91029 - Writer: character identification by copying into dialog
Summary: Writer: character identification by copying into dialog
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.2.8.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-05-02 22:52 UTC by Nick Levinson
Modified: 2015-05-16 19:01 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Levinson 2015-05-02 22:52:35 UTC
I want to be able to identify a character that's already in a document. Since it's stored as one or more bytes, if a user copies a character into a dialog and specifies the font, it shouldn't be technologically hard to match the string length and the 0s and 1s and have the dialog report the matching character.

I don't know if any font still exists in which different fontsizes may offer different glyphs for the same keyboard input (they existed in bitmapped fonts in the late 1980s on Macintosh System). If so, the dialog should also ask what fontsize to judge by. That could be a menu that appears only if the font is of such a kind, since they're probably rare.

If a newer version of Writer has this, that's good enough. The version I'm reporting on has still been getting updated even after reputedly being at EOL.

I guessed my hardware.
Comment 1 Buovjaga 2015-05-06 14:06:25 UTC
Do you mean you want to expose the Unicode number of a character (for example U+004A for Latin Capital Letter J)?

Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided more information.
Comment 2 Nick Levinson 2015-05-09 19:48:39 UTC
That's a good solution.
Comment 3 Yousuf Philips (jay) (retired) 2015-05-13 18:36:51 UTC
I would assume the searching for a character to find its unicode number is a feature found in a character map application, or alternatively a user can search google for it, and isnt really suited to be a feature of the current special character dialog.

@Adolfo, Heiko, Stuart: What is your opinion of this?
Comment 4 Regina Henschel 2015-05-13 19:33:47 UTC
No need for such a feature. Copy the character into a spreadsheet into cell A1. In cell A2 write =unicode(A1) and get the decimal number. If you need the hexadecimal number too, then write =dec2hex(A2) into cell A3.

Outside of LibreOffice you can use the charts of http://www.unicode.org/charts/ and the nice tool http://shapecatcher.com/
Comment 5 Heiko Tietze 2015-05-13 20:07:05 UTC
+1 for Regina
Comment 6 Yousuf Philips (jay) (retired) 2015-05-15 21:53:17 UTC
Closing this as others agree its not worth implementing.
Comment 7 V Stuart Foote 2015-05-15 22:08:11 UTC
Agree to close this, but would suggest that Design and UI work on http://user-prompt.com/libreoffice-design-session-special-character/ and https://docs.google.com/document/d/1PxkIpkzgWF1cX9oQmBhjiTBhUXvUEqbz06Bn4hzbF54 , as well as on bug 34882, should also provide a UI to identify specific Unicode of a selected glyph.

Regina's workaround in comment 4 is cumbersome--while using the Special Character GUI dialog to display the selected glyph seems sensible.
Comment 8 Nick Levinson 2015-05-16 19:01:09 UTC
I assume we'd like LibreOffice to gain acceptance among the general public, most of whom wouldn't think of using a spreadsheet, Google, the Unicode site, or Shapecatcher to identify a glyph, but might search (laboriously) the character dialog, often futilely. We should avoid solutions that require a geek's expertise to remember. Or, if we stay with that, Writer's Help file should say how to do this.

I glanced at the URLs in comment 7. Support for drawing a glyph to identify it is an amazing idea if recognition technology is up to it but I hope simply copying and pasting a glyph, thus copying the bytes, will also be supported, as that would avoid confusing glyphs as handwriting often would and it would support identifying a whitespace or invisible (glyphless) control character (usually one that has a character width of zero even in a monopitch font).