[Fwd: Re: [Scribus] Newbie font-question]

[Peter Linnell]

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.