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 <[email protected]> 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 >> <[email protected]> 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. >>> >>> >>> >>> >>> >>> >> >> >> >> >
