Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should move base functionality to a category of NS/UIBezierPath #6

Open
MrNoodle opened this issue Mar 26, 2015 · 5 comments
Open

Should move base functionality to a category of NS/UIBezierPath #6

MrNoodle opened this issue Mar 26, 2015 · 5 comments

Comments

@MrNoodle
Copy link

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
Copy link
Owner

cparnot commented Mar 26, 2015

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
Copy link
Author

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
Copy link
Owner

cparnot commented Mar 26, 2015

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
Copy link

milend commented Mar 27, 2015

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
Copy link
Owner

cparnot commented Apr 4, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants