This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 490830 - Nafees Web Naksha should drop Preferred Family name
Nafees Web Naksha should drop Preferred Family name
Product: Fedora
Classification: Fedora
Component: nafees-web-naskh-fonts (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Mathieu Bridon
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2009-03-18 04:23 EDT by Parag Nemade
Modified: 2010-06-28 07:30 EDT (History)
4 users (show)

See Also:
Fixed In Version: 1.2-2.fc10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-06-28 07:30:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Parag Nemade 2009-03-18 04:23:10 EDT
Description of problem:
Nafees Web Naksha when installed shows only Nafees as font name in font selection box. When other Nafees fonts installed manually all will point to same name Nafees in font selection dialog box.This should not happen and should show all font names from Nafees font family

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. install this font
2. open this font in fontforge
3. check TTFNames in FontInfo(Ctrl+Shift+F)
4. Look for Preferred Family and Family fields.
Actual results:
currently it shows font name as Nafees

Expected results:
Should show font name as Nafees Web Naksha

Additional info:
Thanks to Muhammad Saad who reported this on fedora-i18n channel.
Comment 1 Mathieu Bridon 2009-03-19 05:57:08 EDT
Thanks for the report.

I contacted upstream about this issue, waiting for their reply.

In the meantime, I'll try to patch the font myself.

If anyone has a fontforge script ready to do that, do not hesitate to attach it here :)
Comment 2 Fedora Update System 2009-04-11 17:13:16 EDT
nafees-web-naskh-fonts-1.2-2.fc10 has been submitted as an update for Fedora 10.
Comment 3 Mathieu Bridon 2009-04-11 17:19:24 EDT
I can't get any answer from upstream :-/

As it is potentially an important usability issue, I patched the font myself and updated the package (including an update to 1.2 release).

It should land soon in Rawhide, can you try it ?

I also rebuilt it for F10, and it should land in the updates-testing repository soon see comment #2 for the bodhi URL).

As F9 is due to be EOLed in less than 3 months, I did not update the package for F9. I can do it too if someone needs it.
Comment 4 Fedora Update System 2009-04-13 15:32:47 EDT
nafees-web-naskh-fonts-1.2-2.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update nafees-web-naskh-fonts'.  You can provide feedback for this update here:
Comment 5 Ben Laenen 2009-04-13 15:55:00 EDT
This isn't a font bug I think. If the preferred family shows "Nafees" then upstream wants to see the font being called "Nafees" and not "Nafees Web Naksha". The latter is just the name that has to be displayed when the system can't handle preferred families.

