See changes.

[ap4y]

Nice change! Thank you very much for the contribution. Shame on me for such mistakes. May I ask you to exclude dc82c7a commit? Because it seems like it's unrelated to this pull request. Thank you for the the contribution.

[alvonellos]

No problem!

[alvonellos]

I'm embarrassed to ask this, but how do I exclude this pull request?

[ap4y]

Its pretty easy. Actually there is several ways to do that: you can revert commit, you can reset repo to previous commit or you can create new pull request and you will get button "Change commits" (more here https://help.github.com/articles/using-pull-requests/ in the section "Changing The Commit Range and Destination Repository")

[alvonellos]

I think that did it. I'm new to GitHub, so I just did it via command line with git rebase -i HEAD~2, deleted the second line, and then did a git push origin +master. I think that did it.

[ap4y]

Merged. Thank you again for the help!

[alvonellos]

No problem! Wish I can help more! I'm looking into doing the same exact thing you're trying to do here, but I think the problem is best approached by writing a compiler... at least, it's looking like that to me. I get this feeling that the more I beat around the bush and avoid writing a compiler, the angrier I am going to be when I end up writing a compiler.

Do you know anything about writing compilers?

[ap4y]

Hi! I don't think that I get you idea clearly. Maybe it is possible to describe it more precisely? About compilers: I don't think that this word is suitable to the parsing process of svg strings, and the whole process of building UIBezierPath from svg commands is closer to interpreters rather than compilers.

[alvonellos]

Sorry for the late reply. The end goal that I'm looking for is a fully SVG-specification compliant bridge between Objective-C and SVG, where the translation between the two is not done on the tiny processor that is on the User's iPhone or iPad or iDevice, but rather on the Developer's machine itself -- once. What I said compiler, I literally meant a compiler.

[alvonellos]

The problem is that every other solution to this problem is beating around the bush. The task is to take one language and generate another, and most of them (your stuff is the only bit that I've had work well) are taking the input files and interpreting them along the way.

[alvonellos]

Imagine the following scenario: you feed a SVG file into a program, and you get .m and .h files for the output, including another file for unit-testing individual objects. The compiler recognizes groups, colors, properties, and so on and then generates the appropriate methods and interfaces for operating on that object. The programmer can then go into the code and add a level of dyanamicism and such to the code post-compilation that is not ordinarily possible. See where I'm going with this?

[ap4y]

Ok, now I get it. As I said earlier your goal can be expressed as writing interpreter (translation between high-level languages) rather than compiler (translation from high-level to low-level). There is a bunch of successful open-source interpreters realisations in github (coffeescript for example) using parsers (jison for the coffeescript). You can go that way too, so you'll get a lot of examples. But, when I think about applications of such product, the only thing I can imaging is vector editors. Other problems can be solved in more elegant/lightweight way, since UIBezierPath can be reused. For example, you can parse in your app svg image to the UIBezierPath singleton instance and use it in different UIView instances without parsing cost (actually I have successfully used that way in production code with UITableViewCell). So, I can't see advantages of interpreter upon reusable path. Unit-testing UIBezierPath is a different story, it's pretty hard to test complex path object, since you can't traverse UIBezierPath object (as long as I know), the only way I can imaging is hit detection.

[alvonellos]

You're perfectly correct, I didn't explain myself correctly before, but luckily you were able to get exactly what I mean -- I didn't mean a compiler in terms of a SVG->binary/machine code but rather a parser generator, like jison. I may have to fall on my sword here, maybe you're right and it's a better idea to interpret SVG on the fly rather than "interpret" it to Objective-C code.

[alvonellos]

But what about complex things like gradients and such, it would be really great to be able to feed in a SVG file exported from illustrator, and be able to use the graphics in that to create sprites and such for games. A fully SVG compliant specification for creating Objective-C code that developers can work with without being irritated too much by the Graphic Designers :-)

[ap4y]

I'm actually made some performance tests and got such results: parsing octocat icon(145 svg string commands) takes 119ms(50ms for regex) and I'm pretty sure that this process can be optimised a bit. The whole UIBezierPath object with underlying CGPath objects costs about 100kb of memory(this is really decent amount). So, all I can say is that I'm rather disappointed in performance :) Thats why, if you need to build pretty intense asset system for something like game engine, pre-parsing is better solution for now. But, I will play a bit with regex parser and will try to optimise current algorithm, so if it will be posible to lower the parsing time to something like 10ms, I think that runtime parsing would be possible. About parsing whole svg files: as I said it's possible, but will cost decent amount of time (for example obj-c uses gradients as mask, color should be stored somewhere etc.). Have you seen https://github.com/SVGKit/SVGKit? It seems like a mature project with similar goals but different approach.