Postscript Language Patch

Here's a random idea that just occurred to me: how about a Postscript language patch for 2D vector rendering?

Maybe with added support for reading-in Illustrator or SVG files and maybe even 'doing stuff' to the vectors before rendering them (I'm thinking Vector Filters of some sort).

Just a random thought...

a|x

pixelnoizz's picture
Re: Postscript Language Patch

i like your random ideas!

cwright's picture
Re: Postscript Language Patch

.AI files can be rendered at arbitray resolutions (I think? maybe not?) Like PDF.

There is built-in support for SVG files -- it's called XML ;)

PS is a bit more involved, but might be possible.

Extending this further, I've been wanting to make a "vector tools" patch set to allow various vector-based things (including vectors from strings of text in specified fonts, etc.). I have no idea what should be included/how it should work/how the interface should be exposed... if you have any thoughts on that, I'm all ears :)

toneburst's picture
Re: Postscript Language Patch

Good to see we've been thinking along similar lines.... :)

I'd love to see a set of vector tools. I'd envisage a similar setup to Kineme3D- a file import patch, some tools, and a renderer. There might also be a patch that accepted a structure of points (corner points and handle points- I'm vague on the terminology) and either rendered vectors directly, or passed the necessary data along to the Vector Renderer patch.

A string-in-font vector importer would also be very cool, especially if it could be configured to output a structure of points that could also be passed on to a Line or Point Structure patch, as well as to a Vector Renderer (this would nicely kill two birds with one stone). Maybe there would be a special patch to handle this, as it might be useful to be able to subdivide each segment in various ways, rather than just passing out the raw positions of each corner-point.

Re. the PS patch- I guess it would be roughly based on the model of the other Programming patches, but maybe would have to be connected to a Vector Renderer to produce output.... Not sure about that one, to be honest. I think a general set of Vector Tools would probably have more mass-appeal. Having said that, I was flipping through my John Maeda book the other day, and there are some quite cool things you can do with PostScript...

aLx

.lov.'s picture
Re: Postscript Language Patch

cwright wrote:
.AI files can be rendered at arbitray resolutions (I think? maybe not?) Like PDF.

There is built-in support for SVG files -- it's called XML ;)

PS is a bit more involved, but might be possible.

Extending this further, I've been wanting to make a "vector tools" patch set to allow various vector-based things (including vectors from strings of text in specified fonts, etc.). I have no idea what should be included/how it should work/how the interface should be exposed... if you have any thoughts on that, I'm all ears :)

A Vector Tools patch would be awesome! I've not a lots of idea what features needed, but, for AI files, accessing the individual shapes with information (size, color, etc.) like the layers in my PS layers plugin would be awesome :)

I just found this framework, never used, maybe its helpfull: http://www.apptree.net/drawkit.htm

toneburst's picture
Re: Postscript Language Patch

Wow, that DOES look interesting. What do you think, cwright?

a|x

toneburst's picture
Re: Postscript Language Patch

How about a patch that takes the the vector control-points and can apply 3D rotation to those points, so that the 2D vectors appear to be in a 3D space?

a|x

usefuldesign.au's picture
Re: Postscript Language Patch

I'm glad you're talking about a vector patch for QC. I've mused about this before and not really got much traction. As Adobe the other day launched a swipe at Apple for not supporting Flash on the iPhone there was a barrage of users slamming flash as old, slow and CPU hungry. It made me think again what could be a replacement. (Although anything QC dependant is not really an "Open Standards" replacement because it requires MacOS on host machine).

Also makes me wonder what Apple will put on any unannounced new hardware it may discussing with the publishing industry to replace print text books using text along with animated diagrams etc (Video is so needlessly MB expensive for diagram kind of animation) in colour ebooks of the future (ie leapfrog kindle). Can SVG do animation well and how does one author it?

Processing and a JS processing implementation I looked at the other day can run pretty fast even in browsers. I would really like to be able to do simple & clean drawing in QC but feel limited at present with Line-Structure Patch. I haven't thought about new possible implementations to much but it seems like a BIG niche to fill, esp if drawing shapes in 4D space becomes possible as a result. Will give some thought.

Would it be possible to leverage (to use an ambiguous non-specific weasel word!) the Quartz2D framework inside a Quartz Composer vector patch at all? Just asking as it seems to have lots of shape related stuff already done and dusted. Anything that can aid/simplify the maths required to do drawing would be cool eg. like 3 co-ordinate polar notation (spherical geometry). I think fast line drawing from shape structures and collections using GL vertexes and nice smooth splines with beiziers handles or other would be really great too.

I use Kineme Line Structure heaps and while it's probably pretty fast the JS I must drive it with is not fast (if you compare to number of lines the a Line Family patches can generate for same FPS ratio).

If some custom patches that can build line/shape structures very quickly from shifting (say randomised or iterated) variable inputs to (editable) line/shape equations inside the patch that would be one good approach towards useful vector patches. I could eleborate if Kineme is interested in hearing more on that. Perhaps these patches could persuade the GPU to handle the calculations (OpenCL?) although I think cwright has said even a CPU can do these kinds of things ridiculously fast, it's just the interpreted Javascript patch that has so much overhead cost per frame.

Anyway I'm all ears on this potential set of patches!