Re: emojis for mouse buttons?

[John W Kennedy via Unicode]

As I have already said, this will not do. Mouses do not have “left” and “right” 
buttons; they have “primary” buttons, which may be on the left or right, and 
“secondary” buttons, which may be on the right or left. If this goes through, 
users with left-handed mouse setups will curse you forever.

-- 
John W. Kennedy
"Compact is becoming contract,
Man only earns and pays."
 -- Charles Williams.  "Bors to Elayne:  On the King's Coins"

> On Jan 1, 2020, at 6:43 AM, Marius Spix via Unicode  
> wrote:
> 
> Cecause the middle button of many mice is a scroll button, I think, we
> need five different characters:
> 
> LEFT MOUSE BUTTON CLICK (mouse with left button black)
> MIDDLE MOUSE BUTTON CLICK (mouse with middle button black)
> RIGHT MOUSE BUTTON CLICK (mouse with right button black)
> MOUSE SCROLL UP (mouse with middle button black and white triangle
> pointing up inside)
> MOUSE SCROLL DOWN (mouse with middle button black and white triangle
> pointing down inside)
> 
> These characters are pretty useful in software manuals, training
> materials and user interfaces.
> 
> Happy New Year,
> 
> Marius
> 
> 
> 
>> On Tue, 31 Dec 2019 23:04:39 +0100
>> Philippe Verdy via Unicode  WROTE:
>> 
>> Playing with the fiolling of the middle cell to mean a double click
>> is a bad idea, it would be better to add one or two rounded borders
>> separated from the button, or simply display two icons in sequence
>> for a double click).
>> 
>> Note that the glyphs do not necessarily have to show a mouse, it
>> could as well be a square with its lower third part split into two or
>> three squares, like a touchpad (see the notification icons displayed
>> by Synaptics touchpad drivers). The same rounded borders could also
>> mean the number of clicks. As well, if a ouse is represented, it may
>> or may not have a wire.
>> 
>> Emoji-styles could use more realistic 3D-like rendering with extra
>> shadows...
>> 
>> Le mar. 31 déc. 2019 à 22:16, wjgo_10...@btinternet.com via Unicode <
>> unicode@unicode.org> a écrit :  
>> 
>>> How about the following.
>>> 
>>> A filled upper cell to mean click,
>>> 
>>> a filled upper cell and a filled middle cell to mean double click,
>>> 
>> Note that clicking and maintaining the button is just like the
>> convention of using "+" after a key modifier before the actual key
>> (both key may be styled separately to decorate their glyphs into a
>> keycap, but such styling should not be applied in the distinctive
>> glyph; there may also be emoji sequences to combine an anonymous
>> keycap base emoji with the following characters, using joiner
>> controls, but this is more difficult for keys whose labels are texts
>> made of multiple letters like "End" or words like "Print Screen",
>> after a possible Unicode symbol for keys like Page Up, Home, End,
>> NumLock; styling the text offers better option and accessibility even
>> if symbols are used and a whole translatable string is surrounded by
>> deocrating styles to create a visual keycap).
> 

Re: emojis for mouse buttons?

[John W Kennedy via Unicode]

Operationally, one does not program for “left” or “right” buttons, because 
left-handed users are encouraged to set a switch that logically turns the mouse 
around, with “Button 1” being the button worked by the index finger, no matter 
what side of the mouse it’s on.

-- 
John W. Kennedy
"Compact is becoming contract,
Man only earns and pays."
 -- Charles Williams.  "Bors to Elayne:  On the King's Coins"

