Issue 110722 - vcl: use language for default font lookup through fontconfig
Summary: vcl: use language for default font lookup through fontconfig
Status: CLOSED FIXED
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: DEV300m75
Hardware: All Unix, all
: P3 Trivial with 2 votes (vote)
Target Milestone: OOo 3.3
Assignee: hdu@apache.org
QA Contact: issues@gsl
URL:
Keywords:
Depends on:
Blocks: 112623 112739
  Show dependency tree
 
Reported: 2010-04-09 13:07 UTC by dtardon
Modified: 2010-09-27 15:09 UTC (History)
2 users (show)

See Also:
Issue Type: PATCH
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
like this (1.57 KB, patch)
2010-04-09 13:07 UTC, dtardon
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description dtardon 2010-04-09 13:07:13 UTC
When I run oowriter in or_IN locale on Fedora, the default document should be
Lohit Oriya. Instead, it's DejaVu Sans, even if Lohit Oriya is installed and is
in oo.o's font configuration for or-IN. The problem is Lohit Oriya happens to be
on second position in the configuration list, behind utkal, which is not
available. Therefore fontconfig returns best match for utkal, which, without
specifying language, is DejaVu Sans.

The attached patch enables to use language for fontconfig matching and sets it
up for looking up default fonts.
Comment 1 dtardon 2010-04-09 13:07:59 UTC
Created attachment 68831 [details]
like this
Comment 2 hdu@apache.org 2010-04-27 12:26:49 UTC
Of course utkal has no resemblance whatsoever with DejaVu-Sans, so I'm wondering why fontconfig 
requests this substitution. If there was a way to find out the certainty of such a substitution or other 
interesting details such as invariances in the substitutions then this would help a lot to avoid such 
problems.

Anyway, I "hg qpushed" the patch into CWS vcl111, thanks!
Comment 3 hdu@apache.org 2010-05-17 15:56:30 UTC
.
Comment 4 hdu@apache.org 2010-06-22 09:11:38 UTC
Got into DEV300_m83 => closing
Comment 5 cno 2010-09-27 10:38:14 UTC
since this causes 
   issue 112623 
   issue 114608 
I reopen.
Comment 6 cno 2010-09-27 15:07:24 UTC
The problem is fixed with issue 114703
Comment 7 cno 2010-09-27 15:09:01 UTC
and close again