[Scribus] Font problem - Bitstream type 1 not working

PLinnell mrdocs
Fri May 5 16:27:45 CEST 2006

On Friday 05 May 2006 11:25, Peter Haraldson wrote:
> > 2) If Bitstream Type1 is no good - then what can I trust, how do
> > I know?
> >
> > I would be very interested to take a look at these fonts to check
> > what goes wrong.
> > You're shure they are unmodified from Bitstream?
> > Please file a _private_ bug at http://bugs.scribus.net and upload
> > one or more
> > of those fontfiles. Also describe exactly how you generated your
> > PDF: export to PDF,
> > embed all fonts, don't subset?
> >
> > As a workaround you can subset all fonts.
> >
> > /Andreas
> First of all - how do I "file a _private_ bug"? I can report an
> issue, but there's nothing about private? Don't know if it has to
> be private, but the fonts are of course not freeware.
> And subsetting - it shouldn't really be used, should it? 

Not at all, and in some situations preferable. 

>I'm really  more interrested in a final solution - be it a fix or in 
the worst  place, having to discard my fonts.

When filing the bug, there is a check box: "View Status: private or 

> Now I've done some tests, here are the results:
> My printer: HP Laserjet 4MPlus, not PS,
> driver:Laserjet4Foomatic+hpijs Distro's: Mandriva2006 and Debian
> 3.1
> Scribus versions: and, in Debian also 1.2.2cvs
> Test: Create small textdocument in Scribus, export to pdf with
> "embed all fonts" none subset, open pdf in kghostview, print ->
> preview or send to printer.
> Result:
> Debian sarge, ghostscript 7.07: No errors, prints fine.
> Mandriva 2006, ghostscript 8.15: Takes ages to print/create
> preview, errors:
> "Embedded font uses undefined procedure RD"
> "Embedded font uses undefined procedure ND"
> (the two lines repeated a zillion times - I used 3 fonts)
> Followed by:
> "  **** This file had errors that were repaired or ignored.
>    **** The file was produced by:
>    **** >>>> Libpdf for Scribus <<<<
>    **** Please notify the author of the software that produced this
>    **** file that it does not conform to Adobe's published PDF
>    **** specification.
> kdecore (KAction): WARNING: KAction::plugAccel(): call to
> deprecated action." (repeated some 10 times).
> This also happens with the pdf created in Debian(gs7.07), opened in
> Mandriva.
> It does not happen with pdf created in Mandriva (gs8.15), opened in
> Debian.
> I'm utterly confused! Is it actually not the fonts, but ghostscript
> 8.15? But then when it's created with 8.15 it works fine on my
> computer, viewed/printed by gs 7.07 - on commercial printer it
> doesn't work? Next step I guess is sending a pdf created in 7.07 to
> commercial printer, see what happens. Or any other suggestions?

Let's be clear. Scribus does _not_ use  ghostscript to create PDF.


Well, maybe back in 0.3x days.

Scribus uses Ghostscript for importing EPS,PS and PDF files into 
Scribus and for generating print previews.

Scribus creates PDF natively with its own PDF library and its own 

Here is the reason why this font is generating errors and how later 
versions cope with these errors:


Now, in your case, the version of Ghostscript only comes into play if 
you have placed EPS or PDF inside and image frame.

> Of course, I don't really know if it's the kghostview-error that
> causes the problems for commercial printer - but it's the only
> error I get. Commercial printer gets no error messages at all, it
> just doesn't print. Creating a pdf without Bitstreams Type1-fonts =
> no error & it prints. (All programs loaded from terminal.)

There are exactly 3, sometimes 4 usable PDF viewers for Scribus on 

1) Adobe Reader - There are issues with both 5.0.x and 7.0.x versions, 
that are indeed bugs in the Reader application and frequently 
triggered with Scribus PDF's. These issues are noted in the docs.

2) GSview 4.7+ with the shared library version of Ghostscript - 
preferably a separate install of the latest AFPL Ghostscript 8.5x

3) KPDF latest in KDE 3.5.x

4) Xpdf 3.01 << note .01 version. This version starts to support 
viewing transparency properly.

Anything else it likely to fool a user that there is a defect in 
Scribus PDF or EPS export or is missing functionality. This is noted 
in different forms in 3 different places in the documentation. 

To put it bluntly: ghostview, gv, ggv and in some cases kghostview 
will not view a perfectly valid EPS or PDF file. ghostview and gv are 
old, unmaintained, ugly and need to be retired from modern distros 

> Commercial printer replies: We do not place it in Quark,


> we
> processed it directly against our printers. 2 tried, both
> PS-printers.
> (When I was there, he used Acrobat 5 on Mac - no errors reported,
> but it didn't print.)
> Peter
> --
>   Peter Haraldson
>   peterharaldson at ml1.net

In the case of printing direct from Acrobat, we would need to know 
what kind of printer they are using and what print settings. Note,  
Acrobat 5 is a bit long in the tooth, but it should work. I have seen 
some issues with Scribus PDF's and Acrobat Pro 5.0.5 on Windows and 
Mac which are not present in 6.0+. 

Hope that helps.


More information about the scribus mailing list