[Scribus] Re: Re: Re: Fonts look bad at first with PDF plugin in browser
Wed Dec 1 12:34:43 CET 2004
On Wednesday 01 December 2004 12:43, Sandip Bhattacharya wrote:
> On Wed, 2004-12-01 at 12:16 +0100, Alexander Skwar wrote:
> > Craig Bradney wrote:
> > > On Wednesday 01 December 2004 11:46, Alexander Skwar wrote:
> > >> Hm :( Then, the fonts look very bad and the form takes "ages" to
> > >> render (~20 to 30 seconds).
> > >>
> > >> What does acrobat (the writer) do differently, so that the problem
> > >> doesn't exist at all there?
I have looked at this file and some comments:
1) There is an option to "Save for Web" in Acrobat Pro. This "linearizes" the
pdf, at the cost of a larger size, contrary to what you would think.
What this does, is save the PDF objects, page by page in a linear fashion
within the PDF, to allow the PDF to download page by page. You must
understand PDF internally does not store objects in a linear fashion by
default in the interests of saving file size - one of the reasons PDF import/
editing is so difficult. Eg. the fonts might be stored last in the file
internally or mixed in with image stream objects.
There is a special Apache module that allows "byte-serving" if I recall
correctly. You need this enabled for this to work with "linearized" PDF.
You can use the pdfopt tool from Ghostscript to do this:
$pdfopt ./input.pdf ./output.pdf
In my test, this doubled the file size, but it does load much faster.
2) There are 10 fonts in the PDF, which is very high for a single page form.
Personally, I would only use the "Base-14" fonts which are included in all
versions of Acrobat. Where a decorative font like for a logo, you might
consider converting them to outlines. This also might make the file smaller.
I tested this with a survey form and reduce the size from 190kb to about 30k.
Moreover, it is my observation Adobe Acrobat does not cope well with either
the Ghostscript fonts or some which are standards on most Linux distros. Why,
I can't tell exactly, but just note I have seen this for a long
time,especially with the Acro Reader for Linux.
3) Acrobat Reader + gtk2 is not a good combo. Mozilla with acro reader plugins
(all platforms) are not particularly stellar performers. This is a known
performance problem, but I can't point to any fixes.
I personally disable viewing PDF within browsers, for many reasons, but mostly
for performance. I also realize this is not the default, but note that there
are many install issues with the Acro Reader .ocx control with IE as well.
4) While Scribus can create PDF forms (which is a wonderful and underused
feature IMO), the defaults and most of our testing is directed towards
optimal print output. The rave reviews Scribus gets for PDF output shows that
effort. It is genuinely commercial grade and in some cases, superior to well
known DTP apps.
5) The exact reason for the behavior you are seeing is *any* Acro Reader will
use its own multi-master fonts to substitute in the display or printing if it
has issues with the embedded fonts or they are not loaded into memory. You
are seeing the slowly improving display, as it loads the fonts. This can be
exacerbated by the GTK + Acro Reader issues I mentioned above.
There is no one single answer to your issue, but my hints might give you some
things to work on to optimize performance.
> While viewing your form if I drag the scrollbar to the bottom, I dont
> reach the bottom and get stuck somewhere in the middle. In other words I
> cant see part of the bottom of the form.
> However if I use the pan tool (the hand) to drag the document up, I can
> see the bottom of the form. Is this another reader specific oddity?
> I have seen this happening on some PDFs before . e.g. some OOo created
> PDFs which have been encrypted using pdftk.
Correct. known, long time issue with Acro Reader on Linux.
/me crosses fingers for a proper Acro 6 for Linux.
More information about the scribus