Dear Michael
I suspect the issues raised by Larry are central to the issues I have
had with printing. In my printer plugin I have three options for
printing and they each give slightly different results depending on what
is being printed (scale of map, size of text and patterns etc). It is
often necessary for a user to try each mode then pick the results that
best suits their needs.
Ideally the core renderer should do the job, but I appreciate the
optimisations that are necessary for the UI may make this not easily
possible. I have come across a similar problem with printing large
JTables (several thousand rows) where I had to "manually" force the
image to be fully painted for the printing process. Otherwise I found
that only part of the image would actually get printed, depending on
where the UI had scrolled to on the screen.
Whether the problem can be (economically) fixed is another problem
Geoff
On 10/06/2013 04:28, Michaël Michaud wrote:
Hi Larry (Becker),
I'm slowly progressing on this topic.
I added different rendering modes in RenderingManager,
Except the printing stuff, there are only a few classes where new
modes are used.
I tested the change on AbstractZoomTool :
In OpenJUMP, MouseWheel zoom is done on an INTERACTIVE mode
In SkyJUMP, you use the EXECUTE_ON_EVENT_THREAD mode
I feel like INTERACTIVE mode gives a better feedback on large datasets
Is there any motivation to have changed rendering mode to
EXECUTE_ON_EVENT_THREAD in SKYJump for mousewheel zoom ?
Michaël
Hi Michaël,
Thanks for starting this effort. I'll try to answer your questions
as best I can. When I wrote this code four years ago, I was immersed
in printer lore that I have mostly forgotten. Here are a few things
that I can recall: (excuse my lecture tone, I know you are very
knowledgeable on the subject of rendering)
1. Rendering for interactive display has completely different goals
than rendering for printing. It is mostly an issue of responsiveness
vs. quality. The JUMP render architecture, as you well know, has
excellent responsiveness and an especially quick redraw capability
thanks to per-layer double buffering. In this aspect it far
outperforms ArcMap and many other GIS programs. While this is a
positive for interactive use, it is a huge negative for printer
rendering. Having a timer-based repaint from an off-screen buffer
occur while printing causes the output to change from vector to
raster mode, so defeating double-buffering is very important.
2. The next issue is that rendering can be multi-threaded and this
can cause problems for the inherently linear print process. The best
mode for printing is to render on the GUI thread because this will
block other things from interfering with the print process. This
causes side effects such as blocking communication with WMS and other
server based layers, but this is taken care of in the PrinterDriver
by creating a Runnable to run in a separate task, but under control
of the PrinterDriver.
3. The next issue is resolution. Normally, of course, we render to
screen resolution which is usually between 72 and 120 dots per inch
or a pixel size of .~ 28 mm. I do some tricks to increase the
apparent resolution without changing the scale. This is especially an
issue when there are raster layers. The PrinterPlugin interface has
options to double the resolution of raster layers so that even when
zooming in on a PDF it still appears smooth.
4. There is the issue of transparency. This is supported in PDF so
it isn't a problem there, but it will cause problems for a real
printer. The UI has options to defeat transparency and other style
settings that might not look quite so nice on a printer.
5. There are also issues of line width scaling that make linestrings
almost invisible at printer resolutions.
Getting back to more practical advice about implementing PDF
generation in OpenJump, I would recommend you start first by
implementing the SkyJUMP PrinterDriver and PrinterPlugin. This will
allow you to print to PDF with a free PDF print driver without
getting into the iText library. You can experiment with commenting
out the RenderManager enhancements to see the effects, which for some
situations may not be too bad. Once you get the driver working it
should be easy add the iText library which gives the direct PDF
generation with layers.
When testing the PDF output always determine first if it is
generating true vectors by zooming in fully. Then you may also see
the effects of decimation as implemented in Java2DConverter and even
in java.awt.Graphics2D.
That's all for now. I've rambled on enough. Let me know what else I
can clarify.
Regards,
Larry
On Thu, Mar 14, 2013 at 3:00 AM, Michaël Michaud
<michael.mich...@free.fr <mailto:michael.mich...@free.fr>> wrote:
Hi Larry (Becker),
I've started pdf printer integration in openjump and the main
change that I face
is one in RenderingManager where you introduced 3 rendering mode
public final static int INTERACTIVE = 0;
public final static int SINGLE_THREAD_QUEUE = 1;
public final static int EXECUTE_ON_EVENT_THREAD = 2;
Before I port this change to OpenJUMP (maybe I'll wait after
1.6 release),
I'd like to have a better vision of what problem it is
supposed to solve and
to know if it is related to the add of printing capabilities.
Thanks for all,
Michaël
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
--
Dr Geoffrey G Roy
Cadplan
129 Gloster Street, Subiaco WA 6008
Tel: (08) 9381 4870 Mob: 04000 31298
Email: ge...@cadplan.com.au
http://www.cadplan.com.au
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
