Thanks, Thomas, for your explanations. I guess I'll have to find a quiet
hour to do a few more tests. What you say makes sense. At any rate, I
was primarily looking into the case where you have real-world lengths
(i.e. not pixels) given for the graphic size and a proper viewBox. I'll
report back ASAP.
On 12.06.2008 18:41:12 thomas.deweese wrote:
> Hi Jeremias,
>
> Jeremias Maerki <[EMAIL PROTECTED]> wrote on 06/11/2008 08:01:11 AM:
>
> > Well, PDF as such doesn't have a "resolution" as we're primarily talking
> > about a vector graphics format. But of course, as soon as we're talking
> > about a bitmap (or effects resulting in bitmap generated by Batik) a
> > resolution becomes important. In FOP we distiguish two resolutions:
> > - source resolution: Mapping of 1px to a length when interpreting pixel
> > sizes on the input side (ex. border="solid 1px" in XSL-FO).
> > - target resolution: The same, but on the output side (meaning the
> > resolution of the bitmaps that are produced)
> >
> > Batik doesn't have that distinction AFAIK. Thomas and I once talked
> > about this. The result was a special setting in the PDFTranscoder:
> > org.apache.fop.svg.PDFTranscoder.KEY_DEVICE_RESOLUTION
> > (accepts the resolution in dpi, datatype Float)
>
> Right Batik doesn't have this distinction. It's a distinction
> that becomes important when you are embedding raster objects into
> a vector format (like PDF). We might need/want this for
> the SVGGraphics2D but on the rendering side this is already taken
> care of by the Graphics2D interface (the Graphics2D should by default
> have 1 unit == 1pt, however you can investigate the actual user space
> to device transform to know what the mapping from pt->pixels is for
> the device the Graphics2D is associated with - and Batik does this
> for many things most notably filters).
>
> > With this hint, Batik is tricked into rendering the bitmaps in a higher
> > resolution.
>
> Well more correctly with this hint Batik is told the destination
> resolution through the Graphics2D interface is different from the
> default 1 pix = 1pt. There is no tricking involved, this is exactly
> the way the Graphics2D API was designed to work.
>
> > In PDF there's a compensating transformation matrix that
> > makes sure the size of the output is correct. When working with SVG in a
> > FO context, FOP's target resolution is automatically used. For Batik,
> > there's currently no connection between the -dpi flag on the rasterizer.
>
> Well the -dpi flag adjusts the mapping between real world units,
> like 'in' 'pt', 'cm', and pixels ('px'). For a properly constructed
> SVG file this is sufficient to adjust the resolution of the output
> for raster formats.
>
> > BTW, some time ago, I submitted a patch for fixing the output resolution
> > in the BitmapTranscoder:
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=44276
> > Thomas recently fixed something in the same are but my patch is still
> > open. I'm not sure if the effect is the same or what the status is.
>
> I fixed the metadata in the output. Your patch seems to treat
> '-dpi' as a global scaling parameter which really isn't correct.
>
> Let me try to illustrate how '-dpi' works. Given the following
> outermost svg tag:
> <svg width="8in" height="10in" viewBox="0 0 800 1000">
>
> If you provide '-dpi 300' you will get an image that is
> 2400x3000 pixels who's content comes from the rectangle 0,0 800x1000
> of the infinite canvas. If you don't have the viewBox then you
> will get a 2400x3000 pixel output that comes from the rectangle
> 0,0 2400x3000 of the infinite canvas.
>
> Further if the outermost svg tag is:
> <svg width="800" height="1000" viewBox="0 0 800 1000">
>
> Then the '-dpi 300' command line option will do nothing (as
> far as this analysis is concerned). This is because width="800"
> says I want an 800 pixel output regardless of the real world unit
> to pixel mapping.
>
> If you wanted a 2400x3000 pixel output from that document then
> you should specify "-width 2400 -height=3000" on the command line.
>
> Now it's worth noting that you simply can't do what you want if
> you have the following root svg element:
> <svg width="800" height="1000">
>
> Because without the viewBox specification the region of the canvas
> that is to be used should match 1:1 with the output image,
> where 1px == 1 user space unit.
>
> Now of course we can provide non-conformant modes in Batik that
> the user can request, and it may be useful to add a 'scale' option
> that effectively provides a viewBox transform that corresponds to
> 0,0 WidthxHeight and then scales the width and height, but really
> the correct answer is for people to specify width and height with
> real world units (otherwise what does dpi mean?) _and_ provide a
> correct viewBox. Unfortunately many people do neither.
>
> Given the above I don't think the proposed patch which (if I
> understand it correctly) will overload the meaning of 'dpi' is a
> good solution. Do you agree with me after my rather long winded
> response?
>
> > On 09.06.2008 19:01:41 Lars Eirik Rønning wrote:
> > > Hi.
> > > I realize this may be an apache fop topic, but because i do use batik
> as my
> > > pdf generator i hope you will help me..
> > >
> > > When i try to add a resized image into my svg the problem seems to be
> that
> > > the quality is not good enough when rendering the pdf
> > >
> > > When i create my pdf using the batik-rasterizer i have understood that
> the
> > > image will be created with dpi 72.
> > > Does this mean that i need to embed my high res image and then usethe
> scale
> > > operator to have it output at a greater resolution?
> > >
> > > The -dpi flag when using the batik-rasterizer does not work well when
> > > generating pdf as i have understood that pdf's do not have any notion
> of the
> > > resolution at all..
> > >
> > > I hope you will be able to help me out.
> > > It does not suffice to have a decent rendering of the image when
> printing
> > > from my pdf..
> >
> >
> >
> >
> > Jeremias Maerki
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
