Hi Chris,
Thanks, I will play around with the -s zoom=[dpi] switch. Hopefully
Matthias can shed some light on this problem
Regards,
Rob
On 12-06-14 03:35 PM, List_Subs wrote:
On Thu, 14 Jun 2012 10:50:41 -0400
Robert Damiano<[email protected]> wrote:
Hi Chris,
We can see that the cropbox for both PDFs, which is used in the
PDF2SWF conversion is 585.0x772.0. I don't believe you can disprove
the validity of my bug by using the tool that I'm claiming has the
bug.
I was more refuting your statement that removing the poly2bitmap 'fixed'
the issue. It made no difference whatsoever when I tried it.
Further quick tests show me that removing '-s zoom=' completely, does
rectify the problem. In fact certain values create the one pixel
discrepancy, while others don't. Try it.
The dimensions that PDF2SWF is showing is the pixels of the
SWF, which I can see are 1015 and 1016 respectively, but that is the
bug.
Possibly. More an effect of the calulation that is being done I'd say.
Points and pixels are completely different beasts remember, points
being physical length units suited to printing size, not display size
which is what you want.
All other tools I'm using show the PDF to have the identical
dimensions and should therefore yield the same SWF dimensions.
.. measured in points, not pixels.
Can you please confirm the PDF dimensions with an alternate tool, and
then get back to me as to why the produced SWFs are of different
dimensions.
As mentioned above, playing with the values of the -s zoom=[dpi] switch
will solve the issue. As to the actual calculation being done, sorry no
clue. Matthias is really the to advise.
Regards,
Chris.
--
Robert Damiano
Java Developer | Uberflip
[email protected]
---------------
SWFTools-common is a self-managed list. To subscribe/unsubscribe, or amend an
existing subscription, please kindly point your favourite web browser
at:<http://lists.nongnu.org/mailman/listinfo/swftools-common>
