Closed Bug 1330389 Opened 7 years ago Closed 7 years ago

Improper Rendering Of U+0525 (ԥ)

Categories

(Core :: Layout: Text and Fonts, defect)

Product:
Core
Component:
Layout: Text and Fonts
Version:
50 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla53
Tracking Flags:
Tracking Status
firefox53 --- fixed

People

(Reporter: chrisjbarth, Assigned: jfkthame)

References

Details

Attachments

(2 files)

1330389.html
170 bytes, text/html
Details
CoreText font fallback on macOS may choose one of the 'hidden' system fonts, so we need to check that list when looking for the corresponding gfxFontFamily
1.53 KB, patch
jrmuizel
: review+
Details | Diff | Splinter Review 
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36

Steps to reproduce:

<!DOCTYPE html>
<html>

<head>
	<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>

<body>
	<span>ԥ&#1317;</span>
</body>

</html>


Actual results:

Two box glyphs are shown. The same box glyph is shown no matter if the literal ԥ character in in the file or the escape sequence.


Expected results:

The correct glyph should be shown both times (it does on every other browser).
Attached file 1330389.html — 

    
  
Component: Untriaged → Layout: Text
Product: Firefox → Core

    
    

    
  
Curious. Looks like a font fallback failure.

Please try this: go to about:config, search for the setting "gfx.font_rendering.fallback.always_use_cmaps" (just type "cmaps" in the search field at the top to filter the list of settings), and then double-click to toggle its value to "true" (it's false by default). Then quit and restart the browser. Does that make a difference?
Flags: needinfo?(chrisjbarth)

    
    

    
  
Changing the cmaps value fixes the issue for both the UTF8-encoded and the escaped character.

    
    

    
  


  
OK, I see what's happening here. When we ask Core Text to find a fallback font for the given text, it can return one of the macOS system fonts that we don't expose in the general font list, and so FindFamily() fails. We need to use FindSystemFontFamily() instead so that the 'hidden' fonts will also be available to the fallback code here.

        Attachment #8826180 -
        Flags: review?(jmuizelaar)

    
  
Assignee: nobody → jfkthame
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

    
    

    
  
Comment on attachment 8826180 [details] [diff] [review]
CoreText font fallback on macOS may choose one of the 'hidden' system fonts, so we need to check that list when looking for the corresponding gfxFontFamily

Review of attachment 8826180 [details] [diff] [review]:
-----------------------------------------------------------------

Can we have a reftest?

        Attachment #8826180 -
        Flags: review?(jmuizelaar) → review+

    
    

    
  
I'm not sure how to do a (reasonably robust) test here, given that this is about system- and installed-font-dependent fallback behavior that is basically a "black box" to us.

    
    

    
  
https://hg.mozilla.org/integration/mozilla-inbound/rev/60eddecfd12de63fc795515d24977b43e5148619
Bug 1330389 - CoreText font fallback on macOS may choose one of the 'hidden' system fonts, so we need to check that list when looking for the corresponding gfxFontFamily. r=jrmuizel

    
    

    
  
https://hg.mozilla.org/mozilla-central/rev/60eddecfd12d
Status: ASSIGNED → RESOLVED
Closed: 7 years ago

          status-firefox53:
          --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla53

    
  
Flags: needinfo?(chrisjbarth)

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: