"ASCII"



  • 0_1508694822330_Screenshot_2017-10-22-18-41-23.png


  • Grade A Premium Asshole

    ಠ_ಠ


  • Winner of the 2016 Presidential Election

    @pjh said in "ASCII":

    0_1508694822330_Screenshot_2017-10-22-18-41-23.png

    Inb4 review: "Too bad it's Unicode..."



  • @pjh
    Now if we could change those to animated jif's we might have something


  • SockDev

    @luhmann don't give the Unicode guys any more ideas because I bet in like Unicode 14, they'll be outlining characters that are animated and change rendering over time.



  • @arantor said in "ASCII":

    @luhmann don't give the Unicode guys any more ideas because I bet in like Unicode 14, they'll be outlining characters that are animated and change rendering over time.

    Eh ... at this point we probably should just embed something like postscript or SVG into unicode. It's where things are headed anyway.


  • Fake News

    @arantor Oh, that's simple, just insert a zero-width-join and 🎥 between the emojis.


  • SockDev

    @cvi except it's not. Unicode doesn't mandate a rendering, merely what the codepoints mean and can have a suggested rendering but there is no more to it than that.

    U+0041 for example has a meaning. It means the capital form of the first letter of the Latin alphabet. It has a suggested form which in this particular font is rendered as 'A'. Other fonts will vary the appearance of this glyph, but they won't change its meaning. But for the standard to impose an appearance on a glyph goes beyond the remit of what Unicode is about.



  • @luhmann don't reignite G/Jifgate, for the love of everything holy and my sanity



  • @arantor You are right of course, I wasn't serious about the suggestion (and probably shouldn't have picked ps/svg, I was going for making it programmable [which is also not a suggestion to be taken seriously]. Blame lack of coffee.)

    OTOH, it's getting close to imposing appearance in several places (IMO): there are some geometric shapes (e.g., U+25A0: BLACK SQUARE), which would be silly to render differently (I mean, you could make it non-square, but .... that would be missing the point). Plus there are the skin tone modifiers which I'd argue are also somewhere in between presentation meta-data and meaningful information about a glyph. Then there are characters like U+1F34E (RED APPLE), U+1F34F (GREEN APPLE); while rendering them red/green isn't a requirement, it certainly sounds like a strong suggestion.

    Then again, embedding a rendering language would fix the problem with people missing their favourite glyphs... 🛒


  • SockDev

    @cvi said in "ASCII":

    I was going for making it programmable [which is also not a suggestion to be taken seriously]

    But where's the fun in that? 😈

    @cvi said in "ASCII":

    OTOH, it's getting close to imposing appearance in several places (IMO): there are some geometric shapes (e.g., U+25A0: BLACK SQUARE),

    That particular example is more, I think, poorly named rather than anything else. The block it's part of has a set of 'black' and 'white' characters on the basis of filled vs not-filled rather than anything else. I think if you wrote those glyphs in another colour, they would correctly have the font and background colours that match the idea of 'filled' vs 'not filled' rather than 'black' vs 'white'.

    As for the shape... I'm not so fussed about that. If you're going to define something as a block containing 'geometric shapes', a square is a logical choice. The same block has triangle, rectangle and others. There is some value in having a generic 'this is a square' symbol because there is value in having something fairly abstract that can be reused.

    I guess my issue is more on the broader use factor than on 'it must not infer a shape' per se. On the one hand, we have squares. On the other we have 'rolling on the floor laughing' and 'face with hand over mouth' which have meaning and potentially inferred representations that aren't generic.

    @cvi said in "ASCII":

    Then there are characters like U+1F34E (RED APPLE), U+1F34F (GREEN APPLE); while rendering them red/green isn't a requirement, it certainly sounds like a strong suggestion.

    See, this is something I have a problem with. What would be more logical would be to define an apple and then support colour variations with combining glyphs in the same way skin tones are handled, making them modifiers rather than explicit items.

    Is there a semantic difference between a red and a green apple? If not, it has no place being a discrete character in the set.


  • kills Dumbledore

    @cvi said in "ASCII":

    there are some geometric shapes (e.g., U+25A0: BLACK SQUARE), which would be silly to render differently

    ✴



  • @arantor said in "ASCII":

    That particular example is more, I think, poorly named rather than anything else. The block it's part of has a set of 'black' and 'white' characters on the basis of filled vs not-filled rather than anything else.

    Yeah. I agree with the poor naming, it seems much more of filled/non-filled as you say. Still the square should be square (even in a proportional font), and so on.

    What would be more logical would be to define an apple and then support colour variations with combining glyphs in the same way skin tones are handled, making them modifiers rather than explicit items.

    I kinda agree.

    I guess the problem is that if colour variations were expressed as combining glyphs, there would be the question of what glyphs you're allowed to apply them on. Technically, there's nothing preventing them from being applied to any glyph. You'd then have colorization in Unicode, which may or may not be something desirable. 𝐀𝐟𝐭𝐞𝐫 𝗮𝗹𝗹, 𝘵𝘦𝘹𝘵 𝖿𝗈𝗋𝗆𝖺𝗍𝗍𝗂𝗇𝗀 𝒉𝒂𝒔 no 𝓹𝓵𝓪𝓬𝓮 𝗂𝗇 𝖀𝖓𝖎𝖈𝖔𝖉𝖊.

    Is there a semantic difference between a red and a green apple? If not, it has no place being a discrete character in the set.

    I'm actually a bit curious about the rationale for inclusion. Is there any resource that documents why something is included (or not)? I don't see why the difference would be more significant than something like 0_1508759709754_warnY.png vs 0_1508759751767_warnR.png.


  • SockDev

    @cvi there's already colorisation in Unicode - c.f. the skin tone combinations for faces. There's also specific meaning combinations for flags.

    I don't have a problem with glyphs having semantic meaning even if the typical representation of that meaning happens to look like a letter - this is why we get duplicate-rendered characters that aren't technically the same as other letters, because there's multiple things that render like 'A' even though they have different semantic meanings. That's cool and all, that's what Unicode sets out.

    @cvi said in "ASCII":

    I'm actually a bit curious about the rationale for inclusion. Is there any resource that documents why something is included (or not)?

    I don't think so, at least not for the earlier stuff. That said there's also an amount of compatibility, e.g. things that existed in the old code pages that needed to be extended forward one way or another. Think of all the line drawing characters in CP437 for example. These need to have a representation somewhere in the BMP.



  • @arantor said in "ASCII":

    @cvi there's already colorisation in Unicode - c.f. the skin tone combinations for faces.

    Indeed, but the skin tone combinations are (AFAIK) only valid for the faces. That at least seems like a set that's possible to define. But for general colors (like green, red, or possibly even arbitrary RGB) .. would you restrict them to a certain set of glyphs, or just let them be applied to anything?


  • SockDev

    @cvi I'd restrict them to the codepoints where it makes sense. And I certainly wouldn't make it RGB because rendering is hard - and there's no need to make it needlessly complicated 😉

    I think Unicode has elements of scope creep though...



  • Unicode has all the advantages of being designed by a worldwide committee and all the disadvantages of being designed by a worldwide committee.

    If you're actually curious about the rationale of why certain decisions were made, the archives of the Unicode Mailing List are public, and go back a long way. Good luck finding what you want, but it's probably in there somewhere.



  • @arantor said in "ASCII":

    @cvi I'd restrict them to the codepoints where it makes sense.

    Great. Another table of stuff to lug around and keep updated when "parsing" Unicode. 😉

    Not sure why RGB would that much harder compared to a few discrete colours. In the attempts at rendering unicode I've seen (which are rather basic ones TBF), if there's support for per-glyph colors, there's basically already support for full RGB. But YMMV. (Colorizing just a part of the glyph, as seen in e.g. the apples and in some of the emojis with skin tone, seems much more invasive.)


  • SockDev

    @cvi this is the kind of thing that libraries and language-level support should tackle, not us peons writing higher level code.



  • @arantor I'm a C++ person, mostly. This "language-level support" thing that you mention, what's that? (🚎)

    I've occasionally have to detour into low-level land, so this kind of stuff worries me, because I might end up having to deal with it at some point. (Besides, somebody has to write the libraries too. They have a hard enough time as it is.)


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.