On Fri, 2003-08-22 at 11:26, Subash Jeyan wrote: > On Fri, 22 Aug 2003 13:48:10 +0200, > Craig Bradney <cbradney at zip.com.au> wrote: > > [...] > > > After renaming the font, rerunning ttmkfdir, rebooting, the font still > > works perfectly > > in KDE, eg Kword, and in KDE windows themselves.. but not in Scribus. > > Any more ideas?
*Sigh* Not all fonts are equal - and *usually* you have to pay a lot for decent ones. Where did the font come from ? Is it a shareware font or free font downloaded from the net ? A great many - not all, are of dubious quality in postscript printing. In professional DTP, they are avoided at all costs. They might look fine on a Windows program and even when printed on Windows using the GDI interface - for example printing to an inkjet from Word or Publisher. However, in the postscript world, these types of fonts frequently have problems printing and displaying properly. In all the time I have been testing Scribus, I have almost never had problems with fonts displaying or printing. Why? I am very fussy about which fonts are installed and used with Scribus. The only fonts I use are the following: Bitstream Vera - still testing - but it seems to work fine so far. The Luxi fonts in Xfree86 - but I do not like the style of the serifs. Most of the Ghostscript fonts - except, I substitute the real Times and Helvetica fonts. The real ones work better with Acrobat Reader. Acrobat Reader does a horrible job of displaying them usually - even when embedded. The Adobe Utopia family from Xfree86. Of all the fonts in a typical Linux distro, I find this is one of the most versatile and reliable. It came to X via IBM. It prints and displays in Acrobat beautifully. The MS Webfonts - except Wingdings. The MS Wingdings can be sometimes fail to print properly in some postscript environments. They also have a weird encoding scheme. The Monotype fonts which came with Star Office 5.2, 6.0 or the ones which come with open office. These are all high quality Agfa Monotype fonts, the same company which provides most of the fonts to MS for Office. Same issue as Wingdings with the symbols fonts. Any 1992+ Adobe Type 1 font. The bonus of using Adobe Type 1 is they will come (should?) with the .afm files which Freetype and Scribus will use for more accurate kerning or spacing in text. Any of the Type 1 Bitstream or ITC fonts included with recent versions of Corel Draw. Type 1 is preferred to the True Type, for same reasons as Adobe. This one of the best bargains in getting some quality fonts. There are about 1000 faces, which cover a broad spectrum of needs for most any user from decorative to symbols to complete extended families with condensed, black and roman weights. I have clients who have used these fonts for years publishing corporate brochures and magazine print runs which run up to 300,00 issues. They have never had a postscript problem with these fonts It is very difficult to make good fonts and they need rigorous QA. Converting the Adobe catalog from Type 1 to Open Type has taken years, mostly because of QA. Thus, the complete Type collection from Adobe runs into several thousand dollars and most good printers consider it essential to have a good portion of the collection. It is for them, a wise investment. Fonts are mini-programs. Look into the True Type spec. There is a lot of references to the VM or virtual machine. They have bugs. There are a lot of broken and poorly constructed freeware/shareware fonts. You can learn a lot about fonts and type from the freetype site. It has a really excellent set of docs on what a font is, terminology, how they work etc. Xfree86 has been perceived, rightfully in the past, to have crappy looking fonts, which were mostly non-scaling bitmap fonts. In the design of X, this was a performance compromise and needed at the time, given its original goals of network transparency. So, in making the Linux desktop more appealing, a lot of effort has been put into adding True Type support etc. However, once True Type font servers became standard, distros started loading packages with some IMO iffy TT fonts. In creating font packages, some of the fonts.dir and fonts.scale files have been less than perfect - some actually bad from the start and without a lot of QA for postscript printing. Now along comes Scribus the first serious DTP app in Linux and everyone is complaining about it can't find fonts. Scribus has lots of code to dig into Xlibs and find not only what fonts are installed, the real postscript name and what is inside the font metrics for precise printing. I consider this a feature, I am very glad it has this code - not a bug. If someone posts a problem with a: a verified high quality Type 1 or True Type font examples above... and it is not binary corrupt - which I can verify if needed. and it is installed properly i.e. fresh fonts.dir and fonts.scale, which have been opened in a text file for correctness. and your font paths are set up properly - see the hints below and Scribus cannot find it then there is a bug - or you have something broken/misconfigured in Xfree86. But I have never seen this since way back on Qt2 and Redhat patched the original True Type font server to Xfree 4.0. There was an issue for Xft2 when Redhat launched RH 8.0 at the same Franz released 0.8. When I advised him of the problem - he had a patch back to me in 2 hours which worked. Scribus cannot yet entirely depend on the new fontconfig/Xft2 setup as it does a lot substituting on the fly and in DTP, you need the real name of the font and to know where it is. How can your properly embed a font for PDF or Postscript otherwise? It works great for general purpose apps and for the desktops KDE/Gnome. I do not want to sound like I am picking on anyone in particular, but fonts in Xfree86 have been a mess for a really long time. Franz has worked very hard to make fonts usable and reliable for DTP without breaking your system or adding another layer of font management/font path complexity a la Star Office, Abiword or Corel's Linux ports to name three. So, no, there may be cases where not all of your fonts will work with Scribus. It is just not as simple as Macs or Windows. Sorry. I rest my case. > > hi, > > had a somewhat similar problem under mandrake (from versions 8.2 upto > 9.1). there's a set of fonts installed by default in mandrake under > /usr/share/fonts/ttf/decoratives. though this directory had > fonts.scale and fonts.dir files, scribus was not picking them up, though > they were available for all other applications under kde. what i did > helped me get those fonts for scribus though i am not sure if they would > help you: > > 1) delete the default fonts.scale and fonts.dir > > 2) ttmkfdir -m 50 -o fonts.scale > > (- m 50 for max # of missing characters per encoding) Subash's fix is correct for many cases, if you need to use these fonts with Scribus. I think the default is 5 or 10. This type of problem is frequently an issue with True Type fonts. There are lots of true type fonts with missing characters in the glyph tables. (See above) You can verify this by selecting the font in the Insert Special command in Scribus. This will show the the entire set of available glyphs a given font. Moreover, this is particularly acute with decorative fonts which might not have all the first 128 glyphs filled - let alone extended glyphs. There are also issues with glyph placement of certain characters, as the TT spec differs slightly from the Type 1 spec. I'll dig out the docs if you are really curious. This was most apparent trying to get True Type fonts to work - properly - in Star Office 5.2. This was one the reasons Keith Drummond created the Kfontistaller. > 3) mkfontdir > > since in my case /usr/share/fonts/ttf/decoratives was already in the > font path i didn't have to run chkfontpath. but if you are adding a new > font directory, you should also additionally run: > > 4) chkfontpath --add /path/to/your/new/font/directory Or add this via font preferences in Scribus.
