Scribus Forums

Scribus => Text and Typography => Topic started by: CGood on December 17, 2016, 08:06:01 pm

Title: Interesting display issue with some bold weight fonts
Post by: CGood on December 17, 2016, 08:06:01 pm
I've noticed that the display of some fonts gets distorted. If I send the same thing to a pdf, it seems fine on the ones I've checked, so I thing this is confined to just the display withing Scribus. I am attaching a screenshot sample showing a font "Aurelis ADF", in bold and Roman. Note the distortion of parts of the bold. It is as if the vectors get scrambled and moved. It seems not to be a big issue since at least pdf output is fine.

Anyone else run into this?
Title: Re: Interesting display issue with some bold weight fonts
Post by: GarryP on December 18, 2016, 02:43:42 pm
I've just downloaded the font from and it seems to display okay in 1.4.6 on Win 10. I've tried various things to make it do what you've observed but can't replicate the issue.

If you can collect an example file for output (including the font file) then someone might be able to try and see what's wrong. It would help if you also say what version of Scribus you're using and on which OS+version.
Title: Re: Interesting display issue with some bold weight fonts
Post by: CGood on December 18, 2016, 08:42:29 pm
I have attached my copy of Aurelis. The list of fonts that display with that distortion makes me suspect it is not a flaw in a font file, but a flaw in the display rendering. I may have a couple more with the problem. Can't remember.

All of these, at least, have an issue in bold rendering:

Adobe Caslon Pro
Eau Naturele
Midiet Sans
Midiet Serif
Tex Gyre Adventor

But when I output into a pdf, that output seems fine. Kind of a head-scratcher. So, this is not a critical flaw, and more a curiosity. Now that I know the output is OK, it's not a crisis. I should note that I have become a font collector (hoarder?) with some six hundred font families +/- and so I get to see many interesting behaviours.

I will file a bug report on this - that might help the devs somewhere down the line.

My system. copied off the "About":  Scribus Version 1.5.1  -  14 February 2016  - Build ID: C-C-T-F-C1.13.1-64bit  -  Using Ghostscript version 9.10

On Linux Mint 17.2 on Lenovo T420 Laptop.
Title: Re: Interesting display issue with some bold weight fonts
Post by: GarryP on December 19, 2016, 12:28:41 pm
I quickly installed - onto a Linux Mint 17.3 VM - both the regular and bold versions of the font you supplied and they look fine in the Font Viewer. I don't have a copy of Scribus in that VM so I can't check how it displays them.

The problem may be something to do with the fact that you're using a quite old, non-stable version of Scribus (1.5.1). Normally I'd recommend going back to the last stable version (1.4.6) but that would mean that the files you've created wouldn't load (Scribus not being backwards compatible). You could try installing 1.5.2, or even 1.5.3 if you want to be as up-to-date as you reasonably can be. Whatever the problem is that you're getting might have been fixed already in a later version. With developmental software, one of the first things you'll normally be asked is "Have you tried it in the latest version?"

As an aside: How are you organising your fonts? I only ask as I've got an idea about creating an application to help organise fonts, images, clipart, articles and other related things and am interesting in knowing how people organise their stuff.
Title: Re: Interesting display issue with some bold weight fonts
Post by: CGood on December 20, 2016, 08:30:12 pm
Thank you for trying to sort out what is going on!

I don't want to make it look like I'm in trouble here - more curious. I have thought about 1.5.2, and if I run into a wall with 1.5.1, I'll update. This is more an oddity than crisis. When I first saw it, I though it was a flaw in one font-face, but then as I saw the distortion in more fonts, the Scribus display looked like the guilty party. I have some six hundred +/- font families installed and only maybe twenty act odd, in one weight.

I cannot remember if multiple versions of Scribus can easily coexist on one machine without messy (for a non-programmer) workarounds.

On your question of how I organize my font collection, I use FontMatrix. It helps look at fonts, check the designer, license... but FontMatrix has very little power to actually organize the presentation or availability of a font set.

I'd take notice if it or some application could allow me at the drop of a hat to present to Scribus or LibreOffice, only a chosen small group of fonts that work together, and allow me to quickly change that set, or look at everything.

As I discover pairs and groups of fonts that play well together, I'd like a way to automate some way to not be forced to wade through endless lists of fonts that won't work together. I wouldn't expect an app to find out what works with what, but merely to allow me to create and deploy limited groupings.

