3 ms·

Could someone please explain when it would be preferable to send a 72x72 PNG to the Unicode standards body, wait for them to accept it into their standard, wait

Could someone please explain when it would be preferable to send a 72x72 PNG to the Unicode standards body, wait for them to accept it into their standard, wait for applications/OSs/etc. to implement these new standards, and then send a message using the new glyph; compared to just embedding the 72x72 PNG in a message right now; as a data URI, a regular URL with a pre-populated local cache, whatever?

skriticos2 11y ago
Because afterward you only need to send about 4 bytes, instead of multiple KB, because the other end already has the image and just needs the serial?
- RIMR 11y ago
  >Because afterward you only need to send about 4 bytes, instead of multiple KB So much wasted time waiting for all those kilobytes to finish downloading...
- chriswarbo 11y ago
  URIs are a perfectly valid "serial", and only need a few bytes (e.g. see URL shorteners). Receivers can look up images in a cache before trying to download them, and caches can be pre-populated with thousands of popular images, by OS vendors, application providers, users, etc.
lotu 11y ago
For that matter why bother having a text encoding at all? We could just send pictures of text to each other right?
- chriswarbo 11y ago
  > For that matter why bother having a text encoding at all? We could just send pictures of text to each other right? This is of course a straw man which has nothing to do with my question. However, it's not actually clear what you mean. If you mean that we could make small pictures of individual characters and send those, well that's exactly what text encoding is; it's an implementation detail whether we specify a character as a unicode code point, or a URI (possibly relative, to allow fonts as namespaces). If you mean sending one big picture of a piece of text, well that's what already happens. Rather than using PNG, we can get better quality and compression ratio by using the "plain text" image format. This only works well when we know that the image only contains text, otherwise we lose a lot of quality (e.g. see http://www.asciiworld.com http://www.asciiworld.com )

skriticos2 11y ago

Because afterward you only need to send about 4 bytes, instead of multiple KB, because the other end already has the image and just needs the serial?

RIMR 11y ago
>Because afterward you only need to send about 4 bytes, instead of multiple KB So much wasted time waiting for all those kilobytes to finish downloading...
chriswarbo 11y ago
URIs are a perfectly valid "serial", and only need a few bytes (e.g. see URL shorteners). Receivers can look up images in a cache before trying to download them, and caches can be pre-populated with thousands of popular images, by OS vendors, application providers, users, etc.

lotu 11y ago

For that matter why bother having a text encoding at all? We could just send pictures of text to each other right?

chriswarbo 11y ago
> For that matter why bother having a text encoding at all? We could just send pictures of text to each other right? This is of course a straw man which has nothing to do with my question. However, it's not actually clear what you mean. If you mean that we could make small pictures of individual characters and send those, well that's exactly what text encoding is; it's an implementation detail whether we specify a character as a unicode code point, or a URI (possibly relative, to allow fonts as namespaces). If you mean sending one big picture of a piece of text, well that's what already happens. Rather than using PNG, we can get better quality and compression ratio by using the "plain text" image format. This only works well when we know that the image only contains text, otherwise we lose a lot of quality (e.g. see http://www.asciiworld.com http://www.asciiworld.com )