Closed Bug 288634 Opened 21 years ago Closed 20 years ago

non-ASCII font support in Gfx:Pango and port a couple of other changes in Gfx:Xft to Pango

Categories

(Core Graveyard :: GFX: Gtk, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jshin1987, Assigned: jshin1987)

Details

(Keywords: fixed1.8, intl)

Attachments

(2 files, 1 obsolete file)

Since the fork of Gfx:Pango, there have been a few changes made in Gfx:Xft that need to ported to Pango Gfx. I'm building a pango build with my patch. After testing it, I'll upload a patch here.
Attached patch patch (obsolete) — Splinter Review
I got rid of some duplicated code (nsFontConfigUtils.* are compiled in without this patch so that it's worth to use functions there instead of duping them in nsFontMetricsPango.cpp). As for non-ASCII font name support, somehow it doesn't work. Pango may have to be updated as well? I haven't yet ported 'font-list' support.
Comment on attachment 179348 [details] [diff] [review] patch >- if (!IsASCIIFontName(aFamily)) >- return PR_TRUE; >+ NS_ConvertUTF16toUTF8 name(aFamily); > >- nsCAutoString name; >+ // The newest fontconfig does the full Unicode case folding so that >+ // we're being lazy here by calling |ToLowerCase| after converting >+ // to UTF-8 assuming that in virtually all cases, we just have to >+ // fold [A-Z]. (bug 223653). > name.AssignWithConversion(aFamily.get()); I forgot to remove the above line (|name.AssignWithConversion...|, which is why fonts with the native names didn't work. With the above line removed, the test case in bug 223653 gets rendered as it should be. Asking for r/sr with the above line removed.
Attachment #179348 - Flags: superreview?(dbaron)
Attachment #179348 - Flags: review?(blizzard)
Attachment #179348 - Flags: superreview?(dbaron) → superreview+
Comment on attachment 179348 [details] [diff] [review] patch trying bryner
Attachment #179348 - Flags: review?(blizzard) → review?(bryner)
updated to the trunk. there's a little conflict with the patch for bug 300491 (not in a line changed by this patch but in a line included in the patch as a 'context': pango_xft_get_context -> gdk_pango_context_get). I'll take care of it if this goes after the patch for bug 300491.
Attachment #179348 - Attachment is obsolete: true
Attachment #190231 - Flags: superreview+
Attachment #190231 - Flags: review?(caillon)
Attachment #179348 - Flags: review?(bryner)
ack, looks like the other patch landed, and we want to not share the "xft" name if possible. jshin, can you get an updated patch with the xft-isms removed?
I replaced 'Xft' with 'Gtk'.
Attachment #190828 - Flags: superreview+
Attachment #190828 - Flags: review?(caillon)
Comment on attachment 190828 [details] [diff] [review] patch without 'xft' + NS_ConvertUTF16toUTF8 name(aFamily); - nsCAutoString name; + // The newest fontconfig does the full Unicode case folding so that + // we're being lazy here by calling |ToLowerCase| after converting + // to UTF-8 assuming that in virtually all cases, we just have to + // fold [A-Z]. (bug 223653). name.AssignWithConversion(aFamily.get()); do you really want that AssignWithConversion here? (EnumFontCallback)
(In reply to comment #7) > (From update of attachment 190828 [details] [diff] [review] [edit]) > + NS_ConvertUTF16toUTF8 name(aFamily); > > - nsCAutoString name; > name.AssignWithConversion(aFamily.get()); > > do you really want that AssignWithConversion here? That line should have been removed. Thanks. I fixed that mistake as I wrote in comment #2, but I resurrected it by applying attachment 179348 [details] [diff] [review] to the fresh cvs copy.
Status: NEW → ASSIGNED
ping caillon, can you review it? I've already fixed, in my local tree, what cbie pointed out.
Comment on attachment 190828 [details] [diff] [review] patch without 'xft' r=caillon, sorry for the delay
Attachment #190828 - Flags: review?(caillon) → review+
Comment on attachment 190828 [details] [diff] [review] patch without 'xft' asking for a 1.8b5 this is a patch for non-default build (pango build), but RedHat ships a pango-enabled build in FC/REL so that we'd better fix it before 1.5. It's rather safe (porting what's been available in our default build for a while to Pango build)
Attachment #190828 - Flags: approval1.8b5?
Attachment #190828 - Flags: approval1.8b5? → approval1.8b5+
Comment on attachment 190828 [details] [diff] [review] patch without 'xft' what's the risk to non-pango builds here?
fixed on both 1.8 branch (today) and trunk (Sept. 4th)
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Keywords: fixed1.8
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: