suggest using 512 emojis

[jbenet]

would be nice to compress even more. 512 emojis could be good. Wish there were 1024 to make things easier for us.

[pfrazee]

I did this for a period, but reverted it to keep more convenient bit-boundaries (256 means 1 emoji = 1 byte)

[jbenet]

How do you handle sub-byte ends?

—
Sent from Mailbox

On Sat, Nov 22, 2014 at 11:15 AM, Paul Frazee [email protected]
wrote:

I did this for a period, but reverted it to keep more convenient bit-boundaries (256 means 1 emoji = 1 byte)

Reply to this email directly or view it on GitHub:
#4 (comment)

[pfrazee]

https://github.com/pfraze/base-emoji/blob/master/index.js#L9

Depends on how readUInt8 does it. I'd guess, if there were eg 4 bits at the end, they'd be treated as the least-significant-bits in an 8-bit number.

[jbenet]

@pfraze hm. i guess this is a Buffer limitation. how do sub-byte bufs work in node?

[pfrazee]

@jbenet I'm really just speculating, I'd have to build some tests to give you a good answer. Base-emoji was built on a lark, so I havent been sweating details like that

[dominictarr]

just make the overhanging bytes always be zero, and drop them when converting back into a buffer.
I used that technique in https://github.com/dominictarr/d64 and thus avoided base64's == padding.

[jbenet]

agreed with @dominictarr. (oh man, i hadn't seen d64-- thank you!)

also, i recently did some work on this. turns out we have emoji >1024! see http://www.unicode.org/Public/emoji/1.0/full-emoji-list.html -- some are missing on some platforms (i.e. not rendering now), but i think they will be rendering in the near future (that doc is by reps from both google and apple). So i think we could sort through and pick the 1024 most likely to be supported. we could get some serious hash "visual compression" this way.