[Webkit-unassigned] [Bug 13136] Spurious glyphs in Google Israel and Gmail (all languages)

[bugzilla-daemon at webkit.org]

http://bugs.webkit.org/show_bug.cgi?id=13136





------- Comment #11 from mitz at webkit.org  2007-03-22 00:11 PDT -------
(In reply to comment #8)
> I guess that means nothing is done about  BiDi control characters (LRM, RLM,
> LRE, RLE, PDF. yes, they'd better not be used in html, but some documents use
> them)? In other words, do they have impact on the directionality of text layout
> in WebKit?

Yes. They are honored by the bidi algorithm implementation in WebCore.
LRE/RLE/LRO/RLO and PDF are not passed down to the font rendering routines.

> Or, does it pass them down so that ATSUI (complex path) can take
> care of them on Mac OS X?

No. All bidi processing is done at the WebCore level, and text gets broken down
to unidirectional runs that get passed down to the rendering code.

> My assumption was that if the page author specified those characters to be
> rendered by a specific fonts,  those characters in group (b) (e.g. Hebrew vowel
> signs) would be rendered well by the font. 

I guess I need to know more about what each of those groups contain (I had no
idea that Hebrew vowels were included). In the RLM example, the author
specified Arial, a font that contains a visible RLM glyph, but did not expect
it to render (since the author's experience with WinIE and Firefox is that RLM
is hidden). If a WebKit user happens to have the same font (the Microsoft
version of Arial), it will be selected and the RLM will be visible, contrary to
the intention of the author. I think this should be avoided.

Similarly for ZWJ and ZWNJ, despite their effect on the rendering of
neighboring characters, if they do not render visibly when the author specifies
Arial on WinIE or Firefox, then WebKit should not render them.

> Even if that's not the case, a font claiming to have glyphs for them are likely
> to have "acceptable" (could be far-from-optimal as in Arial) glyphs.  Because
> 'truly invisible' characters in group (a) are turned to 'zero-width' glyph
> higher up in the code path, using these 'acceptable' (fallback) [1] glyphs for
> group b (perhaps, we need to give more thoughts to how to divide two groups)
> would make more sense than just using 'last resort' glyph (a box with a symbol
> representing a script, or a hollow box or question mark.) 

That is already how WebKit works: if a font has a certain character mapped to a
glyph -- possibly an empty one -- then depending on the character, either that
glyph is used, or the zero-width space glyph is used (as is currently done with
the U+0000..U+001F range for example). A "last resort" glyph (or a glyph from a
different font) is used only in cases where the original font does not have a
mapping for the character. For example, in the screenshots, the version of
Arial the user has contains a (non-empty) glyph for LRM, and that's what's
used. If Arial did not map LRM to any glyph, font fallback would occur, going
through the specified family list (followed by a fallback font suggested by the
OS), and the (probably empty) LRM glyph from the first font that has it mapped
would be used.


-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.