[Gvsig_english] printing

Thu Oct 16 10:06:39 CEST 2008

[following up on Wolfgang's point of view]

Of course, it is very important for users to be able and rely solely on
gvSIG for the final output. I was just thinking about those cases where
people simply *must* process gvSIG's output in an external software,
maybe because they have to fit it into a layout or apply drawing or
labeling styles that gvSIG does not provide (e.g. for publishing maps as
part of a book or proceedings publication with predetermined styles).

After all, a GIS is not an illustration software and it will (and
should) never provide all of the layout facilities that e.g. Inkscape
offers. For that reason, in our company, all GIS map data is part of
a workflow that involves an illustration package for producing the
final output. And I imagine it will be the same in many other places.

Right now, people import PDF or PS outputs into their layout software,
but a cleanly structured SVG would be a lot easier to edit with 
available open source tools, don't you think so?

For that reason, I would vote for developing a high-quality SVG export
filter with a focus on clean SVG data structures and fine-grained
control over vector and embedded raster data.
(note that this does not stand in the way of developing gvSIG's own
layout tools further).

I think the easiest way to develop these thoughts further is to share
a word processing document online. I have create a bare-bones Google
Docs text file. All you need is a Google Mail account which is free and
easy to get (and very useful, I think). Then click on this link and
start typing away:

You could send me a short message with your Google Mail address:

benducke at gmail.com

I could then add you to the list of people to share the document with
and you will get a link to get access to the document.

Let me know if any of you object to this and we will find another
way (maybe someone's Wiki)?

Ben

José Antonio Canalejo Alonso wrote:
> I think it would be better if gvSIG could create the final printing file. In this case the user doesn´t need another software to continue working with the map or export in other formats.
> José Antonio
> 
> 
> 
> ----- Mensaje original ----
>> De: Benjamin Ducke <benjamin.ducke at oxfordarch.co.uk>
>> Para: Users and Developers mailing list <gvsig_internacional at runas.cap.gva.es>
>> Enviado: miércoles, 15 de octubre, 2008 21:06:44
>> Asunto: Re: [Gvsig_english] Again: high-quality printing: support of the development
>>
>> How much work would it be to allow gvSIG to export map layouts
>> in SVG format (with raster maps as embedded bitmaps)?
>>
>> That way, map layouts could go straight into e.g. Inkscape
>> and be processed with all the great tools it has, before creating
>> the final printing press file.
>>
>> I don't know much about SVG, but if it has an equivalent to layers,
>> then it should be easy to produce an SVG data structure that would
>> be easy to retouch in an illustration software.
>>
>> Ben
>>
>> ----- Original Message -----
>> From: "José Antonio Canalejo Alonso" 
>> To: "Users and Developers mailing list" 
>> Sent: Wednesday, October 15, 2008 7:02:39 PM (GMT) Europe/London
>> Subject: Re: [Gvsig_english] Again: high-quality printing: support of the 
>> development
>>
>> Hello Silvio,
>> spanish developers are thinking about the list you are talking to. You can write 
>> us the bugs you`ve found. We would like to Know them because it´s a kind of very 
>> important functionality.
>> I think your workflow is a good one but gvSIG should be able to create maps in 
>> the quality you need. It would be good to know the bugs and the wished 
>> functionalities.
>> Regards
>> José Antonio Canalejo
>>
>>
>>
>> ----- Mensaje original ----
>>> De: silvio grosso 
>>> Para: gvsig_internacional at runas.cap.gva.es
>>> Enviado: miércoles, 15 de octubre, 2008 17:22:09
>>> Asunto: [Gvsig_english] Again: high-quality printing: support of the 
>> development
>>> Hello everybody,
>>>
>>> I agree with everybody on the importance about the bugs list.
>>> What about asking to the developer about such a list? After all,  we are not 
>>> talking about C.I.A stuff :-)
>>> I am sure many Spanish developers read this list. Certainly,  they have wrote 
>>> down any problem concering the printing stuff.
>>>
>>> About the features, sorry to state an obvious thing, but it is realy important 
>>> to not "reinvent the wheel".
>>> As Wolfgang declared it is really important to study carefully other softwares 
>>> before asking for some feature to incorporate into gvSIG.
>>> Me, for once, I would love see R incorporated into gvSIG to get statistical 
>>> option. Nevertheless, I can do this with Grass or with Qgis 1 (thanks to a 
>>> Summer of code project).
>>> For the publishing part Scribus is really powerful. In particular, about the 
>> pdf 
>>> stuff.
>>> The developers are really friendly and in their Mailing list is very easy to 
>> get 
>>> an answer.
>>> The link for the  Scribus' roadmap is: 
>> http://bugs.scribus.net/roadmap_page.php
>>> Here you can find the upcoming English Manual: 
>>> http://documentation.scribus.net/index.php/TOC-en
>>> Scribus works on many platforms (Windows, Linux, Mac) and there is a portable 
>>> version for Windows as well.
>>>
>>> In my view a good workflow could be: 
>>> 1. The option to save the gvSIG'S map as TIFF (with all its components: 
>> legend, 
>>> Title and so forth). Plus, the option to choose the resolution (not certainly 
>> 72 
>>> dpi as a screen-shot).
>>> 2. Modify such an image with Gimp (naturally the Tiff should be Gimp 
>>> "user-friendly").
>>> 3. Import the image in Scribus. 
>>> A Summer of Code project sponsored by Google this year has seen the 
>>> incorporation of the library of Image-Magick into Scribus in order to load 
>> many 
>>> new formats into Scribus. 
>>> This feature will be available with the realase of the 1.3.6 version.
>>> Now the 1.3.5 is under devolopment. The 1.3.3. 12 version is the stable one.
>>> 4. Save the image as pdf from Scribus.
>>> 5. Modify the Pdf with an open-source software is the tricky part. 
>>> At present, for example, a good sofware is pdf-edit 
>>> (http://sourceforge.net/projects/pdfedit).
>>> But it is really "young" and buggy. Plus, it only runs well on Linux and its 
>>> development is really slow.
>>>
>>> Best regards
>>>
>>> Silvio
>>>
>>>
>>>       Scopri il blog di Yahoo! Mail:
>>> Trucchi, novità e scrivi la tua opinione.
>>> http://www.ymailblogit.com/blog
>>>
>>> _______________________________________________
>>> Gvsig_internacional mailing list
>>> Gvsig_internacional at runas.cap.gva.es
>>> http://runas.cap.gva.es/mailman/listinfo/gvsig_internacional
>>
>>
>>       
>>
>> _______________________________________________
>> Gvsig_internacional mailing list
>> Gvsig_internacional at runas.cap.gva.es
>> http://runas.cap.gva.es/mailman/listinfo/gvsig_internacional
>>
>>
>>
>>
>> ------
>> Files attached to this email may be in ISO 26300 format (OASIS Open Document 
>> Format). If you have difficulty opening them, please visit http://iso26300.info 
>> for more information.
>>
>>
>> _______________________________________________
>> Gvsig_internacional mailing list
>> Gvsig_internacional at runas.cap.gva.es
>> http://runas.cap.gva.es/mailman/listinfo/gvsig_internacional
> 
> 
> 
>       
> 
> _______________________________________________
> Gvsig_internacional mailing list
> Gvsig_internacional at runas.cap.gva.es
> http://runas.cap.gva.es/mailman/listinfo/gvsig_internacional
> 
> 

-- 
Benjamin Ducke
Senior Applications Support and Development Officer

Oxford Archaeology Ltd
Janus House
Osney Mead
OX2 0ES
Oxford, U.K.

Tel: +44 (0)1865 263 800 (switchboard)
Tel: +44 (0)1865 980 758 (direct)
Fax :+44 (0)1865 793 496
benjamin.ducke at oxfordarch.co.uk

------
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.