Print specifications

User requirements

  1. choix de l'empreinte par échelle / taille de document (cf. impression)
    • details:
      • for each page the user can set those params: scale (implies what layer we use), resolution (printer), paper size, orientation, rotation, position, comments, title
    • open questions:
      • Do we support full customization of the UI like in CW3? Or do we offer just two kind of UIs (single-page and multi-page) with the possiblity to disable some features (rotation, zoom factor, ...)? The customer seems to want server side templates to generate the whole web site automagically or something like that... need a more global investigation for that
    • status: For the multi-page version, we can start for what have been used in the "PVI swisstopo demo".
  2. choix de la résolution pour le raster 96, 150, 300
    • details: The list of available resolution is configurable
  3. Visibilité de la zone d'empreinte
    • status: For the multi-page version, we can start for what have been used in the "PVI swisstopo demo".
  4. Déplacement/rotation de la zone d'empreinte
    • details:
      • also include snapping between pages when moving them.
      • it's OK to have one tool "enabled" at a time in order to avoid having more than one layer wanting events. So we need a way to know what tool "has the focus"
      • possibility to have textbox for setting the rotation in addition to the "graphic" edition.
    • status: We can use EditFeature from OL with some "customisation" like it was done for Mediapost.
  5. création de document multi-page (cf. module de PVI)
    • details:
      • Page numbering can be activated: Page 1/n
    • status: The PVI module is now in it's own file as an Ext component. So it would be easy to start from there.
  6. activation de l'affichage des attributs (multi-page)
    • details:
      • the list of printed attributes can be determined from what the user has selected (the order as well) in the "query result" tool.
      • the listed features are highlighted on the printed map.
      • advanced formatting for the attribute values (localisation, translations, call to external formatting functions, replaced by icons).
      • possibility to have three modes (only the first one being of some priority):
        • the map alone on a page followed with one or more pages with the features' attributes in a grid
        • the map on the top half of the page and the grid on the bottom, eventually followed by other pages with the rest of the features
        • same as the previous mode, but we have to repeate the map on each page with only the current page's feature highlighted
    • status: good luck
  7. possibilité de mettre un titre, une description, ou autre champ texte/logo libre)x de mettre la légende des thèmes
    • details:
      • that pushes for a kind of PDF template language (must be secretary level user compatible) to define the page layout. That would allows place holders for inserting:
        • per "map" user defined values (title, comments). These information may be printed on one or many pages per map.
        • the attribute grid
        • some logo
        • result from some developer's custom functions
  8. activation vecteur (si couche et type compatible)
    • details:
      • see the "Data sources" chapter for details
      • must be able to merge transparent bitmaps together.
      • if the vector mode is not enabled (by config), the "server side" vector layers are requested in bitmap mode to the map server.
      • we assume all the services are providing the data in the correct projection.
  • status: very complex. need to study the PDF libs available to see what can we done.
  1. activation graticule/ northing / coordonnées /échelle (cf cw3)
    • details:
      • the template system allows the developper to position those blocs.
      • the scalebar type may be from different types: see MapServer scalebar types
      • the units of the scale bar may depend on the length (switch meters/kilometers)
      • the numbers may be configurated to include separators (1'000,05m) (separators may depend on servers locale)
      • the unitsystem may be configurated (km, mi, dd)
    • status: MapServer can generate that for us.
  2. choix de l'output PDF +(PNG,JPEG,TIFF,...)
    • details:
      • in multi-page in raster output, the images are ZIPed together
      • Titles, attributes and the other blocs are not shown in raster output. It's just the map with the type 1&2 (c.f. "data sources") layers shown.
      • the output type is choosable by the end user but the list is configurable by the developper.
  3. Support for printing stats (choropleth, pie charts, histograms, ...) and the legends.
  4. We have to be able to support all the mapping services available on earth and the known universe.

Backend requirements

  1. support des différents sources de données supportées par OL (pas seulement WMS), avec réserve sur les fonds ne permettant pas ce genre de traitement (googlemaps, ...)
    • details:
      • We don't have to respect tiled layers. we can load the whole layer in one query.
  2. gestion des appels pour sursampler les raster (si type de couche compatible)
    • open questions:
      • What does that mean?
  3. possibilité de gestion de gérer les couches vecteurs en vecteur
  4. gestion des droits par rapport à l'impression
  5. possibilité de gérer la sécurisation /encryptage PDF (il faudra choisir le bon module PDF)
    • open questions:
      • This needs more info. Just here to make sure we think about it, the requirements will come later.
  6. the server module must validate what is given by the browser module (DPI in range, valid layer, ...) for security reasons.
  7. must be integrated with the accounting module.

Setup requirements

  1. mise en place par paramétrisation (pas de prog, javascript,...) pour cas simple, se basant sur un template classique d'impression

Misc

  1. fonctionnement sans plugin/ad-on dans IE>=6, Firefox>=2, Safari>=3
  2. Délais de génération du PDF sur le serveur ok
    • details:
      • means less than 30s per page.
  3. conservation d'un mode d'impression simpliste html "as it is"
    • details:
      • that means: the user clicks on something, a new navigator window opens with content we want to print, but in HTML.

CW3

See http://www.cartoweb.org/doc/cw3.4/xhtml/user.pdf.html for the doc.

See https://project.camptocamp.com/svn/fribourg_sig_guichetcarto/trunk/fribourg/client_conf/exportPdf.ini for a config example.

See http://ivs-gis.admin.ch/ for an example.

Data sources

type 1

All the sources of geographic information rendered as bitmap. That means:

  • WMS
  • MapServer
  • TileCache (will be translated by a direct WMS request)
  • KaMap
  • MapGuide
  • WorldWind

Those can come from the local disk or from an HTTP get.

type 2

All the vectorized geographic data sources:

  • WFS
  • !GeoRSS
  • GML
  • KML

Those can come from the local disk or from an HTTP get.

status:

  • we may resort to the ability of MapServer or GeoServer to output PDF or SVG. But that introduces a limitation on what server is supported and what kind of data source is supported.

If the vector mode is enabled, this type is rendered as vectors in the PDF output. Otherwise, we ask the map server to convert them as raster.

type 3

All the vectorized data coming from the web browser along with the definition of what has to be printed. This kind of data contains both the shapes' definition (polylines, points and polygons) and their style (color, line style, filling colors, ...)

This type is rendered as vectors in the PDF output and only if the vector mode is enabled.

Architecture Studies

The most critical part of the print module (server side) is the PDF generation. So greate care as to be taken while selecting the lib we are going to use.

The things the PDF lib will have to be tested for are:

  • try to render a simple page with title, map, some vectors and text rendered of the map and a footer.
  • check how the transparent bitmaps are handled (may need to use another lib to merge the bitmaps first)
  • check that grids can be easily rendered
  • check if PDFs or SVGs can be inserted in other PDFs and that its possible to control their alignement accuratly.

Reportlab toolkit

An open source python lib exists for creating PDF: http://www.reportlab.org/rl_toolkit.html

Some part of it (platypus) make it easy to do layouts, tables&CO.

It can generate encrypted PDFs, but there is hefty license fee (£15'000) for this module. We can use iText as filter for doing that for free...

There is no way to include another PDF in a PDF and the lib seems cripled (in a "you want more feature, you pay a license" kind of way).

pyPDF

Another open source python lib, but this one to manipulate PDF files: http://pybrary.net/pyPdf/

It can merge PDFs together and encrypt them. But I don't think you can insert a PDF into the page of another PDF. So this helps only for encryption.

iText

Open source Java library that can read, write and encrypt PDF documents: http://www.lowagie.com/iText/

Seems to fill all the needs... but it's java...

Interesting stuff:

I did some test code and it seems to fill all our needs and more.

Conclusion

iText/Java seems the way to go.

To avoid needing a tomcat running on the client machine, we can make two interface for the print module:

  • filter mode: works as a filter that takes the configuration (coming from the client) from STDIN and outputs the PDF into STDOUT. That can be called from python/pylons with a "system" call.
  • web mode: works as a servlet and receives the configuration as a CGI parameter and returns the PDF.