I have settled upon using a spreadsheet to describe and categorize my fonts. Weight, serif or sans, small caps or not, italics or obliques, fullness of the sets of glyphs, range of weights, clarity or distinction the italics have from the romans, relative height or depth of ascenders and of descenders, misc notes about the fonts, licensing, limitations and issues, a couple more items I cannot remember this instant.

I'm curious what you are thinking of with font organization.
Title: Re: Interesting display issue with some bold weight fonts
Post by: GarryP on December 21, 2016, 02:51:18 pm
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.)
Title: Re: Interesting display issue with some bold weight fonts
Post by: CGood on December 21, 2016, 11:13:40 pm
I just tried print preview - new to me - and the font Aurelis retains the distortion within the Scribus interface, and when, just now, I save to pdf, all is well as I see it  - external to Scribus.

I suspect the underlying text and sva files are fine, but that the display within Scribus is having a minor hissy fit. The second pdf viewer I ordinarily use is outside of Scribus, just the default "Document Viewer" that comes with Mint.

I am inclined to not upgrade to 1.5.2 - or, not quite yet - until I test drive it on another Mint machine. I have a couple of Mint machines so sometime soon, I should do that. I'm sure it works well, but despite a couple of glitches, 1.5.1 overall does the job darn well.

A couple of random thoughts on font organization and management:

The closest I have come to code is some rudimentary VBA in Microsoft Access, so I don't have intelligent commentary on the means you are thinking of for font or pubilcation asset management. Indeed, the kind of data you and I are thinking about seems to me to be a natural fit within a database. The tagging of fonts can grow like topsy, and in my mind, a db would handle a big pile of redundant tags. I take it on faith from you that xml can do the same.

FontMatrix has a tagging function, but after tagging many fonts with many tags, FontMatrix slowed down significantly enough that I just deleted all the tags and now just use it as a viewer instead of an tagged organizer. I wondered if FontMatrix could be repaired under the hood to perform better. I am guessing it does some loop that is ok with small piles of data, but lags badly with hundreds and thousands of tags.

Vaporware or not, your idea would be wonderful.

The thing that has popped into my mind is that an app would be wonderful, that could uninstall (or make invisible to Scribus) hundreds or thousands of fonts, and allow me to just deal with the two or three I need at the moment in Scribus. And then put some or all the fonts back as I need them, and all along allow me to see all my fonts through the app.

Great to talk!
Title: Re: Interesting display issue with some bold weight fonts
Post by: GarryP on December 22, 2016, 04:24:26 pm
It certainly looks like Scribus is having trouble displaying the font(s) on-screen - both "normally" and in the Print Preview - but the PDF result is okay. This tells me that Scribus could be using two different techniques for drawing the glyphs. Maybe it uses two different libraries. Definitely a bug somewhere but whether it's in Scribus or a library is someone else's call.

I normally wouldn't recommend using the Print Preview as some people have had trouble with it in the past (for example it has trouble with image transparencies). I only asked you to try it to see how Scribus displayed your font issue. Unless you need to see the CMYK separation or something else that function gets you (that a PDF export won't) then I'd recommend using the PDF export as your print preview.

I don't have any 1.5.x installations so I couldn't recommend a particular version but - if you have to use developmental software - it's normally good to use the version before the one that the developers are working on (which is currently 1.5.3).

I get where you're coming from about using a database but I think it would be much simpler if the app didn't need one. Just save its state to a file and restore from that on start-up. Nice and simple. It's an implementation thing which should really be abstracted from the models anyway.

NexusFont has tags too but I don't use them. I use it like a font viewer as you do with FontMartix. I haven't checked to see how well it uses them so I can't comment on that. My list of fonts is starting to grow since moving to a new machine which is why I've been looking around for a solution (hence my idea).

Scribus already has the handy ability to use fonts that are contained in the document's folder without installing them. If a document could have a "toggle" to say that you only want to use the document folder fonts that might be one way of trimming the list down (and would nicely fit with what I was proposing).

There has been talk over the years about having some kind of "recently used" section in the fonts list but I don't know if anything will be coming out of that. Lots of people have their own preferred way of doing it so anything that's done won't be to everyone's liking. Easy font choice is a major thing for a DTP application so I think it's an important issue but that's just my opinion.

Yes, I agree, this chat is coming along nicely. It would be nice to hear from other people too though. It's usually good to get a bit of a debate going as nice ideas sometimes come out of them. Looking forward to more feedback and chat.