I have had a look at the transcoding hints and i was wondering which one to use to get the output correct This is the one i have looked at now: PDFTranscoder.KEY_DEVICE_RESOLUTION I also see that there is something referred to as :PDFTranscoder.KEY_PIXEL_UNIT_TO_MILLIMETER,new Float(0.2645833f) To mee it looks like the latter is the right one, but i am not entirely sure.. Any help is appreciated.
On Wed, Aug 6, 2008 at 1:51 PM, Lars Eirik Rønning <[EMAIL PROTECTED]>wrote: > Thank you so much Thomas. > That helped me a lot! > > > > On Wed, Aug 6, 2008 at 12:32 PM, <[EMAIL PROTECTED]> wrote: > >> >> Hi Lars, >> >> "Lars Eirik Rønning" <[EMAIL PROTECTED]> wrote on 08/05/2008 10:14:48 >> AM: >> >> > I have been using the batik rasterizer to generate pdf from my svg file. >> >> > The strange thing is that my .svg fil contains a rectangle which is >> > 311pt. >> >> Actually your SVG document contains a rectangle that is 311 user >> space units, where in your document 311 user space units are mapped >> to 311 _px_ units. Where by default Batik uses 96 px per inch (user >> agents are supposed to pick and appropriate px to real world unit >> conversion - 96 is a common px->inch conversion for SVG UserAgents), >> by contrast a pt is defined as 1/72nd of an inch always. >> >> > When i convert this to pdf the pdf version is 243pt. >> >> Right 311px/96pxPerIn ~= 3.25in * 72ptPerIn ~= 243pt >> >> > I have not set any particular transcoding hints and was hoping that >> > the conversion would be done more or less seamlessly. >> >> To fix this you can either use 'pt' instead of 'px' units on >> your outermost SVG (which seems to make the most sense to me): >> >> width="311.811pt" height="311.811pt" >> >> Or you can override Batik's default px to real world mapping >> by using the '-dpi' command line option (and/or transcoding hint): >> >> -dpi 72 >> > >
