Should move base functionality to a category of NS/UIBezierPath

[MrNoodle]

I think it makes more sense to have the parsing code in a NSBezierPath category. You can keep the API on NS/UIImage as a wrapper around this but it allows this to be used in other drawing contexts.

[cparnot]

Cheers!

I think we can add those, and keep the NSImage convenience method. In my own use of ASCIImage, I found that I like 'seeing' not just the shapes, but the pixels and not have to worry about drawing.

Note that on OS X, the NSImage you get can be rendered in any context, and it will behave just like the underlying NSBezierPath instances, since the drawing only happens when the block is called. This was a surprising finding for me when seeing NSImageView rendering all these shapes nicely smoothed even after we set the scaling to Up/Down in the xib.

So anyway, thumbs up!

I think it would make sense to rename the current files to 'ASCIImage.h' and 'ASCIImage.m' since we are stuck with this name, and then include both the NS/UIImage categories and NS/UIBezierPath categories in the same files? What do you think?

[MrNoodle]

Sure, the actual string you send in doesn't change. It's just that it is really defining a path so it makes more sense for the functionality to be based in NS/UIBezierPath.

As for NSImage drawing behavior, check out my blog post on it here: http://www.noodlesoft.com/blog/2011/04/15/the-proper-care-and-feeding-of-nsimage/

I'd prefer separate files but am fine with sticking it all under ASCIIImage.

[cparnot]

Very nice post, I remember reading it a while ago actually!

Yes, I was surprised by the NSImageView rendering because I had not thought through the implication of my drawing code being outside a context in the implementation (block API), and my whole focus had been to rendered icons at a specific size. Once I saw that, it took me a bit of time to understand all the implications.

I am not sure it behaves the same on iOS, because the rendering of the bezier paths is done directly in an image context, and UIImage appears to be a different beast. So interestingly, the UIBezierPath category might be even more useful on iOS than OS X in providing the full underlying vector art.

[milend]

On a related note, it would be good to expose and extract all the parsing code (namely -shapesFromNumbersInStrictASCIIRepresentation:) so that other apps can consume ASCIImage strings. Ideally, I'd want to have a separate PARParser that contains the following methods:

-strictASCIIRepresentationFromLenientASCIIRepresentation:
-orderedMarksForASCIIShape:
-markCharactersForASCIIShape:
-nonWhitespaceCharacters
-shapesFromNumbersInStrictASCIIRepresentation:
-numberedASCIIRepresentationFromASCIIRepresentation:

@cparnot If that's of interest, I can supply a patch.

[cparnot]

@milen-me I'll make that a separate issue, so I can go piecemeal on this.