[Live-demo] geopublisher sucking in openoffice? & missing project descriptions

[Hamish]

Antonio wrote:
> we have noticed that the custom OpenOffice packages for some
> distributions (like Ubuntu, for example) removes some files that must
> exist so this extension could work.

Alex:
> (though I'm confused why you would print to OOo, 

Antonio:
> let me just a few things about Kosmo Advanced Printing:
>
> A screenshot wouldn't make sense always on a map.

I think he was just curious to see what it looked like (as I am).

> Maps need to be printed at a very high resolution that a screenshot
> surely don't have. It's not only a question of image quality, also
> about size ratios. Depending on the size of the document  you need
> elements at different sizes or resolution. Respecting the scale of a
> map is a fundamental thing. A map without an exact scale is not a map,
> its just a draw.
...
> On the other hand not only images are sent to the OOo document but
> graphical and textual elements that may be part of the map like
> descriptions on how the map is represented, legends, titles and other
> things. Those elements must be sent to the OOo Draw document because it's
> too hard work to do it manually.
> 
> Kosmo also manage multiple/complex views, legends, details, scales, etc
> ... with OOo.  OOo is far better in printing than anything we could
> develop inside Kosmo.

This is not the place, and I do not mean to second-guess Kosmo's design
decisions at all, but it strikes me that PostScript (and its child PDF)
has been the standard for this exact hardcopy output problem for, well,
decades. Touch ups, rearrangement, and further decoration can be done
in programs such as Inkscape or Illustrator.


> It is neccesary OOo oficial version.  In different linux flavours
> there are substantial differences and sometimes there is missing
> neccesary files.

if it is just missing files, and not altered source, you could easily
package those missing files and install them with an extra per-distro
kosmo-ooo-support.deb package.


Alex:
> In the future we should consider at least a partial install with the
> Spreadsheet component since dbf editing is a fairly day to day issue
> when dealing with GIS. (Case: today R refused to import a shp because
> of an accented character in a column name, Solution open the dbf in
> openoffice, fix and save)

better solution: don't use an outdated lossy format for data transfer
which forces you to reduce the usefulness of your data just to get
through the day. One day, SpatialLite, your time will come.....
;-) ;-)


regards,
Hamish