[Qgis-user] Re: [Qgis-developer] Request for Enhancement: PDF export for post-processing

Alex Mandel tech_dev at wildintellect.com
Fri Mar 5 00:35:46 EST 2010


As I mentioned in IRC here it the thread about the same topic leading up
to the november hackfest.
http://n2.nabble.com/SVG-export-td3792011.html#a3792011

You can see it in the topic list too
http://www.qgis.org/wiki/2._QGIS_Hackfest_in_Vienna_2009

In the end it seems like mapsever, osm and a bunch of other projects are
stuck because there isn't a good rendering toolkit, or we aren't making
use of the current ones. So we have the option to try and patch Qt svg
support to maybe solve it or to hunt around at other svg rendering
libraries and try to bring those into the fold, not sure what
openoffice, scribus or inkscape use but those seem like good places to
start asking.

I guess the question is do we know a programmer who could solve this
issue if we shuffled money their way from Milo's source?

Thanks,
Alex

Milo van der Linden wrote:
> Hello Tyler!
> 
> Thank you for sharing this. Indeed as described in the article on the
> wiki; the main point is: Don't build advanced cartographic composition
> functionality into any of the GIS products that are on the OSGeo stack.
> Less is more.
> 
> If the GIS(es) could export to PDF with
> * PLAIN vector-work; ordered in PDF layers
> * Text as text and not as letter-contours (perhaps even with standard
> font embedded)
> * Symbol nodes as dots, ordered per layer based upon attributes
> 
> My contact would be well served!
> 
> Even putting effort in creating advanced symbology would be to much,
> use-it will want to change even that in his desktop publishing
> environment, so a simple node and the fact the node is on a certain pdf
> layer would be enough information for him to transform all the nodes
> into the symbology he wants.
> 
> Right now he has days of work to create a single map of a city
> post-processing the GIS data (mainly cleansing) and then the
> cartographic work starts. If we could remove the cleaning job, it would
> be a win of 2 to 6 days per city map which would be excelent!
> 
> Tyler Mitchell (OSGeo) wrote:
>> Hi Milo, I just missed you in IRC.  I'm not a QGIS developer but I've
>> been trying to clarify an idea a few folks started a couple years back.
>> Specifically, establishing a standard way of doing high quality,
>> vector/raster output which would do pretty much what you are describing.
>>
>> Standing back as a user, I think many projects have this challenge and
>> could work together if the approach was abstracted and some common
>> underlying tools agreed on or tested.
>>
>> Without writing it all out, my thoughts are here and might be
>> interesting to you.  Dane's work on Quantumnik are encouraging and, in
>> my little world, are pushing the envelope of what's described here too:
>>
>> http://wiki.osgeo.org/wiki/OSGeo_Cartographic_Library  See the first two
>> sections for clarity.  The rest is a brainstorm that's not well
>> organised.
>>
>>
>>
>> Milo van der Linden wrote:
>>  
>>> Hello People!
>>> I have a question.
>>>
>>> This summer I met someone of use-it http://www.use-it.be/ belgium at the
>>> OpenStreetMap State of the Map.
>>>
>>> Use-IT creates free paper maps for youth-hostels targeting a specific
>>> audience. Currently they are using the tool chain:
>>> OpenStreetMap website -> export svg -> import in Illustrator -> lots and
>>> lots of manual labour and finally produce eye candy like this:
>>> http://www.use-it.be/_files/inlineuploads/pages/MAP_O_Brussels.pdf
>>>
>>> Recently, the contact reached out to me. He could not find a solution
>>> within
>>> the OpenStreetMap community or it's related technology partners. Now
>>> I am
>>> helping him out looking at new ways to speed up their labour process.
>>>
>>> I am investigating the qGIS pdf export and it looks promising in
>>> combination
>>> with the OpenStreetMap plugin but texts come out as letter-outlines
>>> instead
>>> of fonts and the PDF layers structure is hard to work with. I would
>>> like to
>>> know if the developers of the layouter/export would be interested in
>>> about 2
>>> weeks of work to enhance the layout manager to something that creates
>>> pdf
>>> that is perfectly fit for post-processing.
>>>
>>> *****************1. PROCESSING PROBLEM*
>>>  This remains almost impossible - only supercomputers are able to
>>>  deliver an svg-file of a city of reasonable size, and even that is
>>>  still only a 50% shot. It took us a full night to render a city, and
>>>  were able to get there only with one of about ten available
>>>  xml-rulesheets (called z12). How could this be tackled?
>>>
>>> This one is tackled with the OSM plugin in combination with the PDF
>>> export.
>>> As far as I can see, the way osm data is presented in qGIS is
>>> simplified,
>>> but this is good! We don't need shading, outlines and a whole lot of
>>> fencies
>>> in this fase. The eye-candy will be created in Illustrator. So, as
>>> far as I
>>> can see; qGIS tackles this issue.
>>>
>>> *****************2. LAYER PROBLEM*
>>>  The svg does not contain separate layers with a clear content (like
>>>  'parks', 'roads', 'rivers'). Only the layers 'Map' and 'Map
>>>  Decoration' appear, but all the information is thrown together in
>>>  the layer 'Map'. You say it's a matter of someone finding the time
>>>  to improve this - but who is the best person to address?
>>>
>>> In the OpenStreetMap data format, there are basically 3 layers: points,
>>> lines and polygons. The "real" layering is organised in attributes
>>> called
>>> tags. To be more generic; It would be good to push elements to a pdf
>>> layer
>>> based upon grouping by attribute. In case of openstreetmap data, it
>>> would
>>> mean applying some rules to strip out the tags into the required
>>> attributes
>>> and then in the layout manager tell the pdf export to "group by
>>> attribute
>>> column A"
>>>
>>>
>>> *****************3. TYPOGRAPHICAL PROBLEM*
>>>  Layouters prefer to work with Adobe Illustrator to make maps. It's
>>>  what they know best, and Inkscape is just not as good yet.
>>>  Osmarender renders svg files. It is possible to open an svg-file in
>>>  Illustrator, but then you get typographical problems, illustrated
>>>  below. Our question: could Osmarender be made to deliver an eps-file
>>>  (always works in Inkscape AND Illustrator) instead of an svg?
>>>
>>>  This is what happened to a small part of Antwerp (Belgium):
>>>
>>>  SVG IN INKSCAPE
>>>   > opens fine
>>>   > text is fully editable
>>>   > see image 'svg_inkscape'
>>>
>>>  SVG IN ILLUSTRATOR
>>>   > opens upside down and with mistakes
>>>   > text is still editable as text (so it's not flattened), but does
>>>  not appear on a horizontal path in the street. Furthermore, every
>>>  letter is on a different path, so it's impossible to select an
>>>  entire word.
>>>   > see images 'svg_illustrator' and 'svg_illustrator_detail'
>>>
>>>  SVG SAVED AS EPS IN INKSCAPE AND THEN OPENED IN ILLUSTRATOR
>>>   > opens fine
>>>   > text is flattened and not editable anymore, and therefore useless
>>>  for layout
>>>   > see images 'eps_illustrator' and 'eps_illustrator_detail'
>>>
>>> **************
>>> Again; as far as I can see, it is qGIS to the rescue! The whole
>>> process of
>>> going from svg through inkscape to Adobe Illustrator is greatly
>>> smartened by
>>> using PDF export instead. Only one thing is needed here: to export
>>> fonts as
>>> text and not as letter contours. Horizontal text would be excelent.
>>> In that
>>> way, the designers can throw away what they do not need and use
>>> Illustrators
>>> smart tools to make text follow lines and so on.
>>>
>>> Now, what I would like to know (my contact has some funds to spend on
>>> this
>>> topic):
>>>
>>> - Who can I address with my enhancement questions?
>>> - Who would be willing to spend about 40 hours on this and at what rate?
>>> - Would this fit the roadmap of qGIS development?
>>> - Would others like to join up and provide extra funding for this?
>>>
>>> I am curious to see what responses will be coming!
>>>
>>> Kind regards,
>>>
>>> Milo van der Linden
>>> +31616598808
>>>     
>>




More information about the Qgis-developer mailing list