Hi Geoffrey,
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.
The different rendering modes are now available in the RenderingManager,
that is :
public final static int INTERACTIVE = 0;
public final static int SINGLE_THREAD_QUEUE = 1;
public final static int EXECUTE_ON_EVENT_THREAD = 2;
I now try to familiarize with Larry's Printer code.
As far as I could see, scale problems also exist in SkyJUMP printer (ex.
decoration elements
are not displayed the same size with every option).
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.
I see,
Hopefully, printing in the event thread will help in this kind of situation.
Let me know if you have ideas to improve printing core capabilities to get
a better control on how things are done in printing extensions.
Michaël
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
------------------------------------------------------------------------------
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