On Wed, 8 May 2002, Michael A Nachbaur wrote: With regard to dynamic image creation
> The most basic uses of this application will to dynamically generate TTF > text for titles, buttons, sidebars, etc. The current version of this > code does this, and quite well. Foreground and background colors, font > name (with bold/italic support), font size, image size (or automatically > detected based on the size of the text), and rotation. I've been working on something like this using GD. Mainly I've been thinking about the interface which (as always) seems to the hardest thing to do properly. It's not an Apache module (though it is designed with mod_perl in mind.) Some form of wrapping module would have to go around it. Hmm. How about I upload the POD so you can see what I mean. htpp://2shortplanks.com/temp/gdti/ Note that this is a work in progress. This code doesn't work yet (though previous hacky versions did.) Yours sounds much more advanced. > The basic text support could be extended to allow for images to be > overlayed on the text (or placed under the text), or stretch images > similarly to how Enlightenment displays window manager themes. Hmm, yes. I have it so the image can be aligned in various ways. It's not quite up to stretching it yet, but we shall see. > Other uses planned would be to manipulate existing images. For instance, > if an image on a website needs a thumbnail, medium size and full-size > view, normally a person must make all versions by hand. If any > formatting needs to be done, like borders or drop-shadows, this > increases complexity. If a person could just drop an image in a > directory, and link to that image, the image could automatically be > resized, borders added, drop shadows put in place. The resulting image > would then be cached, and outputted. Hmm, getting a little complicated here. My program outputs a GD::Image object when done. The idea is that you can then use GD to implement any of the things you're missing. Also, the stages where it draws the background, the border, the text, and so on are all different methods. This allows you to override these methods with your own ones in subclasses, so you can intercept the image creation at various stages and step in to do things first (e.g. draw to the background before the bg image is drawn) > *) URI Arguments > > Information about what is to be done is passed through the URI. This > works for simple tasks like text display, but if anything more > complicated is to be done, external configuration files must be used. > We'll get to that in a bit. I was working on several different encoding schemes that you could use on the URL. Primarily these were: * Base64 alike encoding * A scheme where " " was replaced with "_" and entities could be used Primely I'm only concerned about the text that you want rendered. Everything else was going to be read from a config file/set in the httpd.conf. I was also planning to implement Template Toolkit plugins to allow you to easily create these images. > Essentially, arguments are passed using the PATH_INFO HTTP header. We > want the browser to think this is an actual file, instead of a > dynamically generated image, so that the browser is more inclined to > cache the content. So, a typical query would be: > > http://localhost/genText/font=ArialBold;size=24;fgcolor=#ffffff; > bgcolor=#000000;rotate=90;text=This+Is+The+Text This is indeed a key concept. More importantly I designed my schemes so that they could actually be saved to disk with that filename. One possible idea would be to place the image creation in an ErrorHandler which returns the image and writes it to the correct location on disk. Thus the next time the image is called the perl code is skipped all together and the image is simply sucked off of the disk. I think Randal did a column on something like this a while back. > *) Configuration Files I was thinking of using a system accessible in the httpd.conf for the apache module. > The real important part here, is the "name" attribute of any > element, as this identifies where input can be indicated. In my scheme each location was a different font. So: http://twoshortplanks.com/f/xmason/1st.jpg Is the image "1st" in the "xmason" style. (yes, that link works) An important aspect is that styles in my system can be created from other styles using the ->clone() method. So for example, to create heading2 you could use: my $heading2 = $heading1->clone(text_size => ($heading1->text_size() * 0.8)); All the other attributes would stay the same (colour, background image etc, etc.) The configuration file should reflect that. > *) Caching Schemes I hadn't really considered caching systems. Sounds good. > Note: To prevent the filesystem from filling up, due to DoS attacks, it > may be prudent to have a cron job periodically cull files that have the > oldest access time. Or have the handler do it itself after it's returned an image. You'd also want the handler to keep a scoreboard of how many images have been generated in the last x minutes to stop generating for things like runaway spiders (though OTOH, this could probably be better handled by another module somewhere else in the chain) > My current code uses GD for text writing As does mine. TBH, the hardest thing I had was designing the interface and doing the maths to work out where everything goes when you've got several competing criteria manipulating the image. The underlying image system wasn't that important. I'd considered renaming GD::TextImage to TextImage::GD should TextImage::ImageMagick etc should happen. > *) File Expiration Headers and Browser Caching Not even considered. > *) Current and Future Uses > I have recently released version 1.0 of an all-XML content management > system (although it is not yet available for public use...sorry), and > this means people can edit their entire site, not just plain text. They > can completely change their sitemap structure interactively, and all > site images relating to the sitemap automagically change. I was planning to do something similar with Template Toolkit and the XML::XPath plugin. > Looking forward, I would like to be able to use this for more than just > text. I'd like my customers to be able to select an image, set the > maximum size, check a few boxes or radio buttons to say what formatting > options they'd like, and the image is automagically resized without > wasting disk space or taking a long time to download. Disk space cheap, CPU cycles expensive. > I'm sure there are plenty of other uses for this, but I'll leave it at > this. I'm warey of creating a all too powerful module. It's taken me an age to come up with an interface that I think (IMHO) that has a sensible user interface. I wouldn't want to create something too powerful. I've left hooks in my code. That's all I can do. > I have to make some subtle feature additions to this code within the > next few weeks (months?), and instead of just performing a knee-jerk > reaction and hacking on some cruft to my existing module, I wanted to > open this up to the mod_perl developer community as a whole, to see if > this is something others can use. It sounds good to me. Later. Mark. -- s'' Mark Fowler London.pm Bath.pm http://www.twoshortplanks.com/ [EMAIL PROTECTED] ';use Term'Cap;$t=Tgetent Term'Cap{};print$t->Tputs(cl);for$w(split/ +/ ){for(0..30){$|=print$t->Tgoto(cm,$_,$y)." $w";select$k,$k,$k,.03}$y+=2}
