Allow @3x Scale Factor Output about ansilove

[fcambus]

So far I checked if we can maintain backward compatibility, as in having the -r flag defaulting to 2, and then allowing to pass an integer as well. The problem with that approach is that specifying two colons (to specify that argument is optional) in getopt(3) optstring is not standard and I believe it is not supported on NetBSD and therefore will not be supported on OS X either.

[fcambus]

Could you check if getopt(3) on OS X supports this or not?

[christianvozar]

It looks like option characters followed by two colons :: is a GNU extension.

[christianvozar]

My concern going forward is I'm not sure where the pixel density madness will end. I thought for sure that Retina @2x sized would be adequate for some time but now iPhone X, the Plus Series, and others now use a "Super Retina" with a @3x scale factor. It makes sense for us going forward to use a scale factor so when a "Super Duper Retina" of scale factor @4 comes out it's just a flag to be set.

[fcambus]

Agreed, allowing to specify a custom scale factor is the way to go. I just pushed a retina branch which should allow that.

You can try ansilove -r n input, where n is the scale factor.

So far, n can take a minimum value of 2 and a maximum value of 4, we can adjust it before merging if we decide to go this way.

@ByteProject: any opinion on this issue?

[christianvozar]

That certainly did the trick.

[ByteProject]

Yes. When I added the createRetinaRep bool value to the AnsiLove/C codebase, it was meant to provide compatibility with OS X Retina desktop applications.

I absolutely agree that a custom scale factor is the way to go and I appreciate your efforts to bring ANSi to iOS, even though I see the relevance of a dedicated viewer more on the iPad than on the iPhone.

Regarding the usage of the flags -r n: I‘m fine with that as long as using the -rflag without n would default to @2x (if possible) to not break compatibility with any programs and frameworks relying on this.

I’m wondering if we should limit to max. scale factor 4 or if we should go higher, 10 for instance. That would allow us to not touch this code again for a long time. I first thought that it would be great to not limit the scale factor, but we definitely need to have a limit for preventing misbehavior or bad experience when someone accidentally enters 44444444 instead of 4 for n

If this all is provided, I’d agree that this useful addition should be merged to the main branch.

[christianvozar]

My intention is to create an Ansilove "viewer" (right now it's just codename Ansilove, suggestions for a name for it on the app store are welcome) that is a universal binary for all iOS devices iPad and iPhone. It might be cool to do a tvOS version and allow it to do a demo-mode style for competitions and art exhibits in the future (Apple TV + Ansilove + Television setup). I'm not sure I'll do watchOS since that seems a bit far afield from what someone would view ansi on...

Also, +1 on a reasonable maximum value of 10x scale factor. Hard to imagine anything displaying resolution that big unless we are outputting ansi art for display on a stadium jumbotron 😆

[fcambus]

I think Stefan is right, it's better not to break compatiblity. So I propose to keep the -r flag to generate @2x output, and to introduce a -R flag to allow specifying a custom scale factor, I updated the retina branch to do just that.

Ranges can go from 2 to 8, as setting it to 8 produces images larger than a 4k screen so it should be ok for now I guess.

[fcambus]

If we are happy with this I will merge and tag a new release.

[christianvozar]

Thanks for the work @fcambus. Once you merge and increment the version I will get to work including it in the Mac framework. Thanks to @ByteProject for feedback.

[fcambus]

No worries. I merged the branch and tagged a new version.

Thanks to both of you for the suggestions and feedback.