I've done something like this using Image::Magick, which lends itself better to server-side CGIs, but I recommend you learn (much) about CSS, where you can set the width of elements in em, which is some character length depending on the font size.

If you still think you really need to know the "pixel size" of the rendered HTML, I suggest that you convert your text into images of differing width and calculate from there.

perl -MHTTP::Daemon -MHTTP::Response -MLWP::Simple -e ' ;    # The  
$d = new HTTP::Daemon and fork and getprint $d->url and exit;#spider
($c = $d->accept())->get_request(); $c->send_response( new   #in the
HTTP::Response(200,$_,$_,qq(Just another Perl hacker\n))); ' #  web
[download]

Thanks Corion, see my UPDATE to the original post. This is for a pdf document creation and not html. Sorry for the oversight.

It very much depends on where, when and how (and why?) you are trying to determine this information.

For example. If you are trying to do this within a windows application, that will be writing to the local screen using a pre-selected font, there are a whole raft of entrypoints for dealing with fonts, querying the metrics, and determining the bounds. Which calls you would need to use is very much dependant upon upon what you are trying to achieve.

Other graphical APIs, Tk, Gtk, X etc. will all (probably) have equivalent sets of APIs for doing this.

However, if you are working on a CGI/HTML application and are hoping to work out how many pixels of screen real estate any given string will occupy, forget it it and give up now:)

Whatever you do at the server end to try and determine this is doomed to fail. Even if you specify the exact font and size, each browser may choose to render that font and size with more or less inter-character and inter-word spacing, larger or smaller margins and use (or not) kerning, all of which will completely derail your server-side calculations.

If the fontsize you specify is not available, then the browser may choose to synthesize it from a size that is available, but it is unlikely (if not impossible) that it will reach a similar set of metrics to those you have used in your calculations.

If the font you specify is not available, it will substitute a "similar font", and again you are screwed.

Finally, most if not all browsers allow the user to override the fonts specified by the author and substitute larger, smaller or completely different fonts. I use this facility all the time, opting for small fonts that pack as much text onto my screen as possible. Partially sighted people will tend to opt for larger fonts.

If this is your target, then not only is it impossible to do, you should probably be asking yourself why you want to do it.

If you're starting out with PostScript fonts, a good idea when attempting to generate PDF; and you have the associated .afm files (more like a rarity these days), then one option is to use the old module Font::AFM, and its method stringwidth(), to calculate the physical width of a piece of text, in the font size you like.

Another option, at least when you're using one of the standard PDF fonts, is to use the PDF::API2::CoreFont module. As the docs say:

$wd = $font->width($text) Returns the width of $text as if it were at size 1.

UPDATE:Sorry Monks, I didn't explain why I needed this. I am creating pdf's and I need to calculate space for a certain part of a pdf document I am creating. So, the calculation by pixels will tell me how far I can go with the text, where the left position can start, and if I have to split the line into smaller parts. Thanks again.

Your update is a little confusing. Are you creating a vector or a raster document? PDFs are vector-based and do not use pixels. If you are creating a raster graphic to be embedded in a PDF, that's something different.

Simply answering your question, determining the length of text is a basic function of any text rasterization package. For example, GD returns the bounds of a string rendered with stringFT. More conveniently, you can use GD::Text to get the information a little more easily. Similar functionality is available with nearly any text rasterizer I'm aware of.