The problem should be fixed in the font selectors instead.
Comment 6 Mathieu Bridon 2009-05-01 12:15:59 EDT
(In reply to comment #5)
> This isn't a font bug I think. If the preferred family shows "Nafees" then
> upstream wants to see the font being called "Nafees" and not "Nafees Web
> Naksha". The latter is just the name that has to be displayed when the system
> can't handle preferred families.
> The problem should be fixed in the font selectors instead.  

So, what should I do ?

Revert to the « preferred family » being « Nafees » and reassign the bug to each app having a font selector ?
Comment 7 Ben Laenen 2009-05-01 12:22:55 EDT
(In reply to comment #6)
> So, what should I do ?
> Revert to the « preferred family » being « Nafees » and reassign the bug to
> each app having a font selector ?  

Yes :-)

We've been bugging them for years now to fix it properly once. If more people start the doing that, it may be be fixed one day...
Comment 8 Mathieu Bridon 2009-05-01 12:34:51 EDT
So, how exactly should font selectors behave ?

If they don't look at the « Preferred family » field, what field should they look at ?

(I have no idea how those things work, I'm just trying to understand better the issue before I send it to them :)

On another note, isn't there a shared component (GTK ?) where this could be fixed instead of fixing it in each and every app ?
Comment 9 Ben Laenen 2009-05-01 13:14:00 EDT
I've written down what's going on with (preferred) (sub)families here:

Now, that's for Condensed faces in DejaVu (which are more or less supported by the GTK font selector, but not in Qt). If you move to other kinds of styles they're not supported in any of them (if you get a typeface with 64 styles, you sometimes only see maybe a fourth of them).

Font selectors should behave like this:
* either read preferred family and preferred subfamily (and make sure your font selector supports different styles besides bold and italic)
* or read the family and subfamily (if you don't fully support different styles)

But fontconfig will only give the preferred names to the font selectors, and that's why it's going wrong, if the font selector doesn't support it, it has no way to stick with the family and subfamily of a font and discard the preferred ones.
Comment 10 Mathieu Bridon 2009-05-01 14:18:32 EDT
Okay, so in your example of DejaVu, we would have:
- font family: DejaVu Sans Condensed
- font style/subfamily: Bold
- preferred font family: DejaVu Sans
- preferred font style/subfamily: Condensed Bold

A well behaved font selector would then display the font as « DejaVu Sans » and in the style selector, it would propose the « Condensed Bold » style (along the « Bold », « Italic »,... styles).

Am I right ?

Now, in my case:
- font family: Nafees Web Naskh
- font style/subfamily: Regular (only one style is provided)
- preferred font family: Nafees
- preferred font style/subfamily: Regular

Those are the values fontforge shows me.

Which means that a well behaved font selector would display the font as « Nafees » and in the style selector, it would propose the « Regular » style.

That's not really helpful as other Nafees fonts (for example the Nafees Nastaleeq font) have the same preferred family and preferred style.

So, even a well behaved font selector would have troubles with them :-/

Did I get all this right ?

(BTW, thanks a lot for your time and explanations :)
Comment 11 Ben Laenen 2009-05-01 14:46:10 EDT
OK, I didn't really investigate the Nafees Web Naskh font, but if the preferred subfamily is just "Regular", then that's a mistake there. Obviously the preferred subfamily should be different for all Nafees fonts with preferred family "Nafees". So it looks like the names need to be fixed in the font anyway (but the correct method is changing the preferred subfamily, not by completely dropping the preferred names).

Although I can understand that the latter looks more correct since due to those broken font selectors (or rather, broken synergy between fontconfig and font selectors) you may not be able to select all styles if you rename preferred subfamilies...

My personal view (which we've normally upheld in DejaVu) is that we don't fix things in the fonts which should be fixed elsewhere (it could open the door for other problems later when things do get fixed).
Comment 12 Mathieu Bridon 2009-05-01 15:01:04 EDT
Ok, so I have 2 choices here:

1. change « preferred family » to « Nafees Web Naskh » and let « preferred style » to « Regular » (that's what is in the current Rawhide and updates-testing package)

2. let « preferred family » to « Nafees » and change « preferred style » to « Web Naskh Regular »

Both would be good (admitting that we don't have issues in the font selector).

Which one to choose ? I guess only upstream can answer me on this one, and they are not really responsive :-/

I'll let it the way it is currently, if I can get an anwser from upstream, I'll do what they prefer.

I'll move the package from updates-testing to updates for F10, but I'll keep this bug open for future reference and for reminding me that this is not closed until I get an answer from upstream.

Thanks a lot again for all the explanations Ben.
Comment 13 Ben Laenen 2009-05-01 15:19:41 EDT
Well, in the end you're the package manager, so you're responsible for making it all work together. So I can understand that you prefer just removing the preferred names if you can maintain it and can keep following this up, whatever upstream does.

But upstream (Nafees, fontconfig and font selectors) should fix this anyway.
Comment 14 Fedora Update System 2009-05-02 12:36:49 EDT
nafees-web-naskh-fonts-1.2-2.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 15 Mathieu Bridon 2009-05-12 16:24:53 EDT
Just reopening the bug, so that I don't forget it and go on trying to fix this upstream.
Comment 16 Bug Zapper 2009-06-09 08:20:07 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
Comment 17 Parag Nemade 2009-06-25 05:11:48 EDT
can this bug be closed now?
Comment 18 Mathieu Bridon 2009-06-25 05:20:10 EDT
(In reply to comment #17)
> can this bug be closed now?  

As I said in comment #12, I'd rather keep it open, just to not forget about it.

I didn't really fixed the bug, I worked around it. Fixing it requires getting in touch with upstream, and have it fixed there. I tried to contact them, but I got no reply.

I'll go on trying, I'm afraid that if I close this bug I'll forget about this issue.

Is it really a problem to have it remain open ?
Comment 19 Nicolas Mailhot 2009-06-25 05:42:00 EDT
BTW, with regard to naming, it'd be a very good idea to check the new naming conforms to the WWS spec (making it WPF and CSS compatible)
Comment 20 Mathieu Bridon 2009-06-25 06:05:18 EDT
(In reply to comment #19)
> BTW, with regard to naming, it'd be a very good idea to check the new naming
> conforms to the WWS spec (making it WPF and CSS compatible)

Do you mean the package should be renamed ? Or some of the font attributes should be renamed ?

Could you open a new bug for that please ?

Please note that I am not really fonts-savvy, so if you could include as much details as possible about the request, that would be really appreciated :)
Comment 21 Nicolas Mailhot 2009-06-25 07:08:03 EDT
I means the names declared in the font metadata should conform to the WWS spec. You have all the gory details in the documents I linked, with standard values for style names, the order attributes should appear in, what to put in font name, what to put in style name, what to put in preferred name (and what is their relationship), etc

So it's really the same bug you want to keep open, except the 'maybe dropping the preferred name is a good idea' replaced by 'here is the spec MS published that describes the naming that will work in most apps'

Do remember Adobe and MS are the entities writing the opentype spec, so their opinion should be listened to carefully.
Comment 22 Mathieu Bridon 2009-06-25 07:34:39 EDT
Ok, that's more clear now :)

I'll try to have a look at it when I find the time to.

I'll also notify upstream about this and see if they are more responsive this time.

Thanks for the heads up.
Comment 23 Parag Nemade 2009-12-23 01:19:21 EST
any updates here?
Comment 24 Mathieu Bridon 2009-12-24 10:53:27 EST
(In reply to comment #23)
> any updates here?  

Not really. I'm terribly sorry, I haven't had time to fix this properly. :-/

To sum up :
1. I worked around the initial issue by patching the sources
2. Nicolas added that other parameters might be incorrect and would need to be fixed
3. I never got any answer from upstream, even if I contacted them several times at different email addresses...

Thanks for poking me, I'll try to have a look at all this, but if anyone wants to beat me to it, I'd be more than happy to give the necessary ACLs in PackageDB.
Comment 25 Bug Zapper 2010-04-27 09:14:25 EDT
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here:
Comment 26 Bug Zapper 2010-06-28 07:30:30 EDT
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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