swftools-common
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Swftools-common] Problem with boundingbox (0.8.1)


From: Kai Lautaportti
Subject: Re: [Swftools-common] Problem with boundingbox (0.8.1)
Date: Wed, 20 Jun 2007 11:58:19 +0300
User-agent: Thunderbird 2.0.0.4 (Macintosh/20070604)

Matthias Kramm wrote:
> On Tue, Jun 19, 2007 at 06:16:00PM +0200, Gustavo Frei wrote:
>> I have problem correcting boundingbox with swfbbox for swf created from
>> pdf2swf 0.8.1. The boundingbox is not recalculated and corrected  like it
>> used to be in previous version of swftools.
>>
>> I use the following command: swfbbox -O -c file.swf -o file.swf
>>
>> The problem is not in swfbbox but in pdf2swf i think [...]
> 
> Could you send me an example of a file which isn't processed correctly?

Hi Matthias and Gustavo

I'll barge in since I'm also experiencing similar problems :)

I'm using pdf2swf to convert a wide variety of PDFs. I've also noticed
that by default pdf2swf often produces SWF files which have their
bounding boxes way off.

Using swfbbox (swfbbox -Oc) to clip the bounding boxes fixes some of the
produced SWF files, but does not work as a general solution unfortunately.

Here are some of the things that I've noticed during testing.

- In all cases the contents of the PDF are positioned correctly at the
upper left corner in the SWF file

- The visual appearance of the SWF file is correct in the sense that it
replicates the source PDF as it should.

- The bounding box of the SWF file expands to the right and down past
the "true" bounding box defined by the actual content in the case where
the conversion (and swfbbox clipping) fail. This extra area is transparent.

I've also noticed that using the swfbbox binary to inspect the SWF files
seems to imply that the information to produce correct SWF files is (to
some extent) there. For example, on a particular PDF file, after
conversion and clipping I get the following output:

 $ swfbbox --newbbox test.swf
 Real Movie Size: 643.40 x 854.10 :-8.45 :-89.10
 Original Movie Size: 634.00 x 765.00 :0.00 :0.00

The original movie size here reflects the size of the PDF file (which
can be verified using e.g. pdfinfo).

The real movie size is the size that contains the transparent "extra".
Within that SWF file there is a area which corrensponds to the original
content and has the size of the original movie.

Also, the x and y offset values (-8.45 and -89.10) seem to relate to the
size of the extra area in the SWF file. So there are 8.45 units of extra
area from the right edge and 89.1 units of extra area from the bottom
edge. If the SWF file were clipped using these values the result would
be the correct one.

I've also noticed that for those pages in the PDF that the
conversion+clipping is successful, the offset values are always zero.

I used a simple python script (required python >= 2.4) to test these
issues which is available (with a test PDF file) at:

  http://void.technocore.fi/~dokai/swftools/

Just download the script and the PDF file, modify the paths according to
your system in the beginning of the swftest.py file and run:

  $ python swftest.py test.pdf

The script generates a separate SWF file per PDF page, runs the swfbbox
clipping on the result and then reports if the bbox values are still
incorrect. It uses the pdf2swf and swfbbox binaries and also the pdfinfo
binary from XPDF.

I've tested this with both 0.8.1 and the latest snapshot (2007-06-17)
and the problem is the same.

I'd be happy to provide more info if necessary.

cheers,
Kai Lautaportti


-- 
Kai Lautaportti               +358-50-558-7935
Software engineer             www.hexagonit.fi
Hexagon IT Oy                 address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]