xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Carr" <Paul.C...@express-gifts.co.uk>
Subject RE: Bug ( I think)
Date Thu, 09 Feb 2006 10:31:56 GMT
Thanks guys,
                     I took a look at the source for PrintTranscoder,
and as far as I can see it doesn't query the print drivers for imageable
area. If you could point out the bit that does this Jeremias I'd be very
 I'm not using the print() method on PrintTranscoder, I've defined my
own , the only method that gets called on PrintTranscoder when printing
is the print(Graphics,PageFormat,int) method and this is where I'm
getting confused. In my main class I create a PrintTranscoder &
PrinterJob, get the pageFormat from the printerJob, set the paper to be
a full A4 sheet, and set the imageable area to the full size of the
                PrinterJob printerJob = PrinterJob.getPrinterJob();
                PageFormat pageFormat = printerJob.defaultPage();
                Paper pp=pageFormat.getPaper();
                PrintTranscoder prm = new PrintTranscoder();
                TranscoderInput ti = new
                prm.transcode(ti, null);
I then call "setPrintable" on the PrinterJob with the new pageFormat (
the one that should start at 0,0) and call print()
I stuck a breakpoint at the start of the above method, and the start of
the printTranscoders print(graphics,pageFormat,index) method, and
stepped through the code. I stopped on the printerJob.print() line above
and looked at the pageFormat......imageableArea = (0,0,594,841). I then
stepped over it and the debugger stopped at the breakpoint at the start
of the printTranscoders print(g,pf,i) method......looked at the
pageFormat passed in there......imageableArea =
(12,12,571,817).....different pageFormat !!!
I've never seen this behaviour before....whenever I've called
printerJob.setPrintable(printable,PAGEFORMAT), that is the pageFormat
that gets passed to the printables print(g,pf,i) method.
I managed to get it printing as desired by changing PrintTranscoder to
instead of using the pageFormat :-
        //                pageFormat.getImageableY());
but I'd obviously rather not have to do that ......  anyone got a good
understanding of PrinterJobs / Printables who can tell me why the heck
my pageFormat is changing en route ???? If it is querying the printer
drivers for an imageable area, that might explain things, but I can't
see where it's doing that, and how that gets called when you do
I need to get this sorted while there are still trees left on this
planet (My wastepaper bin is getting very heavy ;-)
Best Regards
Confused of England
-----Original Message-----
From: Patrick Egan [mailto:patrick.egan@greshamticket.com] 
Sent: 08 February 2006 13:34
To: batik-users@xmlgraphics.apache.org
Subject: Re: Bug ( I think)
Hi Paul,
I think Jeremias is correct.
Try adding a TranscodingHint to the PrintTranscoder -
should stop the scaling, but probably not  x, y offset of the printed
image based on the getImageableX and getImageableY evaluated after the
call to PrinterJob.validatePage.


Jeremias Maerki wrote: 
Have a look at the source code for PrintTranscoder. It queries the
printable area (ImageableWidth/Height/X/Y) from the printer driver and
adjusts accordingly. For many use cases this will be ok, but obviously
not in your case. Maybe it needs a switch/TranscodingHints there.
On 08.02.2006 11:39:33 Paul Carr wrote:
	I just tried printing the same SVG from inkscape, and it's
perfect, so
	there is definitely a problem with batik's PrintTranscoder. I'm
	out the Print API as I've used java before to print A4 JPEGS
that had to
	be accurately sized and positioned and it worked fine. (well....
	from using most of the RAM in the machine !)
	I've managed to get an extension till Friday before I give my
	recommendations for the project.....if anyone has any idea
what's going
	on here, please let me know a.s.a.p.
	Thanks again
	-----Original Message-----
	From: Paul Carr [mailto:Paul.Carr@express-gifts.co.uk] 
	Sent: 08 February 2006 10:19
	To: batik-users@xmlgraphics.apache.org
	Subject: RE: Bug ( I think)
	Thanks Cameron,
	           Have you tried printing a hardcopy ? It looks correct
	squiggle, but when I print it to A4 the right hand side of the
image is
	not on the edge of the paper, neither is the bottom. The image
has been
	scaled down to 200 x 288 mm, which isn't cool when you're trying
	print accurately to a somewhat expensive certificate. I've
attached a
	scan of the A4 result after printing your SVG to help clarify
	issue.(had to use serious compression to get through apache's
	daemon....so apologies if it looks a bit naff)If you open it in
	something with a grey background it is easy to see where the
paper edge
	I'm not sure whether it's my printer doing some jiggery pokery.
	anyone would like to help diagnose this please use squiggle to
print off
	a hardcopy of the attached SVG ( making sure you set all the
margins to
	0.0 in the print dialog)
	-----Original Message-----
	From: Cameron McCormack [mailto:cam-batik-users@aka.mcc.id.au] 
	Sent: 07 February 2006 21:37
	To: batik-users@xmlgraphics.apache.org
	Subject: Re: Bug ( I think)
	Hi Paul.
	Paul Carr:
		Has anyone got an example portrait A4 SVG file that will
print to all
		extremities of the page from squiggle ?
	This does:
	  <svg xmlns="http://www.w3.org/2000/svg"
	       version="1.1" width="210mm" height="297mm" viewBox="0 0
210 297">
	    <rect width="100%" height="100%"
	          stroke="black" stroke-width="1" fill="none"/>
	    <circle cx="0" cy="0" r="20"/>
	    <circle cx="210" cy="0" r="20"/>
	    <circle cx="0" cy="297" r="20"/>
	    <circle cx="210" cy="297" r="20"/>
	Note how the viewBox defines the area of the coordinate system
that is
	mapped into the 210mm x 297mm space.  In this case, one user
unit is the
	same as 1mm.
	If you convert this file to a PDF you should see that it
	properly on the A4 page, and that the rect and the mid-points of
	circles are right on the corners of the page:
	  java -jar batik-rasterizer.jar a4.svg -m application/pdf -d
	 Cameron McCormack                ICQ: 26955922
	 cam (at) mcc.id.au                      MSN: cam (at) mcc.id.au
	 http://mcc.id.au/                JBR: heycam (at) jabber.org
	To unsubscribe, e-mail:
	For additional commands, e-mail:
	To unsubscribe, e-mail:
	For additional commands, e-mail:
Jeremias Maerki
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org

Important - This e-mail and the information that it contains may be
confidential, legally privileged and protected by law. Access by the
intended recipient only is authorised. Any liability (in negligence or
otherwise) arising from any third party acting, or refraining from
on any information contained in this e-mail is hereby excluded. If you
not the intended recipient, please notify the sender immediately and do
disclose the contents to any other person, use it for any purpose, or
or copy the information in any medium. Copyright in this e-mail and
attachments created by us belongs to the author and
also asserts the right to be identified as such and object to any
--------------------------------------------------------------------- To
unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org For
additional commands, e-mail: batik-users-help@xmlgraphics.apache.org

View raw message