srl295
commented
6 years ago 2.1 Representing the emoji
The proposal envisions a single name field. At a minimum, it should provide a language tag. Better would be a map <language tag, name in language>.
- [ ] Good idea -TODO
2.2 Secure hash
Including the name seems like a mistake; it should be possible to fix name typos and to add names in additional languages. Hashing the entire "description" would also be sensitive to adding any other metadata. I suggest hashing only the binary image data. Including the content-type would be harmless but redundant and seems unnecessary. Hashing the base64 form rather than the binary is unnecessary as well.
- [ ] I think this is also good… just hash on the image itself.
2.3 Code points allocated to express the secure hash
How about a compromise? Set aside 0x100 or 0x1000 code points for this scheme. Maybe they could even remain "reserved" like noncharacters, with gc=Cn? Or use a range of Plane 16 PUA codes?
In discussion, just using regular hex characters, or perhaps base64, might make more sense with either normal markup or a special 'start/end' or some kind of tag might be a way forward
Such as:
<SG93IGFib3V0IHNvbWUgQ0hBSQo=>(using less than, greater than around some regular ascii te), or perhaps:⫷SG93IGFib3V0IHNvbWUgQ0hBSQo=⫸— using some other character (that could be a PUA to start with)
and using tags:
☕️_SG93IGFib3V0IHNvbWUgQ0hBSQo✦ (whereSG93…are tag characters and✦is tag_term), or perhaps:☕️0_✦SG93IGFib3V0IHNvbWUgQ0hBSQo. (where 0 is some version number tag,✦is tag_term, and a base64 hash followed by ". "follows.
or using higher level protocol:
<chai>SG93IGFib3V0IHNvbWUgQ0hBSQo</chai>
(Do avoid the actual xFFFE & xFFFF noncharacter code points -- the original proposal for using 64k code points would probably have used two of those.)
The original proposal explicitly avoided those.
2.5 Receiving and rendering a CHAI
Please specify the display size of the image when rendered. I assume that it should always be shown in the aspect ratio of the image data. What about height or width?
It would be according to the embedded png
Emoji are typically shown with square bounding boxes and something like "text height". (Not sure what that means -- as high as a CJK ideograph? What font/ascender/descender metric is or should be used? Maybe Unicode need not be that specific.)
What if the image is not square? Scale the image to that height and find out how wide it gets? (Someone could create a very wide image.)
I believe that stickers are often larger than Emoji. Do we need modifiers that specify a scaling factor relative to the text height, some number of some fractions of normal height?
Size should be part of a higher level protocol. I think the point here is ""plain text"" (in scare quotes), so emoji size.
https://www.unicode.org/cgi-bin/GetMatchingDocs.pl?L2/16-379