Import and export is, of course, a huge workflow factor for anyone, especially anyone from a graphic design background. Some of my students at MassArt have been kicking the tires on Processing’s SVG and PDF libraries and running into hitches. There’s nothing more frustrating than getting an obscure error message when you think you’re doing things right. Happily, we’ve got some solutions.

Of course, it’d be great to hear from others with similar issues.

The following libraries might also be of use:
http://www.texone.org/prosvg/
http://processing.unlekker.net/SimplePostscript/index.html

PDF

Several students had problems with font embedding using the built-in library. Symptoms: strange, blocky letters. The issues seem to occur on Mac OS X (all the students in this case I believe were on Mac exclusively.) The reference documentation for the PDF library offers this clue:

Starting in release 0120, text is no longer treated as shape data by default, meaning that the font will need to be installed to view the PDF that’s created. The upside is that the PDF will render better (particularly in light of the Mac OS X bug noted here). To force text to be treated as shape data, use textMode(SHAPE), immediately after size(). See the developer reference for textMode() inside PGraphicsPDF for more specifics.

But so far, forcing SHAPE hasn’t been very helpful.

Colin Owens has this tip instead:

Placing:
[sourcecode language='java']hint(ENABLE_NATIVE_FONTS);[/sourcecode]

before text();

does the trick.

This needs to happen before all your other font/text code. (I believe setup() is optional.)

I also suggested, for those on the Mac, at least, that people get fonts working on Mac and try re-saving in Preview.app for cross-platform / cross-machine compatibility as needed. (The same would be true with Acrobat or any PDF builder on any platform, just in case the library is misbehaving.)

Oddly, people are still having issues in which the first couple of characters are garbled, so they’ve taken to hiding the first two characters used. Bizarre.

SVG

Mahesh Gudapakkam was having some problems with the SVG graphics format, even following examples from Ben Fry. Nicely enough, he solved it himself.

Basically, the issue was tag information being handled in a way other than he intended, thus triggering an array out of bounds error.

First, the symptoms:

running into a problem here .. i am trying to work with a SVG version of the US map.

i have a version that works well – zooms in and out and scales the way i want to – unfortunately i had no way to control characteristics of individual states (only later did i realize that SVG’s can have markers for individual states stored as attributes to its tags and my svg image didnt have any – i downloaded a free one of the web)

i realized the above while reading through ben fry’s [book Visualizing Data]. in an example of his, he points to an SVG on wikimedia (http://commons.wikimedia.org/wiki/Image:Blank_US_Map.svg)

for some reason when i work with this file i get an exception
java.lang.ArrayIndexOutOfBoundsException: 1

all i am doing at this point is declaring a SVG object and reading this downloaded object into it .. and then trying to display it – any ideas?.. processing version is 0135Beta

The problem? Poorly-formed tags:

quick update. i was able to figure out what was causing the array out of bounds error. comparing the working svg vs the one not working and picking up on some threads from some of the early postings rgd’ing issues with candy’s parsing on the processing forums – i found that the graphic tag had some extra attributes. here’s how it appears in the non-working ones.

[sourcecode language='xml']
OR
id=”g4″
style=”fill:#d3d3d3″
transform=”translate(-4,4)”>[/sourcecode]

the candy svg library seems to not like this – once i reduced it down to it happily worked. also a few other things i had to change -
1. it does not work with the tag either – needed to get rid of it
2. some other tags it failed to work with are ones that had these attributes
[sourcecode language='xml']# sodipodi:type=”arc”
# sodipodi:nodetypes=”cc”[/sourcecode]
processing complained that it does not recognize the shape command – once i got rid of these attributes it didnt complain of those errors ..

once i addressed all of these i was able to get the svg to work with candy.

this might be something of interest to others in the group who might end up working with SVG’s .. these tags get produced even when you use a program like illustrator to create a svg (i went that route too and it produced errors as well). hopefully it will save them some time.

If you run into other errors like this, let us know!