You're welcome.
It's odd that the fonts look right when exported to PDF but aren't drawn correctly on-screen. It suggests that Scribus could be using two different ways of drawing the glyphs - one for on-screen and another for export - which, on the face of it, would seem to be a strange thing to do.
Have you tried using the "File -> Print Preview" function? I'm curious as to whether the problem occurs in there too. That might help someone track down where the problem is coming from. Either way, Scribus isn't displaying those fonts correctly on-screen so, to me, that's a bug that needs to be reported.
However, as soon as it's reported someone will ask if the problem still occurs in the latest version. The developers are (essentially) finished with 1.5.1 so they will only really be working on problems that occur in the very latest version. They're not going to go back to try and fix old developmental versions when they have the latest version to work on. This means that you would have to upgrade to at least 1.5.2, which might fix the problem anyway.
On Mac and WIndows it's easy to have different major versions - 1.4.x ,1.5.x - on the same machine as you just install into different folders. Because the different versions use different preference/resource files (with different names) they can sit alongside each other pretty well. I think you can do the same on Linux by using different /opt or /usr folders but I'm not an expert. Either way I don't think it's possible to have two completely separate minor versions - for instance 1.5.1 & 1.5.2 - on the same machine as they will try to use the same preference/resource files and that could cause problems. I'd be happy to be proved wrong on this though.
On the font organisation front, thanks for the information. It's given me something to think about.
My idea, and it could well stay as vapourware and not come to anything, is to have an application that allows you to create "tags" and "metadata" (source, author, location, etc.) that you can apply to files anywhere on your machine. It would have a UI that would allow you to browse files on your machine - fonts, images, clipart, documents - and group them together in whatever way you found useful, also allowing you to get a preview of the tagged files in one place.
For instance, say you're creating a magazine and you have an article on an American Road Trip, you could create tags called "Magazine Issue 1" and "American Road Trip". You could then browse your machine picking and tagging (with both tags) some nice American fonts - e.g. Varsity, Air Americana - via a preview pane. Then you could browse through your pictures and tag some good shots of desert roads and the Vegas Strip, again via a preview pane. You could then browse some documents - probably just text files at first - that contain the text for the article. Once you have chosen/tagged your files you would be able to see them in the same preview pane to get an overall idea of what the resources would look like together. (This all looks fine in my head but it's difficult to explain.)
Once you are ready to go ahead with production you tell the application to collect the items into a new folder. This would create a folder (perhaps with sub-folders) containing copies of the files you have tagged for that article. You can then create the article in Scribus referencing or importing from those files. Tagging new files to use would also let you tell the application to refresh the folder to contain the latest copies of all of the files (if any have changed). Once the magazine was finished you'd delete the sub-folders (to get the space back) but you'd still have the tags in place to be able to re-create them if necessary.
Using the same tagging functions you could organise anything you wanted to. Fonts by weight, or images by subject, or documents by author, or any way you wanted to. You wouldn't have to use the "collect for production" feature if you didn't want to.
I realise I probably haven't explained it very well. Like I said, it's just an idea that's been floating in the back of my head for a while.
I've been looking at applications like NexusFont - which works very nicely but is only for fonts - and XnViewMP - which doesn't work the way I thought it should and is very confusing - and thought that it might be good to have some kind of "total file organiser" that works the way I want it to work. I've thought about trying Adobe Bridge but I don't really want to go down that route if I don't have to so I've not tried to install it yet. I might give it a try just to see how it works though.
Breaking it down in my head - to a certain point - sort of says that most of it shouldn't be too hard to do. Previewing images, fonts and text files shouldn't be very difficult (basic API stuff). Creating a bunch of tags and applying them to a list of filenames shouldn't be too much of a chore (tree structure perhaps). Adding/maintaining metadata on those files shouldn't be a huge issue (dictionary within the tree?). Copying files and creating folders is just an OS function. And the internal data should be fairly easily serialisable into XML so no need for a database. I don't see the actual "engine" for this being a massive problem; difficult and time-consuming to get right but not an unassailable task.
It's the UI that's probably going to be the thing that would kill the idea. If the UI isn't right then it will be pointless.
It's worth mentioning that it would be in C#.NET but that covers OSX and Linux these days too so compatibility should not be a major issue (once I figure out how that's handled).
Anyway, I've not done any real analysis or planning for this and I've no idea if I'll even start it, but if you - or anyone else reading this - have any ideas then I'd like to hear them. (This isn't strictly a Scribus thing but it might be of use to people using Scribus.)