that requires a lot of heuristics, because you have to take into account the overall length, where the number of sections varies. So you need to backtrace, see what you can cut, go forward backtrace again, etc. Not a job for the templates logic.
But the biggest problem is that you don't know what's the font size/family is used by the client, so you cannot really know how many chars is ok.
I presume from these comments that the breadcrumb must not word-wrap onto a new line?
It's OK if this happens, but we better not. Try to insert a long title and see how it works.
2) Remove "stop words" (the, and, of, etc) from the title,
then truncate to
character x (so "CGI to mod_perl Porting. mod_perl Coding
guidelines" could
become "CGI mod_perl porting", etc)
3) Remove any words not beginning with a capital letter (i.e. minor words) - "CGI to mod_perl Porting. mod_perl Coding guidelines"
becomes "CGI
Porting Coding". Now, I agree, this is a terrible title - but
only because
the title of the document itself is poorly constructed...
These two doesn't sound like very good ones, authors will forget to Upcase some words in titles, certain titles won't make sense without the articles.
So there will be no editing? Is there anyplace where a "breadcrumb title" can be explicitely defined?
Currently we already have the concept of title and stitle attributes, because we have a more prominent problem with the menu. So the menu uses stitle (short title). But these two are available only for index.html pages (think docset titles), leaf document have only the title attribute:
html: <title>...</title> pod: =head1 NAME
Good idea. You could replace "..." with "current page",
"current document",
"this page", etc, etc.
I prefer "this page" or "..."
I prefer "this page" I must admit.
ok. this is only for the leaf nodes, right? the index.html pages don't need this terminator.
I have another idea: use the real filenames. Assuming that the filenames are descriptive (which I think is the case) this will work well and filenames are already short enough.
If this were any other site but mod_perl, then I say no to this straight away as the filenames will be meaningless to most users. However, I think it's safe to assume that our audience is a little bit more savvy. Even so, I think filenames are a little "off" - not quite what we are looking for IMHO.
On the second thought we already have the URL with real filenames. So it's probably not a good idea to duplicate this concept.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