> On Dec 31, 2019, at 10:52 AM, Philippe Verdy via Unicode 
>  wrote:
> 
> 
> I say "emoji" because they would belong to the subsets of emojis, within 
> characters, and existing mouse characters (but not button-specific) are 
> already encoded as emojis (i.e. two styles: basic glyphs or color icons).
> 
> What is important is less the mouse than the identification of the button 
> (left/center/right) for documenting keymaps in UI (the documentation usually 
> indicate the default right-hand assignment, a user may still configure the 
> mouse driver to swap the left/right buttons).
> 
> For now the alternative is to compose a localisable string like "L" or "R" or 
> "C", followed by the generic mouse (when documenting keymaps, the surrounding 
> square and shading may be done outside using styling, we just need the unique 
> symbol in a more immediately readable way than just "click".
> 
> A generic clic (1st button) is sometimes represented as an arrow cursor or 
> hand with a pointing finger, and some radial strokes near the tip of the 
> arrow, but it is not very distinctive when we need to explicitly disinguish 
> the buttons, so I suggest a basic empty shape (rounded rectangle or ovoid 
> like a narrow theta "Θ"), with the top part split in three cells by 
> horizontal and vertical strokes, and one of the three cells filled 
> (representing the wire or the wireless waves is not necessary).
> 
> 
> Le mar. 31 déc. 2019 à 14:57, Shriramana Sharma  a écrit :
>> Why are these called "emojis" for mouse buttons rather than just 
>> "characters" for them?
>> 
>> On Tue, 31 Dec, 2019, 18:45 Philippe Verdy via Unicode, 
>>  wrote:
>>> A lot of application need to document their keymap and want to display keys.
>>> 
>>> For now there are emojis for mouses (several variants: 1, 2 or 3 buttons), 
>>> independently of the button actually pressed.
>>> 
>>> However there's no simple emoji to represent the very common mouse click 
>>> buttons used in lot of UI.
>>> 
>>> But it would be good to have emojis for the left, center, and right click 
>>> (showing a mouse with the correct button filled in black), instead of 
>>> writing "left click" in plain text.
>>> 
>>> Has it been proposed ?
>>> 
>>> See for example https://wiki.openstreetmap.org/wiki/ID/Shortcuts
>>> 

Re: 0027, 02BC, 2019, or a new character?

[John W Kennedy via Unicode]

In cold-metal days, many were driven to resort to “M‘Donald” for lack of a 
superscript “c”. 

> On Jan 26, 2018, at 11:47 AM, Richard Wordingham via Unicode 
>  wrote:
> 
> On Fri, 26 Jan 2018 09:08:51 +
> Andre Schappo via Unicode  wrote:
> 
>> Ah! Yes That is a battle I gave up a long time ago. The database
>> here can only handle ASCII. I have stopped trying to get the systems
>> people here to convert the database to UTF-8.
> 
> Some systems (or admins) have been totally defeated by even the ASCII
> version of ʹO’Sullivanʹ.  That bodes ill for Kazakhs.
> 
> Richard.
> 

Re: IBM 1620 invalid character symbol

[John W Kennedy via Unicode]

Indeed, the later 1620-2 was equipped with a Selectric, which probably has 
something to do with the fact that the ж-like character was replaced on that 
model by the “pillow” character (which doesn’t seem to be available in Unicode 
at all).

> On Sep 27, 2017, at 1:02 PM, Asmus Freytag via Unicode  
> wrote:
> 
> On 9/27/2017 9:32 AM, Ken Whistler via Unicode wrote:
>> The only font on that machine can be found by feeling the key strikers in 
>> the typewriter.
> In that context it's worth remembering that there while you could say for 
> most typewriters that "the typewriter is the font", there were noted 
> exceptions. The IBM Selectric, for example, had exchangeable type balls which 
> allowed both a font and / or encoding change. (Encoding understood here as 
> association of character to key).
> 
> That technology was then only two years in the future.
> 
> Other typewriters used interchangeable type wheels for the same purpose, but 
> I believe that generally came later.
> 
> A./

-- 
John W Kennedy
"Harriet thanked Heaven, with grim amusement, for the scholarly habit; at 
least, one did not have to argue about what was or was not evidence."
  -- Dorothy L. Sayers: "Gaudy Night"

Re: IBM 1620 invalid character symbol

[John W Kennedy via Unicode]

The 56th page in the PDF, numbered 52. 

-- 
SKen Software, LLC
Coming soon to an iPhone near you

> On Sep 26, 2017, at 9:20 AM, Martin J. Dürst <due...@it.aoyama.ac.jp> wrote:
> 
>> On 2017/09/26 22:03, John W Kennedy via Unicode wrote:
>> I don’t know what your snippet is from, but the normally authoritative IBM 
>> manual, A26-5706-3, IBM 1620 CPU Model 1 (July, 1965) displays what is 
>> clearly the Cyrillic letter. Whether it should be regarded as that, or as a 
>> distinct character, is another question. See 
>> http://www.bitsavers.org/pdf/ibm/1620/A26-5706-3_IBM_1620_CPU_Model_1_Jul65.pdf
> 
> What page?
> 
> Regards,   Martin.

Re: IBM 1620 invalid character symbol

[John W Kennedy via Unicode]

I don’t know what your snippet is from, but the normally authoritative IBM 
manual, A26-5706-3, IBM 1620 CPU Model 1 (July, 1965) displays what is clearly 
the Cyrillic letter. Whether it should be regarded as that, or as a distinct 
character, is another question. See 
http://www.bitsavers.org/pdf/ibm/1620/A26-5706-3_IBM_1620_CPU_Model_1_Jul65.pdf


> On Sep 26, 2017, at 12:48 AM, Leo Broukhis via Unicode  
> wrote:
> 
> Wikipedia (https://en.wikipedia.org/wiki/IBM_1620#Invalid_character) 
> describes the "invalid character" symbol (see attachment) as a Cyrillic Ж 
> which it obviously is not. 
> 
> But what is it? Does it deserve encoding, or is it a glyph variation of an 
> existing codepoint?
> 
> The question is somewhat prompted by 
> 
> 2BFF  1   HELLSCHREIBER PAUSE SYMBOL
> 
> in the pipeline, although I learned about both earlier today within a few 
> minutes of one another.
> 
> Thanks,
> Leo
> 
> 

Re: How to Add Beams to Notes

[John W Kennedy via Unicode]

> On May 1, 2017, at 3:12 PM, Michael Bear via Unicode  
> wrote:
> 
> I am trying to make a music notation font. It will use the Musical Symbols 
> block in Unicode (1D100-1D1FF), but, since that block has a bad rep for not 
> being very complete, I added some extra characters in the unmapped positions 
> of that block (e.g. U+1D127 inverts the stem of the previous note, U+1D1E9 is 
> a ledger line, U+1D1EA is the "TAB" clef, U+1D1F0-U+1D1FC position the note 
> along the staff, etc.) I've had no problem so far, but now I need to do 
> beamed notes. The Unicode block has control characters for beginning and 
> ending a series of beamed notes (U+1D173 and U+1D174, respectively), but I'm 
> not really sure how to add beams to the notes while keeping the pitch intact. 
> I know I'll obviously need OpenType for this. Slanted beams would be 
> preferred, but straight beams are acceptable. It will need to support beams 
> added on for longer notes. Can someone help me with this?
>  
> I had asked this on a High Logic Font Creator forum (here), and someone said 
> to subscribe to your mailing list and ask you guys. So here I am! Anyway, 
> help, please?

You might want to acquaint yourself with http://www.smufl.org