CInk version 2 finally released!

Finally CInk version 2 has been released.

Some key new things

  • New website with complete API documentation and guides on how you can use CInk JS code.
  • Finally released the full source code of CInk renderer and compiler. License – GPL v3.
  • CInk finally supports all the features of original CFDG, including Paths.
  • CInk has introduced support for texts which extends the capabilities of CFDG considerably. Check out the cool demo – Neon Letters. To learn more about it see – “Text transforms” section here.

Last but not the least, you can post comments on CInk website. The comments section is at the bottom of each page.

Goto Cink website – cink.applegrew.com.

CInkv2 release postponed

Last weekend I was about to release CInk v2, but at the last moment I found a big bug in the way paths are implemented. Now the situation is quite tricky to solve. On top of that, now-a-days I find myself with very little free time. Anyway I will continue to work on it. My estimate is that now CInk v2 release is postponed by a month.

What’s keeping me busy

Of course it is CInk. 😛 Ever since I started working on it, my world has now, kind-of wrapped around it. Oh, I am really fatigued now. Phew!

But anyway, why this post? I surely haven’t posted this to rant about myself. It is of course CInk and it is turning out to be quite something. I have been working on it to fill the features gaps between this and ContextFree. The only gaping hole left was that CInk version 0.1 didn’t support ‘paths’ at all. Well this weekend I have implemented that, well almost. Now CInk supports all path operations expect for ARCTO and ARCREL. I plan to implement them next weekend.

Along with Path support, I have improved the z-index handling. In version 0.1 of CInk, you might have noticed that for codes with z-index, the background color is applied at the end of the rendering process. Also if there are any event rules preset, like MOUSEMOVE and MOUSECLICK, then CInk would defer event handling until the main rendering completes. In fact for evented rules z-index was not even supported. I have fixed them now. Now it doesn’t matter if z-index is present or not, it would behave the same, although it could be injurious to yours browser’s health. In particular Firefox seems to struggle in this case.

I am now moving CInk to version 2.0. Why v2.0 and not v1.0? Glad you asked! I have thrown in a totally new capability in CInk which ContextFree or Algorithm Ink doesn’t have. Using texts.

CInk texts support

For texts the following commands have been introduced.

  • fn – Sets font name to use
  • fs – Sets font size. This is additive. So when multiple fs commands are encountered then their values will be added up as we progress. This allows us to create something where the texts will grow larger or smaller.
  • fu – Sets the font unit. This allows us to set the unit to be used with fs. This can be ‘px’, ’em or ‘pt’.
  • base – Sets text baseline. Won’t elaborate this right now but can be found out by Google.
  • align – Again won’t elaborate right now.
  • t – Aah! The prized command. This is the one which allows you to set the text that needs to be shown. This too is additive, so if you specify in a sequence – t A t B t C, then the net output will be the string ABC.
  • bkspc – This does the job of removing the last character, if there is any. So, if we modify the above  example to – t A t B t C bkspc, then the final text will be AB only.
  • e – This is like bkspc but instead of remove the last character it empties out the full text. So, whenever this is used the the final output will always be and empty string.
  • |t – This one is a genius! 🙂 I can’t help myself from putting so many exclamations and smileys. There goes one more. 🙂 This command should be followed by an integer. This value is then added to the last character’s unicode (decimal) value. So when the current string is ABC then a |t 1 will finally generate the string ABCD. This is because on adding 1 to unicode (in this case the ASCII) value of C, we get D. This D then gets clubbed together with the last string. Now this little buddy has one more trick up its sleeve. What do you expect will be the output of this – t ABC e |t 1 ? Well, it won’t be and empty string. It will be D! This because e and bkspc are, what I call, past-influential commands, because they are not supposed to influence the output of the future commands. In this example C‘s ASCII code is passed-on to |t even when it itself perishes. If C had not done that then |t would have been influence by past commands, making it hard to predict the output. So, now even if there is a e or bkspc on the left of |t then this doesn’t influence it.

There are few more goodies which I will throw-in here. You can use unicode characters for t. For characters outside the normal ASCII range you cannot directly write it as a parameter for t, but instead you need to give that character’s (decimal) unicode value in a special format – {uxxx}. Replace xxx with the unicode number. It can have any number of digits.

Now you might be wondering, at what point all these texts are actually printed and how do we control that? Well the answer is ECHO. ECHO is a shape primitive like CIRCLE, TRIANGLE, SQUARE and LINE (this will come in v2.0). So it behaves exactly like them, that is, when invoked do what is meant to do, in this case print text, using the transformation commands it is interested in. ECHO, like others, honours geometric and colour transformation commands, like hue, scale, flip, etc.

