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

Reply via email to