[Bug 1054204] Re: Libreoffice chooses incorrect font weight
Bug Watch Updater
1054204 at bugs.launchpad.net
Thu Oct 11 12:57:54 UTC 2012
Launchpad has imported 9 comments from the remote bug at
https://bugs.freedesktop.org/show_bug.cgi?id=38737.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
------------------------------------------------------------------------
On 2011-06-28T01:28:34+00:00 Paul Sladen wrote:
Truetype/Opentype files have various sets of metadata, not all of which
can be directly queried/matched via FontConfig.
In particular, both the OpenStep and CSS font-matching schemes require
the "PostScript name" as the canonical form of first attempt:
http://www.w3.org/TR/css3-fonts/#ltfont-face-namegt
"the unique name used with local() specifies a single font, not an entire font family. Defined in terms of OpenType font data, the Postscript name is found in the font's name table, in the name record with nameID = 6 (see [OPENTYPE] for more details). The Postscript name is the commonly used key for all fonts on OSX and for Postscript CFF fonts under Windows. The full font name (nameID = 4) is used as a unique key for fonts with TrueType glyphs on Windows."
Previously patch(es) were offered by Isaiah Beerbower and Evgeniy
Stepanov:
http://lists.freedesktop.org/archives/fontconfig/2008-June/thread.html#2957
http://lists.freedesktop.org/archives/fontconfig/attachments/20080605/c063ded6/attachment.diff
but these do not appear to have been replied. A request is made during
the conversation to file a bug and attach the files.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1054204/comments/0
------------------------------------------------------------------------
On 2011-06-28T06:43:13+00:00 James H. Cloos Jr. wrote:
I also posted an RFD patch to cache and match on the postscript name.
It, too, was ignored.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1054204/comments/1
------------------------------------------------------------------------
On 2011-06-28T06:48:05+00:00 Paul Sladen wrote:
James: do you have a link to your version of the patch too?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1054204/comments/2
------------------------------------------------------------------------
On 2011-06-28T07:05:21+00:00 Freedesktop wrote:
James, feel free to fork fontconfig. I encourage that. If and when
distros pick up your tree, I'll hand you the fdo tree. That's what I
did to Keith afterall. Don't sound apologetic!
Reply at:
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1054204/comments/3
------------------------------------------------------------------------
On 2011-06-28T07:09:43+00:00 Freedesktop wrote:
Note that any patch to add this has to address the interaction between
searching by postscript name and family name. Just adding the
postscript name to the pattern and putting it in a random place in the
matcher is easy. Making sense of how this feature is to be used is
something I haven't seen anyone answering so far.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1054204/comments/4
------------------------------------------------------------------------
On 2012-09-27T15:11:46+00:00 Freedesktop wrote:
Akira, can you update this bug with your latest plans?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1054204/comments/12
------------------------------------------------------------------------
On 2012-09-28T12:25:52+00:00 Akiro wrote:
Well, still thinking how to address comment#4 though, the ideas I have
so far is:
For cache:
* the change in FcFreeTypeQueryFace(): in case any fonts doesn't have TT_NAME_ID_PS_NAME, generate PS-compliant name from the family name as the printing libraries do.
For match:
* the change in FcNameParse(): we could add some code to guess if the string is more likely to be the family name or PostScript name from the existence of '-', ' ', and '-H', or '-V' as the suffix etc. set it to FC_FAMILY and/or FC_POSTSCRIPT_NAME. in some case, pre-lookup for that name may be a good idea? because it would be easy to write the mathing rules if we are sure either of the values points to the correct value. otherwise one who is responsible to maintain the rule needs to write the complicated (or duplicated) rules to match either of FC_FAMILY or FC_POSTSCRIPT_NAME then. or think about the syntax to achieve the rule like:
If pat['family'] == 'Courier' or pat['postscript'] == 'Courier' then
something
* in FcNameParse() or in fcstr.c and fclang.c:
* any function to guess the language from CMap if any.
* a special comparison mode or attribute to ignore the suffix string
like CMap. or should it be done with the above idea at pre-stage?
There should be more we need to think about, but just to share current idea.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1054204/comments/13
------------------------------------------------------------------------
On 2012-09-28T13:01:01+00:00 Paul Sladen wrote:
Akira, thanks for the update!
One thought I'd like to add, regarding the synthesis of missing data; is
that when it comes to /debugging/ font-related issue, a large percentage
of the (invalid) issues relate to sythesis and substitution occuring in
FC or the toolkits. It is often the difficulty in seeing past where the
sythesis (or simplification) of data is occuring, that hampers the
debugging.
Thus, it might arguably be better to cleanly /fail/ if a request is made
for a TT_ attribute that doesn't exist (such as TT_NAME_ID_PS_NAME),
than to return something that wasn't or isn't there.
Perhaps the printing issue highlighted (where synthesis of missing
attributes is needed) could be covered with a helper function of
something like ReturnUniqueNameAsPostscript(). Such a function() (or
ENUM) could then return the TT_NAME_ID_PS_NAME if it exists, or make
something up. But in both cases, without obscuring the ability of an
application /that cares/ to uniquely query or get the raw data.
Does that make sense? I'm happy to expand on the above if not.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1054204/comments/14
------------------------------------------------------------------------
On 2012-09-28T14:30:37+00:00 Akiro wrote:
Well, I know there are some request of additional APIs like FcFontMatch
and FcFontSort without the substitution. we should deal with it as a
separate bug or RFE IMHO.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1054204/comments/15
** Changed in: fontconfig
Status: Unknown => Confirmed
** Changed in: fontconfig
Importance: Unknown => Wishlist
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to fontconfig in Ubuntu.
https://bugs.launchpad.net/bugs/1054204
Title:
Libreoffice chooses incorrect font weight
Status in Fontconfig - Font Configuration Library:
Confirmed
Status in Ubuntu Font Family:
Confirmed
Status in “fontconfig” package in Ubuntu:
New
Status in “libreoffice” package in Ubuntu:
Confirmed
Status in “ubuntu-font-family-sources” package in Ubuntu:
Fix Released
Status in “fontconfig” source package in Quantal:
New
Status in “libreoffice” source package in Quantal:
Confirmed
Status in “ubuntu-font-family-sources” source package in Quantal:
Fix Released
Bug description:
How to fix the problem:
See comments on wrong "Ubuntu Light" font family being specified in
the information of Ubuntu-M.ttf.
You can fix the problem manually by installing fontforge program,
going to Open dialog, navigating in it to /usr/share/fonts/truetype
/ubuntu-font-family/ and opening Ubuntu-M.ttf. In Element -> Font
Info, you can fix the family on the first page, and then export the
font with File -> Generate Fonts, selecting the type "TrueType". Save
to somewhere in your home folder first, accept the warnings, then in a
terminal window / command line type:
sudo mv Ubuntu-M.ttf /usr/share/fonts/truetype/ubuntu-font-family
sudo dpkg-reconfigure fontconfig
Attached to this bug report is also a branch of the Ubuntu packaging
that includes this manually modified Ubuntu-M.ttf, since the sources
seem not to be editable with free tools.
Original description:
After installing the Ubuntu Font 0.80-0ubuntu3+console from quantal I
have the added "Medium" font weight:-
/usr/share/fonts/truetype/ubuntu-font-family/UbuntuMono-B.ttf
/usr/share/fonts/truetype/ubuntu-font-family/Ubuntu-RI.ttf
/usr/share/fonts/truetype/ubuntu-font-family/Ubuntu-MI.ttf
/usr/share/fonts/truetype/ubuntu-font-family/Ubuntu-LI.ttf
/usr/share/fonts/truetype/ubuntu-font-family/UbuntuMono-RI.ttf
/usr/share/fonts/truetype/ubuntu-font-family/Ubuntu-M.ttf
/usr/share/fonts/truetype/ubuntu-font-family/UbuntuMono-BI.ttf
/usr/share/fonts/truetype/ubuntu-font-family/Ubuntu-B.ttf
/usr/share/fonts/truetype/ubuntu-font-family/Ubuntu-L.ttf
/usr/share/fonts/truetype/ubuntu-font-family/Ubuntu-C.ttf
/usr/share/fonts/truetype/ubuntu-font-family/Ubuntu-BI.ttf
/usr/share/fonts/truetype/ubuntu-font-family/UbuntuMono-R.ttf
/usr/share/fonts/truetype/ubuntu-font-family/Ubuntu-R.ttf
If I install this font and choose "Ubuntu Light" in LibreOffice, it
actually picks the "Medium" font weight. If I remove the medium font
weight files and restart LibreOffice it chooses the right weight
again. It seems related to bug 744812.
Screenshots show the issue.
ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: libreoffice-writer 1:3.6.1~rc2-1ubuntu5
ProcVersionSignature: Ubuntu 3.5.0-15.22-generic 3.5.4
Uname: Linux 3.5.0-15-generic x86_64
ApportVersion: 2.5.2-0ubuntu4
Architecture: amd64
Date: Fri Sep 21 17:34:30 2012
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Alpha amd64 (20120102)
SourcePackage: libreoffice
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/fontconfig/+bug/1054204/+subscriptions
More information about the foundations-bugs
mailing list