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