![]()
# For this reason I think it's important to provide both forms, the full
# article and the separate pages.
I had not considered supporting both, but it covers all bases... ;-) I'll have
to think about how to present it... Initially bring up a "split page" table of
contents with words and a link to the single file version ? Have different
index entries, different index files for those that want split pages ?
Ideas ?
# For multipart FAQs, I'd love to see the parts combined with a single
# index. I have an intro section and an index to all parts at the
# beginning of each part; I'd like to see those elided. I can't say how
# you should do that ...
I read this two different ways, combining all the parts into a single file,
(I don't think that's what you mean) or have a single index entry that goes
to a top level index built just for the multipart FAQ. (I think that's what
was meant.)
I like the idea but the problem is what goes in the Intro section ? Just
the preamble of the digested faqs ? Is that it or are there other things ?
This assumes the FAQ is in one of the digest formats. Not quite a universal
situation yet...
# You should handle at least all the faqmailfaqmail and structured formats that
# Tom Fine handled.
Alright... This is the 4th person to suggest that I support his format. Does
anyone have a good definition of it ? I could not find it on Ohio-State.
I need to get his docs that describe it. Does anyone have a copy ?
If there are other definitions of formats beside RFC1153 and the Minimal
Digest Format please send me a copy.
# Tom Lane mentioned displaying the Summary. I have the same Summary in
# all parts, though I'll consider changing it. I include a word or two in
# the Subject line which gives a clue as to what the part contains, so
# the existing display is fine for the diabetes FAQ.
I think that his use of the Summary is a good one.
# You should suppress the article headers except the most critical (From,
# Newsgroups, Date, Reply-To, Subject, Summary). The complete header is a
# lot of garbage to wade through at the top. Move it somewhere else to be
# displayed on request. Some links in the headers should not be:
# Originator could send useless email to faqserv@bloom-picayune.MIT.EDU;
# the Supersedes: link is useless by definition; the Message-ID link is
# of questionable value at best.
And I went to all that trouble to put it in there and now you want me to
take it out... ;) Point taken. I'll review the headers and not htmlasize
(a word coming to a dictionary near you in the next century) those that
supply no value.
# Tom Fine has a way to cross-reference sections within an FAQ. I've never
# tried to make it work because it won't work across parts. If you define
# a format that looks OK to human eyes and also converts to a link and
# works across parts, I'd try to use the facility.
Again, an understanding of what he was doing would help. I never took
the time before and now it would help.
# Link marking is a bit too aggressive for my taste. In addition to my
# comments about the headers, I see far too many links to my own
# newsgroup; it's a bit distracting to read a paragraph with
# misc.health.diabetes underlined three or four times. A comment about
# "the alt.support hierarchy" gets a news: link. I try to explain a valid
# email address as "user@domain.typ"; this gets a mailto: link.
I am putting in checking for the newsgroups to try to get rid of hierarchy
references being turned into news: links. The mailto: reference you pointed
out should have been skipped... I'll have to check and see if I can squash
that bug.
# The search returns most hits as being in an .../index.html file. This
# seems to be the file created when the FAQ is not split up. This is
# confusing.
This is being corrected. The reference to index.html need not be presented
to the user and is being removed.
# The search also shows raw html when it finds the target there. This is
# very ugly and will confuse users, though I don't have a sound suggested
# alternative.
Yeah. I'm trying to either enable it or remove it from the output. The
problem with enabling it is I can't guarantee the HTML in the output
is complete. Some of it can span multiple lines that are not returned
as part of the search.... I still have some work to do on the searching.
I'd really like to thank you for taking the time to review it. Good points
here and I'll make use of them.
-- Kent Landfield Phone: 1-817-545-2502 The Landfield Group FAX: 1-817-545-7650 Email: kent@landfield.com http://www.landfield.com/ Please send comp.sources.misc related mail to kent@uunet.uu.net.
[
Usenet Hypertext FAQ Archive |
Search Mail Archive |
Authors |
Usenet
]
[
1993 |
1994 |
1995 |
1996 |
1997
]
![]()
© Copyright The Landfield Group, 1997
All rights reserved