Open keianrao opened 4 years ago
keianrao
commented
4 years ago Actually, the last group isn't all composed of ZWJ sequences. There's a lot of sequences here that don't have the ZWJ, but are still supposed to combine into one emoji. Primarily, the skin tone modifier.
I'm not sure why the fonts don't join them, and I'm not sure how joining even works for these sequences. Is it a thing where the text widget itself has to notice and support?
keianrao
commented
4 years ago By the by. Emoji are differentiated by a 'text' rendering and an 'emoji' rendering. So far, all fonts have given a black-and-white text rendering, including Noto Color and Twemoji.
I won't treat that as an issue since (1) they look fine anyways, and (2) I don't think it's something we can control. (Save for giving up on assembling the Unicode from the data files, then setting that as the JButton label. In favour of creating our own table where we map each emoji to an image file)
keianrao
commented
4 years ago The specific thing we want to support, first, is emoji modifiers.
They mentioned, that having them as separate characters is the 'internal representation'. Which suggests that what our program is doing right now, storing them as separate characters, is correct
keianrao
commented
4 years ago Point 2 for section 1.5 'Conformance', in UTS #51, talks about software having certain capabilities with regards to emoji. That is to say, software specifically implements emoji support.
My suspicion is that, (1) Java Swing's text-rendering components (JTextField and JButton/JLabel in our case) don't have support for emoji. And (2) we still can see, and copy, emoji, because our strings are still a series of codepoints, and whatever font we use can at least render anything that's a qualified character. So even though a skin tone modifier character is meant to be joined into a modifier base emoji. It's something that can be rendered on its own so it shows up on our screen, as opposed to being invisible/garbled.
keianrao
commented
4 years ago If we were rendering with PNG files, then this wouldn't be a problem. As we build up each JButton, we can set a single emoji as its icon, based on the sequence of code points it has.
The pickup field would be trickier, either we give up there (since it's meant for selecting to copy, not for looking at), or we implement our own text field that renders emoji properly. Which isn't an impossible task..
But, we have no PNG files, we are relying 100% on how Java and our fonts conceptualise text.
The emoji that aren't being rendered properly can be split into three groups:
Emoji that are larger than can fit in the JButton, so it gets cutoff somehow. These are the easiest, just adjust all the sizes so that they fit. Not to mention when you click on them to copy them into the pickup text field, they look fine there.
Emoji that the current font doesn't have support for. These are plain tofu. This isn't much of an issue either, just change the font (I actually tried a variety of DFSG-compliant fonts. Their coverage are all good, but each had their own few missing emoji)
ZWJ sequences. These, they look like multiple characters in the JButton, and when you copy them they appear as separate glyphs. Though when you move your keyboard cursor through them, you can notice the invisible zero-width joiner. And if you copy it to somewhere on Firefox, it can turn out fine (combined into one emoji). Or not.
The first two groups, I've already confirmed that it's not a programming error on my part, they're just font problems. But the last group is both tricky to support, and possibly not rendering correctly because of my fault.
I tried a community TTF build of Twemoji - the font that Firefox uses to render emoji - on this app, and it wiped out all the tofu. But the not-joining ZWJ sequences were still there.