[Bug 1823984] Bold fonts in qt applications appear much too heavy
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1823984
--- Comment #16 from Hannes Riebl <hriebl(a)posteo.de> ---
All theoretical and spec-related discussions aside, here is the output of
Nicolas' command on my system (with Cantarell 0.111 installed):
$ fc-scan -f
"%{family};%{style};%{fullname[0]};%{width};%{weight};%{slant};%{fontversion};%{file}\n"
/usr/share/fonts/cantarell | sort -t ';' -k1,1d -k4,4n -k5,5n -k6,6n -k2,2d
-k7,7dr | uniq | column --separator ';' -t
Cantarell Regular Cantarell Regular 100
80 0 7274 /usr/share/fonts/cantarell/Cantarell-Regular.otf
Cantarell Bold Cantarell Bold 100
200 0 7274 /usr/share/fonts/cantarell/Cantarell-Bold.otf
Cantarell,Cantarell Extra Bold Extra Bold,Regular Cantarell Extra Bold 100
205 0 7274 /usr/share/fonts/cantarell/Cantarell-ExtraBold.otf
Cantarell,Cantarell Light Light,Regular Cantarell Light 100
50 0 7274 /usr/share/fonts/cantarell/Cantarell-Light.otf
Cantarell,Cantarell Thin Thin,Regular Cantarell Thin 100
0 0 7274 /usr/share/fonts/cantarell/Cantarell-Thin.otf
That's pretty much the same as on Nicolas' system, except that Cantarell-VF.otf
is missing. To me it seems that the metadata is quite inconsistent between
Cantarell-VF.otf and the other files. Shouldn't the output for Cantarell-VF.otf
be as follows, at least for the sake of internal consistency:
Cantarell Cantarell Regular 100
[0 205] 0 13173 /usr/share/fonts/cantarell/Cantarell-VF.otf
Cantarell,Cantarell Thin Thin,Regular Cantarell Thin 100
0 0 13173 /usr/share/fonts/cantarell/Cantarell-VF.otf
Cantarell,Cantarell Light Light,Regular Cantarell Light 100
50 0 13173 /usr/share/fonts/cantarell/Cantarell-VF.otf
Cantarell Regular Cantarell Regular 100
80 0 13173 /usr/share/fonts/cantarell/Cantarell-VF.otf
Cantarell Bold Cantarell Bold 100
200 0 13173 /usr/share/fonts/cantarell/Cantarell-VF.otf
Cantarell,Cantarell Extra Bold Extra Bold,Regular Cantarell Extra Bold 100
205 0 13173 /usr/share/fonts/cantarell/Cantarell-VF.otf
Instead of:
Cantarell Cantarell Regular 100
[0 205] 0 13173 /usr/share/fonts/cantarell/Cantarell-VF.otf
Cantarell Thin Cantarell Regular 100
0 0 13173 /usr/share/fonts/cantarell/Cantarell-VF.otf
Cantarell Light Cantarell Regular 100
50 0 13173 /usr/share/fonts/cantarell/Cantarell-VF.otf
Cantarell Regular Cantarell Regular 100
80 0 13173 /usr/share/fonts/cantarell/Cantarell-VF.otf
Cantarell Bold Cantarell Regular 100
200 0 13173 /usr/share/fonts/cantarell/Cantarell-VF.otf
Cantarell Extra Bold Cantarell Regular 100
205 0 13173 /usr/share/fonts/cantarell/Cantarell-VF.otf
Maybe it's worth a shot to generate a version of Cantarell-VF.otf with this
metadata? I would do it myself, but I don't know how to compile Cantarell.
Would be happy to try it out on my system, though...
--
You are receiving this mail because:
You are on the CC list for the bug.
4 years, 1 month
[Bug 1823984] Bold fonts in qt applications appear much too heavy
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1823984
--- Comment #15 from Nikolaus Waxweiler <madigens(a)gmail.com> ---
I agree that a better written specification would be highly appreciated, but I
think you're fighting a losing battle here. OpenType is 40 years of accumulated
cruft and vendors and applications doing whatever they want. Our font engineers
spend _significant_ amounts of time testing fonts before release in major
applications _every single time_. Microsoft, the owner of the specification, is
no paragon when it comes to interpreting their own spec in their own
applications. As it stands, font metadata is no exact science but fudged in
whatever way makes the fonts work as intended for the paying client. It's the
reason the spec is so weakly worded. And that's just the way it is.
Anyway, this is getting increasingly off-topic. I'd wait for a Qt person to
look into this. If they find that the font is doing something off-beat, I can
fix it.
--
You are receiving this mail because:
You are on the CC list for the bug.
4 years, 1 month
[Bug 1823525] New: fontforge fails to build with Sphinx 3.0.0
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1823525
Bug ID: 1823525
Summary: fontforge fails to build with Sphinx 3.0.0
Product: Fedora
Version: rawhide
Status: NEW
Component: fontforge
Assignee: kevin(a)scrye.com
Reporter: cstratak(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: cstratak(a)redhat.com,
fonts-bugs(a)lists.fedoraproject.org, kevin(a)scrye.com,
mhroncok(a)redhat.com, paul(a)frixxon.co.uk,
pnemade(a)redhat.com
Blocks: 1783776
Target Milestone: ---
Classification: Fedora
fontforge fails to build with Sphinx 3.0.0.
[ 3%] Generating sphinx-docs
cd /builddir/build/BUILD/fontforge-20200314/build/doc && /usr/bin/sphinx-build
-q -n -W -b html -d doctrees
/builddir/build/BUILD/fontforge-20200314/doc/sphinx sphinx-docs
make[2]: Leaving directory '/builddir/build/BUILD/fontforge-20200314/build'
Warning, treated as error:
/builddir/build/BUILD/fontforge-20200314/doc/sphinx/scripting/python/fontforge.rst:1369:duplicate
object description of fontforge.layer.stroke, other instance in
scripting/python/fontforge, use :noindex: for one of them
For the build logs, see:
https://copr-be.cloud.fedoraproject.org/results/cstratak/sphinx_3.0.0/fed...
For all our attempts to build fontforge with Sphinx 3.0.0, see:
https://copr.fedorainfracloud.org/coprs/cstratak/sphinx_3.0.0/package/fon...
Testing and mass rebuild of packages is happening in copr. You can follow these
instructions to test locally in mock if your package builds with Sphinx 3:
https://copr.fedorainfracloud.org/coprs/cstratak/sphinx_3.0.0/
Let us know here if you have any questions.
Sphinx 3 will be included in Fedora 33. To make that update smoother, we're
building the dependent packages in Copr.
We'd appreciate help from the people who know this package best, but if you
don't want to work on this now, let us know so we can try to work around it on
our side.
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1783776
[Bug 1783776] python-sphinx-3.0.1 is available
--
You are receiving this mail because:
You are on the CC list for the bug.
4 years, 1 month
[Bug 1823984] Bold fonts in qt applications appear much too heavy
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1823984
--- Comment #14 from Nicolas Mailhot <nicolas.mailhot(a)laposte.net> ---
The OpenType spec is quite hard to read because its authors do not use
IETF-style unambiguous MUST SHOULD etc but plain human text (sometimes,
repeating the same point multiple times with various levels of emphasis). It
badly needs refactoring by a professional standards writer, to remove the
repetitions, and make requirements more explicit and forceful.
Generally speaking, you should apply everything the spec recommends no matter
how polite and un-assertive the wording is. Because anything authors think is a
good idea *is* a good idea, and would not have been documented if it were not a
hard requirement for software somewhere.
Besides, anything stated in part of the spec is likely to be repeated or built
upon in more forceful terms in other parts, in later revisions, or derived
standards¹.
¹ CCS4 was written by people more familiar with standards; it generally repeats
OpenType, with a lot of MUSTs sprinkled everywhere, because there’s only one
way to make things work reliably, and the original vocabulary is dangerously
watered down
--
You are receiving this mail because:
You are on the CC list for the bug.
4 years, 1 month
[Bug 1823984] Bold fonts in qt applications appear much too heavy
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1823984
--- Comment #13 from Nikolaus Waxweiler <madigens(a)gmail.com> ---
Regarding ID 4, the spec uses wording like "would generally be omitted" and
"would typically be a combination of name IDs 16 and 17", so "non-conformance"
sounds like hyperbole to me.
I don't know if fontconfig's "fullname" is supposed to return ID 4 or if it
synthesizes that field from family and style name.
--
You are receiving this mail because:
You are on the CC list for the bug.
4 years, 1 month
[Bug 1823984] Bold fonts in qt applications appear much too heavy
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1823984
--- Comment #11 from Nicolas Mailhot <nicolas.mailhot(a)laposte.net> ---
The OpenType spec states, when defining fullname (Name ID 4)
https://docs.microsoft.com/en-us/typography/opentype/spec/name#nid4
> name ID 4 would typically be a combination of name IDs 16 and 17
You’re not supposed to use Name ID 1/2 in Name ID 4, but Name ID 16/17 (and
probably Name ID 21/22 since those override 16/17 if present)
And the spec continues with
> without needing any additional qualifications regarding “Regular”.
So, you’re not supposed to repeat “Regular” in upper naming layers. It can only
exist in Name ID 2, 17 or 21 to specify the default family face.
Also, due to the RBBI limitations of Name ID 1 & 2, the default face does not
have the same meaning in Name ID 1/2 & 16/17 or 21/22. A face can be default
(Regular) in the RBBI sense (name ID 2), without being Regular in Name ID 17 or
21.
This is all clearer in the canonical example provided with the spec:
https://docs.microsoft.com/en-us/typography/opentype/spec/namesmp
(does not include Name ID 21/22, those are later creations to help font makers
fix existing non conformant name ID 16/17 without breaking legacy compat)
--
You are receiving this mail because:
You are on the CC list for the bug.
4 years, 1 month
[Bug 1823984] Bold fonts in qt applications appear much too heavy
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1823984
--- Comment #10 from Nikolaus Waxweiler <madigens(a)gmail.com> ---
I don't understand your metadata criticism. The "Cantarell Extra Bold Regular"
thing is a concatenation of name id 1 and 2 and the spec recommends that you
pretend to be a RIBBI font in them. It makes stuff work in old crusty
applications such as modern Word.
> https://docs.microsoft.com/en-us/typography/opentype/spec/name#name-ids (IDs 1 and 2)
> [...]
> While some platforms or applications do not have this constraint, many existing applications that use this pair of names assume that a Font Family name is shared by at most four fonts that form a font style-linking group: regular, italic (or oblique), bold, and bold italic (or bold oblique). To be compatible with the broadest range of platforms and applications, it is strongly recommended that fonts limit use of Font Family name in this manner.
> [...]
This is established practice and what ufo2ft, the "major player" next to
Adobe's makeotf, does and what the spec recommends. You start from the true
family and style name and if the style is within RIBBI, you use id 1 and 2, if
not, you write the true values to 16 and 17 and emulate RIBBI-ness in 1 and 2.
The style names for variable font instances are taken from the fvar and/or STAT
table. fontconfig seems to only use the full name from the name table without
taking variation data into consideration.
The correct way to determine family and style for a static font is
family_name = id16 or id1
style_name = id17 or id2
In pythonesque pseudo-code and ignoring the WWS stuff that I have never seen in
practice. Fontconfig seems to do the wrong thing here by including the
"Regular" when id17 says something else.
--
You are receiving this mail because:
You are on the CC list for the bug.
4 years, 1 month