{"action":"created","issue":{"url":"https://api.github.com/repos/w3c/i18n-discuss/issues/2","repository_url":"https://api.github.com/repos/w3c/i18n-discuss","labels_url":"https://api.github.com/repos/w3c/i18n-discuss/issues/2/labels{/name}","comments_url":"https://api.github.com/repos/w3c/i18n-discuss/issues/2/comments","events_url":"https://api.github.com/repos/w3c/i18n-discuss/issues/2/events","html_url":"https://github.com/w3c/i18n-discuss/issues/2","id":188566286,"number":2,"title":"Use of ZWJ","user":{"login":"r12a","id":4839211,"avatar_url":"https://avatars.githubusercontent.com/u/4839211?v=3","gravatar_id":"","url":"https://api.github.com/users/r12a","html_url":"https://github.com/r12a","followers_url":"https://api.github.com/users/r12a/followers","following_url":"https://api.github.com/users/r12a/following{/other_user}","gists_url":"https://api.github.com/users/r12a/gists{/gist_id}","starred_url":"https://api.github.com/users/r12a/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/r12a/subscriptions","organizations_url":"https://api.github.com/users/r12a/orgs","repos_url":"https://api.github.com/users/r12a/repos","events_url":"https://api.github.com/users/r12a/events{/privacy}","received_events_url":"https://api.github.com/users/r12a/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":9,"created_at":"2016-11-10T17:12:40Z","updated_at":"2016-11-23T07:39:22Z","closed_at":null,"body":"[Comment by @ntounsi]\r\n\r\nWhat is the spec of the zero-width joiner?\r\n1) Unicode-Ch9, Sec 9.2 Arabic, p371 (http://www.unicode.org/versions/Unicode9.0.0/ch09.pdf) says:\r\n\"... The use of a joiner **adjacent to a suitable** letter permits that letter to form a cursive connection without a **visible neighbor**.\" and gives a use case \"This provides a simple way to encode some special cases, such as exhibiting a connecting form in isolation.\" \r\n\r\nGuess that \"suitable letter\" means those letters who join according to their writing system (e.g. Aleph doesn't join to it's left in Arabic).\r\nBut what \"adjacent\" mean? At the right, left or both?\r\n\"without a visible neighbor\" : what about no visible member next? A visible member but separated by space, say? \r\nTo support the definition, Unicode gives an example of a special case with letter HEH and shows what ZWJ means for that special case. \r\n\r\n2) Wikipedia informal définition says: \r\n \"When placed **between** two characters that **would** otherwise not be connected, a ZWJ causes them to be printed in their connected forms.\"\r\nMore explicit but (only?) \"between\" two letters. When \"would\" they be not connected.  What are those situations?\r\n\r\nAny way, browsers implementation of ZWJ differs from one another. I noticed that browsers (based Gecko vs. based Webkit) display depends on\r\n- font used (some fonts seem to react better), \r\n- What letter is neighbour, even if separated by a space \r\n- base direction rtl or ltr (!?)\r\n\r\nAlso, letter Ghain behave differently than letter Heh, though they both have four different shapes: initial, medial, final and isolated. \r\nMoreover, Gecko implementation is right for \"colored letters\" within a word (they join). But ZWJ applied to only one letter works better in Webkit implementation : all the four shapes show up ."},"comment":{"url":"https://api.github.com/repos/w3c/i18n-discuss/issues/comments/262449820","html_url":"https://github.com/w3c/i18n-discuss/issues/2#issuecomment-262449820","issue_url":"https://api.github.com/repos/w3c/i18n-discuss/issues/2","id":262449820,"user":{"login":"duerst","id":815565,"avatar_url":"https://avatars.githubusercontent.com/u/815565?v=3","gravatar_id":"","url":"https://api.github.com/users/duerst","html_url":"https://github.com/duerst","followers_url":"https://api.github.com/users/duerst/followers","following_url":"https://api.github.com/users/duerst/following{/other_user}","gists_url":"https://api.github.com/users/duerst/gists{/gist_id}","starred_url":"https://api.github.com/users/duerst/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/duerst/subscriptions","organizations_url":"https://api.github.com/users/duerst/orgs","repos_url":"https://api.github.com/users/duerst/repos","events_url":"https://api.github.com/users/duerst/events{/privacy}","received_events_url":"https://api.github.com/users/duerst/received_events","type":"User","site_admin":false},"created_at":"2016-11-23T07:39:22Z","updated_at":"2016-11-23T07:39:22Z","body":"@khaledhosny: You said \"I think it might indeed be related to bidi itemisation, since browsers will itemize the text first into runs with the same direction before doing the shaping, so the ZWJ might end in the wrong run.\"\r\nShouldn't a ZWJ ideally be included in both runs (not necessarily for reordering, but before being sent to rendering) if it falls on a run boundary? That's probably not what the Bidi algorithm says. But the Bidi algorithm is about ordering, and ZWJ has nothing to do with ordering. On the other hand, ZWJ is about shaping, and is defined (as far as I understand) to work logically."}}
{"actor":{"display_login":"duerst"}}