You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs-dev@perl.apache.org by Bill Moseley <mo...@hank.org> on 2002/03/23 22:59:34 UTC
Need stylesheet help for NS4.0
Hi,
I replaced most of the <font> tags in the search results template (that
template came from the swish-e distribution package).
But my search results falls apart in NS4.0. Can someone take a look and
see if they know any tricks to make NS4 work.
Someone's review of the styles I added might be wise, too. ;)
You can preview over my slow connection at
http://hank.org:5000/
I added the "_" and ":" to what swish considers part of a word, so
searching for mod_perl really searches for the single word "mod_perl", and
searching for Apache::Registry will find that, as a single word, too.
That changes means searching for "Registry" won't find "Apache::Registry".
Play with that and see if you like it better.
Currently only pages generated with the "page_body" template are indexed.
This is because the spider is only extracting out content within
<div class="index_section">
tags, and that's in page_body. That means the index.html pages are not
indexed, which is probably what we want.
Searching in sub-sections seems to work reasonably well. If you are on the
documentation page it will search all docs in the /docs/* tree, but if you
are looking at a Guide page and type search it will search just The Guide.
I'm still +1 for moving the search box to the side bar for two reasons: 1)
it frees up space in the content area, and 2) I like the idea of a radio
button to search the current section or everything. Someone might be
browsing The Guide and then want to search for something, but not limit it
to The Guide.
>http://www.bullitt.suite.dk/new_logo_top/download/search.html
One problem: did anyone look at that test in Netscape? NS4 doesn't work.
Again, if someone can help find why NS4 is messing up in search results,
that would be a big help, as I have no idea!
Thanks,
--
Bill Moseley
mailto:moseley@hank.org
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Grammar Advisory
Posted by Stas Bekman <st...@stason.org>.
Bill Moseley wrote:
> At 11:22 PM 04/15/02 +0100, Jonathan M. Hollin wrote:
>
>>Mod_perl is the power behind many of the Internet's busiest and most
>>advanced web sites. Listed here are success stories from people using
>>mod_perl; also, world-wide statistics of mod_perl usage
>
>
> That's the idea. Toot our horn a bit.
These are committed. Keep these on coming.
> So how does one adjust the statistics considering that probably most
> mod_perl sites are behind a proxy?
break into many sites and re-install the front-end saying that its backend
is mod_perl :) But at 3.5M hosts I don't think we should really complain :)
ORA still keeps this ugly php is installed on more sites than mod_perl
to sell
php conference :(
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
RE: Grammar Advisory
Posted by Bill Moseley <mo...@hank.org>.
At 11:22 PM 04/15/02 +0100, Jonathan M. Hollin wrote:
>Mod_perl is the power behind many of the Internet's busiest and most
>advanced web sites. Listed here are success stories from people using
>mod_perl; also, world-wide statistics of mod_perl usage
That's the idea. Toot our horn a bit.
So how does one adjust the statistics considering that probably most
mod_perl sites are behind a proxy?
--
Bill Moseley
mailto:moseley@hank.org
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
RE: Grammar Advisory
Posted by "Jonathan M. Hollin" <ne...@digital-word.com>.
>I think it should be rewritten more like:
>
> Mod_perl is the power behind many of the Internet's busiest and
> most advanced web sites. Listed here are success stories from
> people using mod_perl...
>
>Something will a little stronger language.
>
>What do you think? I'm not a writer, but I hope you get what
>I'm saying.
I like where you're coming from Bill. To your text I would add:
Mod_perl is the power behind many of the Internet's busiest and most
advanced web sites. Listed here are success stories from people using
mod_perl; also, world-wide statistics of mod_perl usage
>I know I've said this before, but "Technologie Extraordinaire"
>still sounds funny to me.
:-)
Jonathan M. Hollin - WYPUG Co-ordinator
West Yorkshire Perl User Group
http://wypug.pm.org/
http://wypug.digital-word.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Grammar Advisory
Posted by Bill Moseley <mo...@hank.org>.
At 10:48 PM 04/15/02 +0100, Jonathan M. Hollin wrote:
>Technologie Extraordinaire
>We have lots of great success reports from people using mod_perl,
>including world-wide statistics no mod_perl usage.
Funny, I was just reading that as you wrote.
I think it should be rewritten more like:
Mod_perl is the power behind many of the Internet's busiest and
most advanced web sites. Listed here are success stories from
people using mod_perl...
Something will a little stronger language.
What do you think? I'm not a writer, but I hope you get what I'm saying.
I know I've said this before, but "Technologie Extraordinaire" still sounds
funny to me.
--
Bill Moseley
mailto:moseley@hank.org
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Need stylesheet help for NS4.0
Posted by Stas Bekman <st...@stason.org>.
Bill Moseley wrote:
> Sorry for the large attachments!
>
> Thanks Allan those stylesheet changes did fix the NS4 problem. I've
> attached search-NS4.0.png so you can see what it looks like in Netscape
> 4.08 on Win98.
much better :) though it seems that the title has lost the background.
> On my machine the fonts for the search results are larger than I like. I'm
> not sure if that's my machine or just the way I'm thinking. So I attached
> both a search results from our search, and a search results from google
> with slightly smaller fonts, so you can compare. I was trying to get
> closer to the google look.
looks fine to me :)
> Also, should the URL fragment be stripped on that (green) display of the path?
let's keep it for now, it's easy to remove things later
> Also, what about the "Search Time". I wanted it very small, but still
> readable. Maybe it should just be removed completely?
ok as well
what's this section's date/time under each result? is it the
modification time?
5708 bytes 2002-03-23 11:58:24 PST
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Grammar Advisory
Posted by "Jonathan M. Hollin" <ne...@digital-word.com>.
Re: http://perl.apache.org/preview/modperl-docs/dst_html/index.html
A comma (,) should never precede the word "and".
The paragraph:
Technologie Extraordinaire
We have lots of great success reports from people using mod_perl,
including world-wide statistics no mod_perl usage.
should read:
Technologie Extraordinaire
We have lots of great success stories from people using mod_perl,
including world-wide statistics on mod_perl usage.
The paragraph:
Download
Get Source and Binary mod_perl distributions and additional Perl Modules
has capitalisation overdone (IMHO):
Download
Get source and binary mod_perl distributions and additional Perl modules
The paragraph:
Getting Help
Solve your mod_perl problems: with help of mod_perl mailing lists,
mod_perl training company or a commercial support company. Find an ISP
providing mod_perl services.
should read:
Getting Help
Solve your mod_perl problems: with the help of the mod_perl mailing
lists, a mod_perl training company or a commercial support company. Find
an ISP providing mod_perl services.
The paragraph:
Mailing Lists
mod_perl and related projects mailing lists
"projects" has ownership over "mailing lists" in this context so:
Mailing Lists
mod_perl and related projects' mailing lists
or
Mailing Lists
mod_perl and related project mailing lists
I'll post more as I find them.
Jonathan M. Hollin - WYPUG Co-ordinator
West Yorkshire Perl User Group
http://wypug.pm.org/
http://wypug.digital-word.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Need stylesheet help for NS4.0
Posted by Bill Moseley <mo...@hank.org>.
Sorry for the large attachments!
Thanks Allan those stylesheet changes did fix the NS4 problem. I've
attached search-NS4.0.png so you can see what it looks like in Netscape
4.08 on Win98.
On my machine the fonts for the search results are larger than I like. I'm
not sure if that's my machine or just the way I'm thinking. So I attached
both a search results from our search, and a search results from google
with slightly smaller fonts, so you can compare. I was trying to get
closer to the google look.
Also, should the URL fragment be stripped on that (green) display of the path?
Also, what about the "Search Time". I wanted it very small, but still
readable. Maybe it should just be removed completely?
Thanks again for the help!
Re: Need stylesheet help for NS4.0
Posted by Bill Moseley <mo...@hank.org>.
At 04:00 PM 03/24/02 +0800, allan wrote:
>hi bill
>
>i will post suggestions for the search styles later ...
>
>> >http://www.bullitt.suite.dk/new_logo_top/download/search.html
>>
>> One problem: did anyone look at that test in Netscape? NS4 doesn't work.
>
>
>i developed that on ns4/mac so i _know_ it's working ok on
>my machine. what is wrong at your machine?
Oh, sorry. Here's a snapshot -- without resizing NS4
Re: Need stylesheet help for NS4.0
Posted by allan <la...@inet.uni2.dk>.
hi bill
i will post suggestions for the search styles later ...
> >http://www.bullitt.suite.dk/new_logo_top/download/search.html
>
> One problem: did anyone look at that test in Netscape? NS4 doesn't work.
i developed that on ns4/mac so i _know_ it's working ok on
my machine. what is wrong at your machine?
./allan
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Need stylesheet help for NS4.0
Posted by Stas Bekman <st...@stason.org>.
Bill Moseley wrote:
> At 05:26 PM 3/26/2002 +0800, Stas Bekman wrote:
>
>
>>>You mean replace \n with some flag (e.g. '#$%$#') only in <pre> sections?
>>>\n in HTML should matter.
>>
>>You suggested %0A in the previous email, but I was actually thinking to
>>have all sentences separated with <br> rather than thrown altogether. no
>>matter if it's HTML or <pre>
>
>
> %0A will get indexed as 0A.
>
> It's not really sentence based. The highlighting code finds a word or
> phrase, then flags the previous and next five words. It stops highlighting
> after finding six hits. The "..." are added if words are skipped between
> the ten snippets.
>
> What you are saying is you find a hit, then flag backwards to the beginning
> of the sentence, and flag forward to the end of the sentence, then display
> that entire sentence, right? I think that might end up with long snippets.
> Also phrases can match across sentences.
but we can find the end of the sentence, no? using the punctuation
rules. (or for code by preserving/restoring \n) so at least we can put
each matching phrase (part of a sentence) on a separate line, is that
correct?
I think the *only* problem with the current matched text presentations,
is mixing sentences (including code). If we keep the same presentation
as we have now plus somehow keep separate sub-sentence on separate lines
we have a perfect output.
> I can't remember how the highlight code works (it varies in the different
> highlighting modules). One maintains a FIFO stack that always contains
> enough words to show the context only. Another splits the entire document
> into an array.
>
> I wonder if this is more tweaking than is needed for most users. I'd think
> in general seeing a word/phrase with five or so words on each side will
> show the context.
>
>
> Bill Moseley
> mailto:moseley@hank.org
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Need stylesheet help for NS4.0
Posted by Bill Moseley <mo...@hank.org>.
At 05:26 PM 3/26/2002 +0800, Stas Bekman wrote:
>> You mean replace \n with some flag (e.g. '#$%$#') only in <pre> sections?
>> \n in HTML should matter.
>
>You suggested %0A in the previous email, but I was actually thinking to
>have all sentences separated with <br> rather than thrown altogether. no
>matter if it's HTML or <pre>
%0A will get indexed as 0A.
It's not really sentence based. The highlighting code finds a word or
phrase, then flags the previous and next five words. It stops highlighting
after finding six hits. The "..." are added if words are skipped between
the ten snippets.
What you are saying is you find a hit, then flag backwards to the beginning
of the sentence, and flag forward to the end of the sentence, then display
that entire sentence, right? I think that might end up with long snippets.
Also phrases can match across sentences.
I can't remember how the highlight code works (it varies in the different
highlighting modules). One maintains a FIFO stack that always contains
enough words to show the context only. Another splits the entire document
into an array.
I wonder if this is more tweaking than is needed for most users. I'd think
in general seeing a word/phrase with five or so words on each side will
show the context.
Bill Moseley
mailto:moseley@hank.org
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Need stylesheet help for NS4.0
Posted by Stas Bekman <st...@stason.org>.
Bill Moseley wrote:
> At 04:55 PM 03/26/02 +0800, Stas Bekman wrote:
>
>>OK, how about this:
>>When indexing strip all the HTML. and replace \n with whatever swish-e
>>can store.
>
>
> You mean replace \n with some flag (e.g. '#$%$#') only in <pre> sections?
> \n in HTML should matter.
You suggested %0A in the previous email, but I was actually thinking to
have all sentences separated with <br> rather than thrown altogether. no
matter if it's HTML or <pre>
> When presenting results display:
>
>>- N "short sentences" per hit
>>- enclosed in <pre></pre>
>>- and \n restored
>>
>>this should make it perfect speed and usability-wise if this is doable.
>>And this will improve the speed of highlighting since it'll be a plain text.
>
>
> It won't gain any speed since it currently only works with plain text. The
> trade off will be maybe better readability, but a loss of compactness.
>
> It might be fun to try -- wouldn't be that hard...thanks to Perl.
cool ;)
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Need stylesheet help for NS4.0
Posted by Bill Moseley <mo...@hank.org>.
At 01:04 AM 03/26/02 -0800, Bill Moseley wrote:
>You mean replace \n with some flag (e.g. '#$%$#') only in <pre> sections?
>\n in HTML should matter.
Argh! shouldn't matter..
To late for me.
--
Bill Moseley
mailto:moseley@hank.org
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Need stylesheet help for NS4.0
Posted by Bill Moseley <mo...@hank.org>.
At 04:55 PM 03/26/02 +0800, Stas Bekman wrote:
>OK, how about this:
>When indexing strip all the HTML. and replace \n with whatever swish-e
>can store.
You mean replace \n with some flag (e.g. '#$%$#') only in <pre> sections?
\n in HTML should matter.
When presenting results display:
>
>- N "short sentences" per hit
>- enclosed in <pre></pre>
>- and \n restored
>
>this should make it perfect speed and usability-wise if this is doable.
>And this will improve the speed of highlighting since it'll be a plain text.
It won't gain any speed since it currently only works with plain text. The
trade off will be maybe better readability, but a loss of compactness.
It might be fun to try -- wouldn't be that hard...thanks to Perl.
--
Bill Moseley
mailto:moseley@hank.org
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Need stylesheet help for NS4.0
Posted by Stas Bekman <st...@stason.org>.
> If I'm missing what you are suggesting, send what you think
>
> http://hank.org:5000/search/swish.cgi?query=registry
>
> should look like.
OK, how about this:
When indexing strip all the HTML. and replace \n with whatever swish-e
can store. When presenting results display:
- N "short sentences" per hit
- enclosed in <pre></pre>
- and \n restored
this should make it perfect speed and usability-wise if this is doable.
And this will improve the speed of highlighting since it'll be a plain text.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Need stylesheet help for NS4.0
Posted by Per Einar Ellefsen <pe...@skynet.be>.
Actually, I'll rest my case. I think I caused more problems by that remark,
because it's a little too much to implement. Searching is still great, and
turns out good results 75% of the time.
At 09:45 26.03.2002, Bill Moseley wrote:
>At 02:39 PM 03/26/02 +0800, Stas Bekman wrote:
>
> >Per Einar Ellefsen wrote:
> >> What I can suggest: as we generate our HTML from POD files, knowing what
> >> is code, could there maybe be some possibility of putting some <div>
> >> tags around the <pre> ones, and then patch Swish in some way to get it
> >> to treat those parts as searchable but not displayable? If I understood
> >> it right, it's already using some <div> tags to know what to index, so
> >> maybe it would be possible to make it a little more advanced?
>
>You mean don't display the context since it doesn't look nice in the
>summary? I think I'd rather have it show the context even if it is ugly.
>
>The highlighting code is designed to just show the first X words or X
>characters (depending on which highlight module is used) if no matching
>context is found to display, but I'd still rather see the word hits, if
>possible.
>
> Search google for: ["the guide" AND "light registry"]
>
>It does basically the same thing.
>
> >I don't think this is possible, since the hit doesn't happen in the
> >sentence but an index which points to the section which includes this
> >sentence.
>
>Right. It's isn't grep.
>
>Also, if you start trying to preserve HTML then it becomes a bit more
>tricky and slow to do the phrase highlighting, since a phrase match in
>swish might match across HTML formatting. For example imagine highlighting
>the *phrase* that matches the last word of one link, and the first word of
>a link that follows. Matching "foo bar":
>
> <a href="first">bla bla foo</a> <a href="second">bar bla bla</a>
>
>ends up as:
>
> <a href="first">bla bla <span class="mark">foo</span></a><span
>class="mark"> </span><a href="second"><span class="mark">bar</span> bla
>bla</a>
>
>And it gets even harder when that first link might have looked like:
>
> <a href="first">bla <em>bla fo</em>o</a>
>
>Not very likely, buy you can see why you then need HTML::TreeBuilder to do
>that kind of rewriting of the HTML. The phrase highlighting code is messy
>enough working with just plain text. So if you start highlighting code in
>50K or 100K documents where you need to first build a HTML tree then
>parsing speed becomes quite noticeable.
>
>Currently, even without parsing the HTML, all the slowness in returning
>results you see is coming from the highlighting code (well, that I see on
>my LAN, as you may have a slow connection). Turn off highlighting and the
>results are returned very fast.
>
>I'm sure Google is much smarter about highlighting than swish (considering
>swish doesn't do highlighting). But google doesn't try too hard either.
>Here's how it highlighted the phrase
>"light set" which included html formatting:
>
> <i><B style="color:black;background-color:#99ff99">light</i> </B>
> <B style="color:black;background-color:#99ff99">set</B>
>
>A little nesting problem there, I think.
>
>
> >I've another suggesting: is it possible to distinguish between sentences
> >(or parts of) when presenting the hit's context? If so we could add
> ><br>'s after each sentence/part of and therefore make it more readable.
> >I know you said that \n are removed, but if there is a way to keep the
> >original strings as tokens in the index, this will improve the
> >readability a lot.
>
>I probably could substitute \n inside of <pre> sections with %0A or
>something like that in the swish parser code, or in the code that splits
>the documents into sections replace \n inside <pre> with a set of chars
>that won't be indexed, but can then be used as a flag to show where \n are
>found (and thus replace with <br>). But I think that's overkill.
>
>Look at http://hank.org:5000/search/swish.cgi?query=registry
>
>I'll put back in the \n below -- swish does a s/\s+/ /g in some cases (when
>joining text together), so swish would need to be modified to keep
>whitespace, too, inside of <pre> sections.
>
> ... the light set we are going to use the registry.pl script running
>under Apache::Registry: benchmarks/registry.pl
>----------------------
>use strict;
>print "Content-type: text/plain ... pl file:
>use Apache::RegistryLoader ();
>Apache::RegistryLoader->new->handler(
>"/perl/benchmarks/registry.pl",
>"/home/httpd/perl/benchmarks/registry .pl");
>To create the heavy benchmark set let ...
>results:------------------------------
>name | avtime rps
>------------------------------
>light handler | 15 911
>light registry | 21 680
>------------------------------
>heavy handler | 183 81
>heavy registry | 191 77
>------------------------------
>Let's look at the results ... comparison:
>------------------------------
>name | avtime rps
>------------------------------
>light handler | 50 196
>light registry | 160 61
>------------------------------
>heavy handler | 149 67
>
>Even if it was formatted correctly (without swish doing s/\s+//g;) you end
>up with a lot longer summary for a little readability gain.
>
>The idea is not that the search results show the page correctly, rather
>that it just shows some content to help you decide if you should follow the
>link in the search result.
>
>If I'm missing what you are suggesting, send what you think
>
> http://hank.org:5000/search/swish.cgi?query=registry
>
>should look like.
>
>
>--
>Bill Moseley
>mailto:moseley@hank.org
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
>For additional commands, e-mail: docs-dev-help@perl.apache.org
--
Per Einar Ellefsen
per.einar@skynet.be
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Need stylesheet help for NS4.0
Posted by Bill Moseley <mo...@hank.org>.
At 02:39 PM 03/26/02 +0800, Stas Bekman wrote:
>Per Einar Ellefsen wrote:
>> What I can suggest: as we generate our HTML from POD files, knowing what
>> is code, could there maybe be some possibility of putting some <div>
>> tags around the <pre> ones, and then patch Swish in some way to get it
>> to treat those parts as searchable but not displayable? If I understood
>> it right, it's already using some <div> tags to know what to index, so
>> maybe it would be possible to make it a little more advanced?
You mean don't display the context since it doesn't look nice in the
summary? I think I'd rather have it show the context even if it is ugly.
The highlighting code is designed to just show the first X words or X
characters (depending on which highlight module is used) if no matching
context is found to display, but I'd still rather see the word hits, if
possible.
Search google for: ["the guide" AND "light registry"]
It does basically the same thing.
>I don't think this is possible, since the hit doesn't happen in the
>sentence but an index which points to the section which includes this
>sentence.
Right. It's isn't grep.
Also, if you start trying to preserve HTML then it becomes a bit more
tricky and slow to do the phrase highlighting, since a phrase match in
swish might match across HTML formatting. For example imagine highlighting
the *phrase* that matches the last word of one link, and the first word of
a link that follows. Matching "foo bar":
<a href="first">bla bla foo</a> <a href="second">bar bla bla</a>
ends up as:
<a href="first">bla bla <span class="mark">foo</span></a><span
class="mark"> </span><a href="second"><span class="mark">bar</span> bla
bla</a>
And it gets even harder when that first link might have looked like:
<a href="first">bla <em>bla fo</em>o</a>
Not very likely, buy you can see why you then need HTML::TreeBuilder to do
that kind of rewriting of the HTML. The phrase highlighting code is messy
enough working with just plain text. So if you start highlighting code in
50K or 100K documents where you need to first build a HTML tree then
parsing speed becomes quite noticeable.
Currently, even without parsing the HTML, all the slowness in returning
results you see is coming from the highlighting code (well, that I see on
my LAN, as you may have a slow connection). Turn off highlighting and the
results are returned very fast.
I'm sure Google is much smarter about highlighting than swish (considering
swish doesn't do highlighting). But google doesn't try too hard either.
Here's how it highlighted the phrase
"light set" which included html formatting:
<i><B style="color:black;background-color:#99ff99">light</i> </B>
<B style="color:black;background-color:#99ff99">set</B>
A little nesting problem there, I think.
>I've another suggesting: is it possible to distinguish between sentences
>(or parts of) when presenting the hit's context? If so we could add
><br>'s after each sentence/part of and therefore make it more readable.
>I know you said that \n are removed, but if there is a way to keep the
>original strings as tokens in the index, this will improve the
>readability a lot.
I probably could substitute \n inside of <pre> sections with %0A or
something like that in the swish parser code, or in the code that splits
the documents into sections replace \n inside <pre> with a set of chars
that won't be indexed, but can then be used as a flag to show where \n are
found (and thus replace with <br>). But I think that's overkill.
Look at http://hank.org:5000/search/swish.cgi?query=registry
I'll put back in the \n below -- swish does a s/\s+/ /g in some cases (when
joining text together), so swish would need to be modified to keep
whitespace, too, inside of <pre> sections.
... the light set we are going to use the registry.pl script running
under Apache::Registry: benchmarks/registry.pl
----------------------
use strict;
print "Content-type: text/plain ... pl file:
use Apache::RegistryLoader ();
Apache::RegistryLoader->new->handler(
"/perl/benchmarks/registry.pl",
"/home/httpd/perl/benchmarks/registry .pl");
To create the heavy benchmark set let ...
results:------------------------------
name | avtime rps
------------------------------
light handler | 15 911
light registry | 21 680
------------------------------
heavy handler | 183 81
heavy registry | 191 77
------------------------------
Let's look at the results ... comparison:
------------------------------
name | avtime rps
------------------------------
light handler | 50 196
light registry | 160 61
------------------------------
heavy handler | 149 67
Even if it was formatted correctly (without swish doing s/\s+//g;) you end
up with a lot longer summary for a little readability gain.
The idea is not that the search results show the page correctly, rather
that it just shows some content to help you decide if you should follow the
link in the search result.
If I'm missing what you are suggesting, send what you think
http://hank.org:5000/search/swish.cgi?query=registry
should look like.
--
Bill Moseley
mailto:moseley@hank.org
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Need stylesheet help for NS4.0
Posted by Stas Bekman <st...@stason.org>.
Per Einar Ellefsen wrote:
>> >I suggest the following solution: if you meet a <pre> tag and no closing
>> ></pre> tag we add it.
>> >Do you think this is possible Bill? Assuming that all the HTML is proper
>> >(no text without enclosing <p>),
>> >we can always tell which text is not HTML (i.e. <pre>) am I right?
>>
>> It's not that easy. Swish is what is storing the content. It's being
>> parsed by libxml2 and it's just storing the text, not any of the tags.
>> It's also converting \n into white space, so any formatting would be lost
>> anyway.
>>
>> For HTML in general, it's a fun task to add highlighting code around a
>> group of words -- and still keep the HTML valid.
>
>
> Yes, I can understand it's very hard.
> What I can suggest: as we generate our HTML from POD files, knowing what
> is code, could there maybe be some possibility of putting some <div>
> tags around the <pre> ones, and then patch Swish in some way to get it
> to treat those parts as searchable but not displayable? If I understood
> it right, it's already using some <div> tags to know what to index, so
> maybe it would be possible to make it a little more advanced?
I don't think this is possible, since the hit doesn't happen in the
sentence but an index which points to the section which includes this
sentence.
> Another possibility: I know it's not optimal, but maybe the search
> results should only display descriptions of the page in question?
> This brings out another issue: if the pages were more split out (the
> guide pages are veeery long), maybe we could get more concise results
> and descriptions matching more closely.
If you look again at how the new search works, you will see that its
results are pointing to the single page sections and not the whole page
which can be big. This is a great boon compared to the previous
situation and removed the need to created the split version of the guide
which I was producing before, e.g. see here:
http://thingy.kcilink.com/modperlguide/strategy/The_Solution.html
the engine is here:
http://thingy.kcilink.com/modperlguide/index.html#search
In any case if you will try to write descriptions to all section you
will find yourself writing another set of the documentation. It's
feasible, but impractical.
I've another suggesting: is it possible to distinguish between sentences
(or parts of) when presenting the hit's context? If so we could add
<br>'s after each sentence/part of and therefore make it more readable.
I know you said that \n are removed, but if there is a way to keep the
original strings as tokens in the index, this will improve the
readability a lot.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Need stylesheet help for NS4.0
Posted by Per Einar Ellefsen <pe...@skynet.be>.
At 23:14 25.03.2002, Bill Moseley wrote:
>At 01:41 AM 03/26/02 +0800, Stas Bekman wrote:
> >> Another issue of the search I'd like to address is that the packet of
> >> results that come back is a little problematic: the mixture of code
> >> which cannot be formatted and text is a mess, and you're easily turned
> >> off byt it. I suggest that we make it search through the code sections
> >> (as it's still pretty important), but we don't show the code listing on
> >> the results page.
>
>I guess it would be helpful to know what you searched for to see what you
>are seeing.
>
>The bit of content returned with each search result is just to help decide
>if that's the result one might be interested in. I never considered that
>it had to be formatted correctly, and in fact for something like perl code
>that would take up too much space.
Well, try searching for "registry" as an example, something I know many
people would try to search for.
What you get.. is.. well, hard to get a grip of. I've been put off by
similar results on other sites, and it just didn't make me want to search
there.
I know we can't correctly format it in the results, but there must some
other possibility.
> >I suggest the following solution: if you meet a <pre> tag and no closing
> ></pre> tag we add it.
> >Do you think this is possible Bill? Assuming that all the HTML is proper
> >(no text without enclosing <p>),
> >we can always tell which text is not HTML (i.e. <pre>) am I right?
>
>It's not that easy. Swish is what is storing the content. It's being
>parsed by libxml2 and it's just storing the text, not any of the tags.
>It's also converting \n into white space, so any formatting would be lost
>anyway.
>
>For HTML in general, it's a fun task to add highlighting code around a
>group of words -- and still keep the HTML valid.
Yes, I can understand it's very hard.
What I can suggest: as we generate our HTML from POD files, knowing what is
code, could there maybe be some possibility of putting some <div> tags
around the <pre> ones, and then patch Swish in some way to get it to treat
those parts as searchable but not displayable? If I understood it right,
it's already using some <div> tags to know what to index, so maybe it would
be possible to make it a little more advanced?
Another possibility: I know it's not optimal, but maybe the search results
should only display descriptions of the page in question?
This brings out another issue: if the pages were more split out (the guide
pages are veeery long), maybe we could get more concise results and
descriptions matching more closely.
Just some thoughts.
--
Per Einar Ellefsen
per.einar@skynet.be
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Need stylesheet help for NS4.0
Posted by Stas Bekman <st...@stason.org>.
Bill Moseley wrote:
> At 01:41 AM 03/26/02 +0800, Stas Bekman wrote:
>
>>>Another issue of the search I'd like to address is that the packet of
>>>results that come back is a little problematic: the mixture of code
>>>which cannot be formatted and text is a mess, and you're easily turned
>>>off byt it. I suggest that we make it search through the code sections
>>>(as it's still pretty important), but we don't show the code listing on
>>>the results page.
>>
>
> I guess it would be helpful to know what you searched for to see what you
> are seeing.
>
> The bit of content returned with each search result is just to help decide
> if that's the result one might be interested in. I never considered that
> it had to be formatted correctly, and in fact for something like perl code
> that would take up too much space.
that wasn't my question, but Per Einar's :)
>>I suggest the following solution: if you meet a <pre> tag and no closing
>></pre> tag we add it.
>>Do you think this is possible Bill? Assuming that all the HTML is proper
>>(no text without enclosing <p>),
>>we can always tell which text is not HTML (i.e. <pre>) am I right?
>
>
> It's not that easy. Swish is what is storing the content. It's being
> parsed by libxml2 and it's just storing the text, not any of the tags.
> It's also converting \n into white space, so any formatting would be lost
> anyway.
>
> For HTML in general, it's a fun task to add highlighting code around a
> group of words -- and still keep the HTML valid.
Never mind then, it's still better to see what are the hits.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Need stylesheet help for NS4.0
Posted by Bill Moseley <mo...@hank.org>.
At 01:41 AM 03/26/02 +0800, Stas Bekman wrote:
>> Another issue of the search I'd like to address is that the packet of
>> results that come back is a little problematic: the mixture of code
>> which cannot be formatted and text is a mess, and you're easily turned
>> off byt it. I suggest that we make it search through the code sections
>> (as it's still pretty important), but we don't show the code listing on
>> the results page.
I guess it would be helpful to know what you searched for to see what you
are seeing.
The bit of content returned with each search result is just to help decide
if that's the result one might be interested in. I never considered that
it had to be formatted correctly, and in fact for something like perl code
that would take up too much space.
>I suggest the following solution: if you meet a <pre> tag and no closing
></pre> tag we add it.
>Do you think this is possible Bill? Assuming that all the HTML is proper
>(no text without enclosing <p>),
>we can always tell which text is not HTML (i.e. <pre>) am I right?
It's not that easy. Swish is what is storing the content. It's being
parsed by libxml2 and it's just storing the text, not any of the tags.
It's also converting \n into white space, so any formatting would be lost
anyway.
For HTML in general, it's a fun task to add highlighting code around a
group of words -- and still keep the HTML valid.
--
Bill Moseley
mailto:moseley@hank.org
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Need stylesheet help for NS4.0
Posted by Stas Bekman <st...@stason.org>.
Per Einar Ellefsen wrote:
> At 18:04 25.03.2002, Stas Bekman wrote:
>
>> Bill Moseley wrote:
>>
>>> At 01:20 PM 03/25/02 +0800, Stas Bekman wrote:
>>>
>>>>> That changes means searching for "Registry" won't find
>>>>> "Apache::Registry".
>>>>> Play with that and see if you like it better.
>>>>
>>>>
>>>> hmm, can we teach swish-e some special logics? e.g. can we tell
>>>> swish-e to take any perl module that it sees (i.e. a::b) and split
>>>> it into words but still search for parts and whole module names?
>>>
>>>
>>> So Apache::Registry would get indexed as these three words?
>>> 1 apache::registry
>>> 2 apache
>>> 3 registry
>>> Of course we can, it's open source, after all ;)
>>> My guess is it would be easier to do in perl. SwishProgParameters.pl
>>> has
>>> HTML::TreeBuilder code -- I suppose once the new documents are created
>>> could traverse the HTML tree and use a regular expression to match
>>> module
>>> names and add additional content by splitting on /::/.
>>> What do you think?
>>
>>
>> Sounds good to me, but before we talk about feasibility.
>> Will this give good intuitive results? I think the :: special case will
>> help a lot for the perl related code.
>
>
> Yes, this is very important. Imagine you're looking for something
> talking about registry scripts. You search for "registry", you don't get
> Apache::Registry, and you search for Apache::Registry, you don't get the
> common "registry scripts" expression. So this is definitely very important.
of course. That's exactly the idea :)
> Another issue of the search I'd like to address is that the packet of
> results that come back is a little problematic: the mixture of code
> which cannot be formatted and text is a mess, and you're easily turned
> off byt it. I suggest that we make it search through the code sections
> (as it's still pretty important), but we don't show the code listing on
> the results page.
I suggest the following solution: if you meet a <pre> tag and no closing
</pre> tag we add it.
Do you think this is possible Bill? Assuming that all the HTML is proper
(no text without enclosing <p>),
we can always tell which text is not HTML (i.e. <pre>) am I right?
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Need stylesheet help for NS4.0
Posted by Per Einar Ellefsen <pe...@skynet.be>.
At 18:04 25.03.2002, Stas Bekman wrote:
>Bill Moseley wrote:
>>At 01:20 PM 03/25/02 +0800, Stas Bekman wrote:
>>
>>>>That changes means searching for "Registry" won't find "Apache::Registry".
>>>>Play with that and see if you like it better.
>>>
>>>hmm, can we teach swish-e some special logics? e.g. can we tell swish-e
>>>to take any perl module that it sees (i.e. a::b) and split it into words
>>>but still search for parts and whole module names?
>>
>>So Apache::Registry would get indexed as these three words?
>> 1 apache::registry
>> 2 apache
>> 3 registry
>>Of course we can, it's open source, after all ;)
>>My guess is it would be easier to do in perl. SwishProgParameters.pl has
>>HTML::TreeBuilder code -- I suppose once the new documents are created
>>could traverse the HTML tree and use a regular expression to match module
>>names and add additional content by splitting on /::/.
>>What do you think?
>
>Sounds good to me, but before we talk about feasibility.
>Will this give good intuitive results? I think the :: special case will
>help a lot for the perl related code.
Yes, this is very important. Imagine you're looking for something talking
about registry scripts. You search for "registry", you don't get
Apache::Registry, and you search for Apache::Registry, you don't get the
common "registry scripts" expression. So this is definitely very important.
Another issue of the search I'd like to address is that the packet of
results that come back is a little problematic: the mixture of code which
cannot be formatted and text is a mess, and you're easily turned off byt
it. I suggest that we make it search through the code sections (as it's
still pretty important), but we don't show the code listing on the results
page.
--
Per Einar Ellefsen
per.einar@skynet.be
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Need stylesheet help for NS4.0
Posted by Stas Bekman <st...@stason.org>.
Bill Moseley wrote:
> At 01:20 PM 03/25/02 +0800, Stas Bekman wrote:
>
>>>That changes means searching for "Registry" won't find "Apache::Registry".
>>>Play with that and see if you like it better.
>>
>>hmm, can we teach swish-e some special logics? e.g. can we tell swish-e
>>to take any perl module that it sees (i.e. a::b) and split it into words
>>but still search for parts and whole module names?
>
>
> So Apache::Registry would get indexed as these three words?
> 1 apache::registry
> 2 apache
> 3 registry
>
> Of course we can, it's open source, after all ;)
>
> My guess is it would be easier to do in perl. SwishProgParameters.pl has
> HTML::TreeBuilder code -- I suppose once the new documents are created
> could traverse the HTML tree and use a regular expression to match module
> names and add additional content by splitting on /::/.
>
> What do you think?
Sounds good to me, but before we talk about feasibility.
Will this give good intuitive results? I think the :: special case will
help a lot for the perl related code.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Need stylesheet help for NS4.0
Posted by Bill Moseley <mo...@hank.org>.
At 01:20 PM 03/25/02 +0800, Stas Bekman wrote:
>> That changes means searching for "Registry" won't find "Apache::Registry".
>> Play with that and see if you like it better.
>
>hmm, can we teach swish-e some special logics? e.g. can we tell swish-e
>to take any perl module that it sees (i.e. a::b) and split it into words
>but still search for parts and whole module names?
So Apache::Registry would get indexed as these three words?
1 apache::registry
2 apache
3 registry
Of course we can, it's open source, after all ;)
My guess is it would be easier to do in perl. SwishProgParameters.pl has
HTML::TreeBuilder code -- I suppose once the new documents are created
could traverse the HTML tree and use a regular expression to match module
names and add additional content by splitting on /::/.
What do you think?
--
Bill Moseley
mailto:moseley@hank.org
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Need stylesheet help for NS4.0
Posted by Stas Bekman <st...@stason.org>.
> You can preview over my slow connection at
>
> http://hank.org:5000/
>
> I added the "_" and ":" to what swish considers part of a word, so
> searching for mod_perl really searches for the single word "mod_perl", and
> searching for Apache::Registry will find that, as a single word, too.
>
> That changes means searching for "Registry" won't find "Apache::Registry".
> Play with that and see if you like it better.
hmm, can we teach swish-e some special logics? e.g. can we tell swish-e
to take any perl module that it sees (i.e. a::b) and split it into words
but still search for parts and whole module names?
> Currently only pages generated with the "page_body" template are indexed.
> This is because the spider is only extracting out content within
>
> <div class="index_section">
>
> tags, and that's in page_body. That means the index.html pages are not
> indexed, which is probably what we want.
+1
> Searching in sub-sections seems to work reasonably well. If you are on the
> documentation page it will search all docs in the /docs/* tree, but if you
> are looking at a Guide page and type search it will search just The Guide.
Yes, looks fantastic, Bill!
+1
> I'm still +1 for moving the search box to the side bar for two reasons: 1)
> it frees up space in the content area, and 2) I like the idea of a radio
> button to search the current section or everything. Someone might be
> browsing The Guide and then want to search for something, but not limit it
> to The Guide.
OK, let's try it then (since I've +1 x 2 for the left bar and not other
comments). I waiting for Allan to send me the latest design, when he
will get some free time to finish these, so I suppose it will include
this left search bar in it.
>>http://www.bullitt.suite.dk/new_logo_top/download/search.html
>
>
> One problem: did anyone look at that test in Netscape? NS4 doesn't work.
>
> Again, if someone can help find why NS4 is messing up in search results,
> that would be a big help, as I have no idea!
When NS4 gets messed-up, it's usually when the HTML is not perfect. I
use sgmlcheck to find these problems. I see:
/usr/bin/nsgmls:<OSFD>0:10:51:E: there is no attribute "TYPE"
/usr/bin/nsgmls:<OSFD>0:14:11:E: there is no attribute "CLASS"
/usr/bin/nsgmls:<OSFD>0:24:17:E: character "%" is not allowed in the
value of attribute "WIDTH"
/usr/bin/nsgmls:<OSFD>0:29:34:E: there is no attribute "CLASS"
/usr/bin/nsgmls:<OSFD>0:29:59:E: character "%" is not allowed in the
value of attribute "WIDTH"
/usr/bin/nsgmls:<OSFD>0:33:42:E: general entity "nbsp" not defined and
no default entity
/usr/bin/nsgmls:<OSFD>0:45:35:E: there is no attribute "CLASS"
/usr/bin/nsgmls:<OSFD>0:49:44:E: there is no attribute "BGCOLOR"
/usr/bin/nsgmls:<OSFD>0:255:49:E: there is no attribute "CLASS"
/usr/bin/nsgmls:<OSFD>0:404:114:E: there is no attribute "CLASS"
/usr/bin/nsgmls:<OSFD>0:482:22:E: character "%" is not allowed in the
value of attribute "WIDTH"
/usr/bin/nsgmls:<OSFD>0:497:34:E: character "%" is not allowed in the
value of attribute "WIDTH"
/usr/bin/nsgmls:<OSFD>0:500:48:E: character "%" is not allowed in the
value of attribute "WIDTH"
/usr/bin/nsgmls:<OSFD>0:590:34:E: character "%" is not allowed in the
value of attribute "WIDTH"
/usr/bin/nsgmls:<OSFD>0:593:35:E: character "%" is not allowed in the
value of attribute "WIDTH"
the real problems are
- character "%" is not allowed in the value of attribute "WIDTH"
- there is no attribute "BGCOLOR"
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Need stylesheet help for NS4.0
Posted by Bill Moseley <mo...@hank.org>.
At 05:09 PM 03/24/02 +0800, allan wrote:
><font style="background:#FFFF99">mod_perl</font>
Oh, right, that's the highlighting module that's doing that. For got about
that.
>also, please dont supply properties for the dd,dt tags, try
>this kind instead:
>
><dd>
> <div class="searchsummary">
> ... Document summary ...
> </div>
></dd>
I'll try that, too, but my previous thinking was <div> add a line break.
(I haven't tried it yet.)
>also i think you should increase all 0.6ems font-sizes to at
>least 0.80 - on macintosh font are generally smaller i think
Ok.
So, why doesn't everyone run at 72dpi and when they want more screen size
buy a bigger monitor? I had one person complain that fonts and graphics
were too small -- turned out he was running something like 140dpi!
I'm watching the kids today, but I'll try to test your changes and then
post an image if NS4 still messes up.
Do you really think maintaining a second sytlesheet for NS4 would be too
much work? Assuming it would make things work in NS4... I wonder if there
is a sytlesheet converter available for NS4.
Time for breakfast!
--
Bill Moseley
mailto:moseley@hank.org
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Need stylesheet help for NS4.0
Posted by allan <la...@inet.uni2.dk>.
hi bill
i suggest you replace all font tags like this:
<font style="background:#FFFF99">mod_perl</font>
<span class="sp-bg">mod_perl</span>
and in your style sheet do something like:
span.sp-bg {
background:#FFFF99;
}
the <span> tag is the proper tag for this kind of thing i
think. as to why it needs the style specs in the style
sheet, god knows.
also, please dont supply properties for the dd,dt tags, try
this kind instead:
<dd>
<div class="searchsummary">
... Document summary ...
</div>
</dd>
<dd>
<div class="searchprops">
searcswish.cgi etc ..
</div>
</dd>
also i think you should increase all 0.6ems font-sizes to at
least 0.80 - on macintosh font are generally smaller i think
- see below for a quick suggestion.
hth
./allan
__TRY__
/* Search Results */
div.searchform {
font-size: 0.9em;
}
td.searchheader {
background-color: #525a73;
font-family: verdana, arial, helvetica, sans-serif;
color: #ffffff;
font-size: 0.9em;
}
td.searchtimes {
background-color: #525a73;
font-family: verdana, arial, helvetica, sans-serif;
color: #ffffff;
font-size: 0.8em;
}
td.searchnav {
background-color: #eeeeee;
font-family: verdana, arial, helvetica, sans-serif;
color: #000000;
font-size: 0.8em;
}
span.back {
background:#FFFF99;
}
div.searchsummary {
font-size: 0.85em;
}
div.searchprops {
font-size: 0.80em;
color: green;
}
__END__
Bill Moseley wrote:
>
> Hi,
>
> I replaced most of the <font> tags in the search results template (that
> template came from the swish-e distribution package).
>
> But my search results falls apart in NS4.0. Can someone take a look and
> see if they know any tricks to make NS4 work.
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org