Bug 490830

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 :)

nafees-web-naskh-fonts-1.2-2.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/nafees-web-naskh-fonts-1.2-2.fc10

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.

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: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-3508

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.

(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 ?

(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...

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 ?

I've written down what's going on with (preferred) (sub)families here: http://bugs.freedesktop.org/show_bug.cgi?id=12735

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.

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 :)

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).

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.

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.

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.

Just reopening the bug, so that I don't forget it and go on trying to fix this upstream.

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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

can this bug be closed now?

(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 ?

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)

http://blogs.msdn.com/text/attachment/2249036.ashx
http://blogs.adobe.com/typblography/typotechnica2007/Font%20names.pdf

(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)
> 
> http://blogs.msdn.com/text/attachment/2249036.ashx
> http://blogs.adobe.com/typblography/typotechnica2007/Font%20names.pdf  

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 :)

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.

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.

any updates here?

(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.

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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

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.