[Scribus] Re: Re: Re: Fonts look bad at first with PDF plugin in browser

[Plinnell]

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?

<snipping heavily>

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.

Cheers,
Peter