Re: [Swftools-common] possible rounding issue when using "-s zoom="

[Chris Pugh]

Hi Ben,

I'm still not sure why you'd expect rounding down to work.  Only
rounding up will. That said, the examples I posted were simply to show
the slight variation in what happens with various decimal places.
Theoretcally, 5 and above in the place farthest right, should round up
the previous place, but it doesn't always work out that way.

   pdf2swf -p 1 -s zoom=54.4336[-9] ??

  pdf2swf -p 1 -s zoom=54.434 ??

which also means that adding 0.001 and rounding up does not
consistently produce the required result. ( Mattias?  Should it? )

I know 0.431 is bigger than 0.43, but the clumsily phrased statement (
sorry ) was a reference to what happens with increasing decimal places
and eventual recurrence.  The farther you go to the right, the closer
to the lower number you become.

Regards,



Chris.

On 4 March 2010 10:24, Ben Broadhurst
<address@hidden> wrote:
> Hi Chris,
> thanks for the advice - I know that 8 decimal places is overkill, but I have
> tried rounding to a variety of digits; if it rounds up it works, if it
> rounds down it doesn't. Your first suggestion works for example, but rounded
> to 2 digits doesn't as that is rounded down. I am experimenting with simply
> adding a fixed number (0.001) to see if this is enough to fix it.
>
> Adding digits to a number doesn't make it smaller btw; 0.431 is bigger than
> 0.43 - it's only when rounding that a number with more digits can be smaller
> than one with less.
>
> Again cheers for the feedback, always appreciated!
>
> ben.
>
>
> Chris Pugh wrote:
>>
>> Did you perchance try,
>>
>>   pdf2swf -p 1 -s zoom=54.43365479 -s jpegquality=90 -S -z
>> page_01.pdf -o page_01.swf
>>
>>   pdf2swf -p 1 -s zoom=54.4336548 -s jpegquality=90 -S -z page_01.pdf
>> -o page_01.swf
>>
>>   pdf2swf -p 1 -s zoom=54.433655 -s jpegquality=90 -S -z page_01.pdf
>> -o page_01.swf
>>
>>   pdf2swf -p 1 -s zoom=54.43366 -s jpegquality=90 -S -z page_01.pdf
>> -o page_01.swf
>>
>>   pdf2swf -p 1 -s zoom=54.4337 -s jpegquality=90 -S -z page_01.pdf -o
>> page_01.swf
>>
>>   pdf2swf -p 1 -s zoom=54.434 -s jpegquality=90 -S -z page_01.pdf -o
>> page_01.swf
>>
>> ??
>>
>> Just maybe using .43365478 is rather overdoing the accuracy?  Remember
>> that the more decimal places one adds, the smaller, theoretically, the
>> number gets.
>>
>> Regards,
>>
>>
>> Chris.
>>
>>
>> On 3 March 2010 14:00, Ben Broadhurst
>> <address@hidden> wrote:
>>
>>>
>>> Hi all,
>>> I am having a minor issue with swfs being sized incorrectly. An example
>>> pdf is here:
>>> http://ps1.sk.im/7/8/78826/PDFs/page_01.pdf
>>>
>>> PDF size info:
>>> width/height: 595.22x842 points (209.98x297.04 mm)
>>>
>>> Our system converts pdfs to 450px wide, so I calculate the "-s zoom="
>>> param with the formulae (450/widthInPoints)*72, this gives me a dpi of
>>> 54.43365478
>>>
>>> So pdf2swf get run like this:
>>> pdf2swf -p 1 -s zoom=54.43365478 -s jpegquality=90 -S -z PDFs/page_01.pdf
>>> -o hiRes/page_01.swf
>>>
>>> This generates an sdf that is 449 pixels wide. Not a huge difference I
>>> know, but it gives us headaches down the line. This happens in about 7% of
>>> PDFs that I convert, and when it does happen it's always 449 - never 451
>>> which is why I thought it may be a rounding issue.
>>>
>>> In case it helps, I get the size info out using pdf2text
>>> (www.pdftron.com) using the command line:
>>> pdf2text --pages 1 --pageinfo PDFs/page_01.pdf
>>>
>>> which spits out:
>>> 595.22, 842, 0, 0, 595.22, 842, 0, 0, 595.22, 842, 180
>>>
>>> which is page    width     height     mw     mh     pw     ph    cropLeft
>>>     cropBottom     nw     nh     rotation
>>>
>>> These dimensions match what I get from Acrobat as well.
>>>
>>> Sorry for the long email - I have been trying to fix this for what feels
>>> like my entire natural life.
>>>
>>> Cheers all,
>>> ben.
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>