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. --------------- 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>
