[webkit-reviews] review requested: [Bug 16131] ZWNJ - Display non-printing, invisible character : [Attachment 51156] Updated patch with code moved to GlyphPageTreeNode::initializePage()

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Mar 19 08:29:56 PDT 2010


David Yonge-Mallo <davinci at chromium.org> has asked  for review:
Bug 16131: ZWNJ - Display non-printing, invisible character
https://bugs.webkit.org/show_bug.cgi?id=16131

Attachment 51156: Updated patch with code moved to
GlyphPageTreeNode::initializePage()
https://bugs.webkit.org/attachment.cgi?id=51156&action=review

------- Additional Comments from David Yonge-Mallo <davinci at chromium.org>
I've moved the code to GlyphPageTreeNode::initializePage().  The patch now
makes the treatment of ZWNJ and ZWJ consistent with other Unicode format
control characters such as LRM and RLM.

How would a user access the glyphs for ZWNJ and ZWJ in situations where they
should actually be displayed, such as for editors or IMEs?  I'm not sure what
the correct display behaviour is for format control characters when they are
typed into edit fields.  The patch suppresses their display, which is
consistent with how the other control characters currently behave.

The reason I added a check for Arabic presentation forms is because they should
be handled by the complex font path.  It relates to the bug in that ZWNJ and
ZWJ are not handled correctly for Arabic script when the presentation forms are
used.  Some web pages are encoded using the presentation forms (even though
that goes against Unicode's rules), and without the check they don't shape
(apply ZWJ and ZWNJ) properly.	

If this bug is restricted to just the *visibility* of the ZWNJ and ZWJ
*glyphs*, as opposed to the correct handling and display of ZWNJ and ZWJ more
generally, I can create a new bug report for the other situations.


More information about the webkit-reviews mailing list