Anything we’d be interested in? I like hieroglyphs.
Forget the phallus hieroglyphs, I’m more interested in the “tiny man holding a DIP microchip” hieroglyph http://graphemica.com/𓀨/glyphs/aegyptus-regular
Ancient aliens CONFIRMED!
If you extrapolate Moore´s law backwards in time chips must have been really huge back then.
egyptian reggae
Dear Commentors:
Anansi1333 asked about the two-hieroglyph combination at 130B9. Obviously one is a phallus. The other one is the hieroglyph for a folded cloth, and it also means the letter sound “s”( https://discoveringegypt.com/egyptian-hieroglyphic-writing/egyptian-hieroglyphic-alphabet/). Having looked that all up, I don’t know what the combination of a phallus and folded cloth might have meant. Maybe it was posted at the public steam rooms to remind everyone to wear a towel, but I’m not sure the Ancient Egyptians had a lot of problems with nudity, as well as not being sure they had public steam rooms.
But, really, croquet hoop, eh? I 13AE2 my eyes! (page 33, row 2, column 11)
Leila
Is there a (direction of writing) character or do the have separate characters for left to right vs right to left writing?
They have both the left-to-right mark (U+200E) and the right-to-left mark (U+200F). You can do all sorts of stuff; at the cost of making a Unicode implementation pretty hairy if feature complete.
So I guess they consider the reversed glyphs for writing right to left “presentation forms” not worthy of separate encoding. I suppose that’s the way to go, although it might make quoting a short bit written right to left more complicated. But then, that is ALWAYS complicated.
This is what the “symbola” font was created for. The idea is that it’s not necessarily pretty, but it implements as much of the standard as possible so that you can use it as a fallback. I had to install it ages ago so that I could have phoenician support.
At this rate, Unicode is going to become a rainbow table for human doodlings.
/s
Thanks. I will take a look.
I expect these will be a ingredient in the next “shortish phrase that crashes all [os type] phones”. This seems to be way to complex to implement.
Nothing in the proposal has “interesting” (aka complex) encoding or presentation rules. I didn’t see any presentation rule changes at all, and all the encodings are straightforward. It has a lot of text dedicated to how they picked which numbers represent what glyph, and why they decided to pick some glyphs to represent and others to leave out of Unicode (at this time).
It is basically “here are a few thousand glyphs with names and example illustrations that we want”, none of the complex “this is how the letter form changes when found near this other sequence” that all the “shortish string that can crash an iPhone” exploits have used.
That’s no promise that there isn’t something in there, or that it won’t somehow interact with existing complexity in some weird way…
…but I think this is less a threat to my iphone’s Uptime, and more a threat to the legibility of my personal Swift code.
And it looks like they have “cartouche begins” and “cartouche ends” characters…
They’ll still refuse to let the Tolkien scholars have their Middle Earth characters though.
Given that Unicode is pretty serious (at least when sticking to principles) about attempting to keep glyphs as assigned codepoints distinct from visual representation (not just in the “FFS people! The font in our document is just a placeholder, not normative!”; but in things like “‘GREEK CAPITAL LETTER DELTA’ (U+0394)” being treated as wholly distinct from “‘MATHEMATICAL BOLD CAPITAL DELTA’ (U+1D6AB)” because the two have completely different meaning despite the latter being a straight appropriation of the former) I would imagine that “reversed glyph” would be a distinct thing from “switch to right-to-left”(though it would still most properly be a modifier, rather than a whole bunch of mirror-mirror codepoints; since the Unicode way is supposed to be doing things by composition rather than addig scads of additional primitives, where possible): “reversed glyph” would just mean rendering that character backwards without other modifications; while switching to right-to-left means adopting the relevant conventions for left vs. right justification and anything else that makes a right-to-left language distinct from left-to-right with the symbols backwards.
For very short snippets, not long enough to trigger any of the additional rules, having a stash of backwards glyphs would be a hack that makes that case a lot simpler; but it would lead to messiness in other respects (probably most annoyingly having both right-to-left and reversed-glyph-hack would mean that apparently identical strings wouldn’t match at all; copy/paste behavior would also get pretty freaky if you had to start inferring when to automagic the snippet into reverse glyphs and when to keep it as is but surround with the appropriate direction reversals).
Doesn’t make life easier for the renderer; but when your scope is “encoding” there’s an argument to be made against the sort of hacks that would be just fine if you knew that the output was heading straight to the printer, because you haven’t the slightest reason to believe it is; and a result where things like string comparison breaks down would not be good.
Clearly IDN-enabled URLs are going to get more fun. No need for a boring .name or cash-grubbing .me when you can do it the old fashioned way.
But the direction that the character is facing IS dependent on the direction that the line is being written. so there’s no need for separate (mirror the following character) code point.
I assume that the use case is embedding fragments too short for line-level language direction to apply; but it looks like they do have support for ‘right-to-left override(U+202E)’ and ‘left-to-right override (U+202D)’, so you can both modify the declared direction of the language you are writing in and mirror specific bits of it.
Handy for visual confusion and entertaining spoofing attacks Legitimate_Documentfdp.exe
The real question is, why didn’t we get this first?