Hi,
If you have your hands dirty already I would suggest to make some preparations
for making it easier to write geospatial PDF files in the future. The
essential thing to do is to capture the envelope of a map as polygon WKT and
store is somewhere. For example it could be saved into a plain text file that
uses the same filename base "output_map_2013_03_15_neatline.txt" Saving also
the SRID would be a good addition but then you should ask user to give it
because OpenJUMP is not projection aware. I will show later an example about
how this into can be utilized.
If we are saving some metadata then perhaps there could be an option to save
also other metadata that can be embedded into PDF file. GDAL PDF driver page
http://www.gdal.org/frmt_pdf.html is listing these metadata items: AUTHOR,
CREATOR, CREATION_DATE, KEYWORDS, PRODUCER, SUBJECT, TITLE
Usage example:
AUTHOR="Jukka Rahkonen http://latuviitta.org";
CREATOR="SkyJUMP/OpenJUMP PDF Writer"
CREATION_DATE=D:20121122132447+02'00'
KEYWORDS="OpenJUMP, MAP"
PRODUCER="name of the PDF library"
SUBJECT="Some subject"
TITLE="OpenJUMP PDF Map"
The date format is D:YYYYMMDDHHmmSSOHH'mm'
For 22 nov 2012 13:24:47 GMT+02:
D:20121122132447+02'00'
These metadata could also be stored into text file for the future needs but I
guess that PDF libraries can also write them directly into PDF file. This page
shows how some software is doing it and what it the result
http://www.verypdf.com/pdfinfoeditor/pdf-metadata.html
And here comes an example how the neatline metadata can be used in
post-processing.
First I created a PDF map from a non georeferenced tiff image with
gdal_translate as
gdal_translate -of PDF base.tif base.pdf
We can imagine this PDF came from OpenJUMP PDF Writer. Then I draw a polygon
and captured the WKT and I decided that the SRID is EPSG:4326. The following
command converts the base.pdf file into geospatial PDF
gdal_translate -of PDF -a_srs epsg:4326 -co NEATLINE "POLYGON ((21.266055555555
557 42.01149896236421, 21.266055555555557 42.02038333333333, 21.278203573003132
42.02038333333333, 2
1.278203573003132 42.01149896236421, 21.266055555555557 42.01149896236421))"
base.pdf geospat.pdf
Gdalinfo about geospat.pdf confirms that it is location aware now
gdalinfo geospat.pdf
Driver: PDF/Geospatial PDF
Files: geospat.pdf
Size is 537, 393
Coordinate System is:
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.0174532925199433,
AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4326"]]
Origin = (21.266055555555546,42.020383333333299)
Pixel Size = (0.000022664211656,-0.000022664211656)
Metadata:
DPI=72
NEATLINE=POLYGON ((21.266055555555557 42.020383333333328,21.266055555555557
42.0114989623642,21.27
8203573003125 42.0114989623642,21.278203573003125
42.020383333333328,21.266055555555557 42.020383333
333328))
Corner Coordinates:
Upper Left ( 21.2660556, 42.0203833) ( 21d15'57.80"E, 42d 1'13.38"N)
Lower Left ( 21.2660556, 42.0114763) ( 21d15'57.80"E, 42d 0'41.31"N)
Upper Right ( 21.2782262, 42.0203833) ( 21d16'41.61"E, 42d 1'13.38"N)
Lower Right ( 21.2782262, 42.0114763) ( 21d16'41.61"E, 42d 0'41.31"N)
Center ( 21.2721409, 42.0159298) ( 21d16'19.71"E, 42d 0'57.35"N)
Band 1 Block=537x1 Type=Byte, ColorInterp=Red
Band 2 Block=537x1 Type=Byte, ColorInterp=Green
Band 3 Block=537x1 Type=Byte, ColorInterp=Blue
This example should be taken as a demonstration which shows that it is possible
to add georeferencing afterwards but not as an instruction about how to do is.
Gdal_translate as used in the example is not the right tool because it is
rasterizing PDF vectors in PDF to PDF conversion which is not desired.
-Jukka Rahkonen-
Michaël Michaud wrote:
Hi Larry,
All that makes sense.
Thanks for the detailed answers to my last question and to the few next ones ;-)
I'll keep them preciously as diving in the rendering pipeline is always a
challenge for me.
By the way, I already could print to pdf with your printer + openjump, but I'd
to
deactivate a few lines as I did not update RendererManager yet.
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<mailto:Jump-pilot-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
------------------------------------------------------------------------------
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
