Joshix-1

Results 62 comments of Joshix-1
trafficstars

Can confirm, the following doesn't work: ```py async def test_http_server_client_fetch(http_server_client): resp = await http_server_client.fetch("/") assert resp.code == 200 assert resp.body.decode("utf8") == MESSAGE resp = await http_server_client.fetch("/redirect") assert resp.effective_url == http_server_client.get_url("/")...

The same is the case for ⁉️ https://raw.githubusercontent.com/hfg-gmuend/openmoji/master/color/72x72/2049-FE0F.png doesn't work, but https://raw.githubusercontent.com/hfg-gmuend/openmoji/master/color/72x72/2049.png works. I would say the issue is with the names of these files and not with the example...

I used the following python script to check for more emojis with the same issue: The python script needs the following library: https://pypi.org/project/emoji/ I ran it in a folder where...

https://emojipedia.org/variation-selector-16/ > An invisible codepoint which specifies that the preceding character should be displayed with emoji presentation. Only required if the preceding character defaults to text presentation. If I interpret...

Same representation after posted (GitHub embedding an image ): ![Posted](https://user-images.githubusercontent.com/57299889/179411319-28ca52a1-b8cf-460f-8277-7e76682b22f8.png) Different representation while editing (Noto Color Emoji): ![While editing](https://user-images.githubusercontent.com/57299889/179411325-105c8bd7-1b04-4b4d-9a5c-945557745bf3.png) GitHub doesn't care about the FE0F, but I don't think that...

Github even removes the fe0f for longer emoji sequences: Works: https://github.githubassets.com/images/icons/emoji/unicode/1f64b-1f3fb-200d-2642.png 404: https://github.githubassets.com/images/icons/emoji/unicode/1f64b-1f3fb-200d-2642-fe0f.png OpenMoji has it with -FE0F: https://raw.githubusercontent.com/hfg-gmuend/openmoji/master/color/72x72/1F64B-1F3FB-200D-2642-FE0F.png The emoji on emojipedia: https://emojipedia.org/man-raising-hand-light-skin-tone/ (just chose a random longer emoji...

If I look at https://github.com/hfg-gmuend/openmoji/releases/download/14.0.0/openmoji-font.zip In the demo.html `☮` and `☮️` are displayed the same way if I type them in the textarea. (first without FE0F). That seems like another...

🏳️ would break too as it is saved as 1F3F3-FE0F https://raw.githubusercontent.com/hfg-gmuend/openmoji/master/color/72x72/1F3F3-FE0F.png If it doesn't really matter if it is a real emoji, wouldn't it be better to do it like...

Another issue with the code I just noticed is, that it e.g. doesn't work with https://openmoji.org/library/emoji-0035-FE0F-20E3/ (The leading 0s are missing) Fix for python: ```py "-".join(f"{ord(c):04x}" for c in emoji).upper()...

> For me, it does not break, I could also find this one: https://raw.githubusercontent.com/hfg-gmuend/openmoji/master/color/72x72/1F3F3.png Yes, true (I just looked for files ending with -FE0F and didn't check if it is...