So, it’s time for an example.

//Delhi Belly by AppleGrew

startshape stacks
size {s 0.2 z -400 x -.5}

rule stacks {
   delhi {b 1 h 0}
   belly { y -1 b 1 h 200}
}

rule delhi {
   //Unicode for two Hindi characters.
   //{u2367} is called a "matra", which in
   //itself is not a letter but modifies the
   //sound of the other.
   stack {t "{u2338}{u2367}"}
   stack {t L x 1.5}
   stack {t H x 2.5}
   stack {t I x 3.5}
}

rule belly {
   stack {t B}
   stack {t E x 1}
   stack {t L x 2}
   stack {t L x 3}
   stack {t Y x 4}
}

rule stack {
   10* { z 1 x .05 r 1 h 10}
   ECHO {sat 1 r 1}
}

rule stack {
   10* { z 1 x .05 r -1 h 10}
   ECHO {sat 1 r -1}
}

rule stack {
   10* { z 1 x .01 r 1 h 10}
   ECHO {sat 1 r 1}
}

rule stack {
   10* { z 1 x .01 r -1 h 10}
   ECHO {sat 1 r -1}
}
Output

Note: You need to have Firefox 4+ or Chrome to see the output below. It is not tested on any other browser.

CInk version 0.1 preview

[AG_PH_ON]

For past few weeks I have been on working on this. This has come out to be quite good. The above video shows rendering being done on latest Google Chrome browser. I have tested my code in Chrome and FireFox 5, and it works with reasonable performance.

About CInk

Sometime back I stumbled upon Aza Raskin’s very inspiring and beautiful Algorithm Ink[sup] 1[/sup]. It’s easy to use and you can create some truly amazing art. From there I learnt that it is a Javascript implementation of Context Free Design Grammar (CFDG), invented by Chris Coyne[sup]2[/sup]. Also, that CFDG contains more language constructs which Algorithm Ink didn’t support, like loops, z-index, etc. Instead it provided a link to C implementation of CFDG – Context Free Art[sup]3[/sup]. When I saw what still more amazing stuffs people have done there, particularly a B/W artwork, “Bleak” [sup]4[/sup], then I decided of re-implementing CFDG in Javascript.

Why Javascript

CInk is not a replacement for its C counterpart – Context Free, but it adds to it. First this allows a way for random nettizens to stumble on it and create something amazing, even if by chance. Second, CInk clearly separates parsing and rendering logics, making it possible to be used to draw your site’s background. Yeah I find that cool. 😉 Third, as a side-effect of the trick Aza used to keep the browser from locking up as the script draws the art, makes for a visual treat. Which the C counterpart cannot, as it is too efficient and fast to render. 😛

Algorithm Ink

CInk can be considered an enhancement of Algorithm Ink, as the rendering logic’s fundamental concepts are from it.  Except for that it is purely a new product. The parser has been created using JSCC[sup]5[/sup] with slightly modified grammar than given in Context Free’s source code.  Output rendered by CInk is now very much like its Context Free. CInk retains support for MOUSEMOVE and MOUSECLICK predefined rules, introduced by Aza. One major difference between CInk and Algorithm Ink is that, unlike Context Free, Algorithm Ink used HSL to RGB color conversion, but CInk uses HSV to RGB conversion. Also CInk code has been made modular and it doesn’t litter the global namespace.

Overall CInk is compatible to Algorithm Ink and Context Free. So, codes for Algorithm Ink will run in CInk and codes for Context Free may need to be scaled down. You can use size {} command for that.

Future

This is just a preview. I haven’t released CInk yet. It will be online when I have created its site. It will be GPL licensed. Currently path commands like LINETO, etc. are not supported, but will be in little future. Though tile{} command is supported but the output will be less than appealing. I am not sure if it is possible to fix this now. For now tile{} will remain broken. Since <canvas> doesn’t support z-indexes, so CInk creates stack of them when rendering a code that refers to z indices. At the end of the rendering all these stacks are merged into the one. This is of course a hack, but can’t help it unless HTML5 specification and browser developers do something about it.

  1. http://azarask.in/projects/algorithm-ink (Algorithm Ink)
  2. http://korsh.com/cfdg/ (CFDG inventor)
  3. http://www.contextfreeart.org/mediawiki/index.php/Context_Free_Art:About (Context Free Art)
  4. http://www.contextfreeart.org/gallery/view.php?id=2550 (Bleak Artwork)
  5. http://jscc.jmksf.com/ (JS Compiler Compiler)