@Michaël,
A few hints: com.isa.jump.plugin.PrintPlugIn is the UI class that uses
PrinterDriver and PDFDriver to do the work. You can use PrintPlugin as is
with some localization work, or you can use as an example to build your own
UI class.
@Geoffrey,
In order to use the new print architecture you might want to use some of
the pubic code in PrinterDriver after it is translated to OJ. As a minimum
you might try:
PrinterDriver.disableDoubleBuffering(yourLayerViewPanel);
yourLayerViewPanel.getRenderingManager().setRenderingMode(
RenderingManager.EXECUTE_ON_EVENT_THREAD);
yourLayerViewPanel.getRenderingManager().renderAll();
yourLayerViewPanel.getRenderingManager().copyTo(graphics);
yourLayerViewPanel.getRenderingManager().setRenderingMode(
RenderingManager.INTERACTIVE);
PrinterDriver.enableDoubleBuffering(yourLayerViewPanel);
regards,
Larry
On Wed, Jun 12, 2013 at 4:01 PM, Michaël Michaud <michael.mich...@free.fr>wrote:
> 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> 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
> listJump-pilot-devel@lists.sourceforge.nethttps://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
> processeshttp://p.sf.net/sfu/servicenow-d2d-j
>
>
>
> _______________________________________________
> Jump-pilot-devel mailing
> listJump-pilot-devel@lists.sourceforge.nethttps://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.auhttp://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
> listJump-pilot-devel@lists.sourceforge.nethttps://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
>
>
------------------------------------------------------------------------------
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
