The whole playing card thing got me onto this - Support for displaying html (fun) and SVG (funner) is built into the iphone. It would be nice to be able to take a blob of either and have pass it to be rendered - return the result in an image() for compositing to the screen. Would add some neat capabilities, and deal with the whole “fonts” thing at the same time.
I went ahead and posted each of these, plus card spritepack, as enhancement suggestions on the issue tracker. I wouldn’t ask for SVG (or html), but they’re apparently built into the UIWebView component - so if that can render to an image it shouldn’t be heinously hard to add, and would be insanely flexible.
Interesting idea, and like you say, not hard to implement.
My thought is that we would do something like the following
myImage = webContent("http://somewebsite.com/data.svg", 400, 400)
The main issue I have with this is
- It’s a blocking call
- Data may not exist
- Code doesn’t function correctly if the user is offline
If you call webContent() in the draw() loop you will stall your rendering by quite a long time.
Another possible issue is speed. How fast will it render a quite complex structure? The domino card class is getting sluggish when it involves user interactivity with many cards on the screen.
But combining this proposed online SVG/HTML grabber with custom sprite, we’ll get sprite builder with content from online resources. I personally won’t use them directly in a program, due the technical limitations (speed, blocking, online). Instead, I will use it as some kind of a tool, something like online resource grabber.
Another idea is to create a proper vector font renderer. Unicode fonts have many good and interesting shapes, including card symbols (symbols font). I also need to draw non-ASCII fonts, mainly arabic.
+1 for this. Lots of UI opportunities would arise. But pretty soon you wouldn’t want to stop with static HTML. JavaScript?
I’d rather separate the context - be able to
svg = wget("http://www.someplace.com/bortels/starmap.svg")
rendersvg(svgimage, svg)
Simply because I can think of 20,000 uses for wget.
As for blocking - It can be dealt with, if need be, by drawing a “loading…” screen (a few times to deal with buffering), then making the calls, then going on when you’re done. Alternatively, make the result a callback.
wget("http://wubba", function { svg=result.content })
Your draw would then have “if (svg) then” around the lot, maybe with an ‘else’ for loading screen. The “result” object would have content for the content, status for the return code, and/or maybe “error” for the error text (if any). Ooh, and “headers” would let us do cookie handling and other stuff. (This assume you don’t just go full-on and do sockets, which I’d frankly prefer - I’ve been dabbling with websockets… and redis…)
Done right, I would suspect this would be a one-time thing - usually, my preference if the data isn’t huge and is static would be to fetch it, then store it in local storage.
The idea behind drawing to an image() is that gives us control after-the-fact about scaling and size - to say map it onto a 3D-cube or such.
I support wget() as a separate tool but for images…
Myimage = image (1,1) – or some kind of default, non-blocking
Myimage:wget(“http…”,400,400) – 400, 400 optional, defaults to image size, non-blocking
also wget pushes to a queue, so if you call a million of them it’s only going to load one at a time
Myimage:ready() – returns true if image is loaded (also true if wget was never called)
I would say string:wget is needed but really for what people want to use it for it would be blob:wget and the blob object would have it’s own functions.
Or maybe string is fine. The word blob is in an SQL sense, binary large object.
Really, what image() needs is image.data
So I could go “a = image.data” and save a off to storage or such, and later do
i = image(64, 64)
i.data = wget("http://home.bortels.us/tomfezicon.image")
(We need 8-bit clean persistent storage, sigh)
We wrote at the same time 
So a blob?
Mmmm. thinking about it, we need:
i = image(64, 64)
i.data = convert(wget("http://a.b.c/image.jpg"))
with support for the common formats - jpeg, png, gif.
Mind you, if I had “renderhtml” and sockets, I could roll my own!
Not sure if this will help TwoLives but http://code.google.com/p/lua-blob/
On a different forum about lua SQL they where putting blobs in string or converting them to number (I guess if there small). Not sure how effective blob is a string can be.
Perhaps it will be best if we just add sockets first and then examine what is necessary in higher-level APIs.
+10 for Simeon. Add sockets. I will wrap them, by which I mean I will port the library from someone who has already wrapped them
If you’ve seen my moose - you know I don’t do graphics well. Sockets, I do. Heck, that’s my job (at a somewhat higher level). Wait until we can harness the power of the internet, or even simply peer-to-peer for multiplayer games! (dang - I need another ipad…)
+10 for sockets. If you expose a media player object I will have some meat streaming video apps for you in a heartbeat! I want circular video and audio buffers too, naturally.
Going back to the original subject, I’d like SVG support. SVG is quite a common option for exporting from (and importing to) many graphics programs so it would make it easier to design something in TeX, say, and then import it to Codea. Or to use Codea to design drawings in TeX.
I’ll put in my vote for sockets first.
Thanks!