Open Bug 23953 Opened 25 years ago Updated 2 years ago

[mozTXTToHTMLConv] Conversion of footnotes to links

Categories

(MailNews Core :: Backend, enhancement, P3)

Other
Other
enhancement

Tracking

(Not tracked)

People

(Reporter: karl, Unassigned)

References

Details

(Keywords: helpwanted)

(I'm sorry if this is the wrong component) As you know, Mozilla supports conversion of *bold* to bold and _italic_ to italic, conversion of smileys to graphics and automatic links recognition. Here's a suggestion for a similar feature, conversion of footnotes to links. In e-mail[1], "footnote references" are often written like this, with the footnote at the bottom of the message. It would be nice if the [n]'s could automatically be turned into links to the corresponding footnotes. The [n]'s at the bottom of the message could also be links to its footnote reference (the first if there are several for one footnote). So not to create unnecessary footnote links (e.g. in ASCII art), a algorithm similiar to this one should used: Suggestion for automatic footnote recognition algorithm: Create footnote link if you find a 1. [number], where the first one *must* be numbered [1], the second [2] and so on, with exception of 2. A [2] when no [1] exist earlier in the message should be ignored (this goes for all other [n] with no [n-1] earlier in the same message too. 3. All [n]'s should have coresponding _CRLF[n] Footnote definition_ at the bottom of the message (if not, they should be ignored). [1] And in newsgroups too.
Assignee: phil → mozilla
Wow, that's pretty ambitious. Reassign to Ben Bucksch, cc rhp.
Status: NEW → RESOLVED
Closed: 25 years ago
Depends on: 20212
Resolution: --- → WONTFIX
...and there're implementation issues, too: Dependency on bug #20212. WONTFIX. Feel free to make HELP WANTED or so.
Well, if you don't check, if there's a corresponding footnote, there's no dependency on 20212. It would be a DUP of bug #23327.
perhaps it would be good to mark this help wanted.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
.
Assignee: mozilla → nobody
Status: REOPENED → NEW
Keywords: helpwanted
I like this idea. I suggested something similar on n.p.m.mail-news and n.p.m.wishlist a while back, although the algorithm I suggested wasn't nearly as picky as this one. However, I think that this algorithm isn't exclusive enough in one respect: it doesn't pay attention to quotation levels. A footnote reference in a quoted line most likely does not refer to a footnote in the later document. I think that the HTML tags generated by this feature should go something like this... for a footnote reference "[n]" in quote level q: <A HREF="#footnote_n_q" CLASS="footref"><SPAN CLASS="txt-tag">[</SPAN>n<SPAN CLASS="txt-tag">]</SPAN></A> for the corresponding footnote: <SPAN CLASS="footnote"><A NAME="footnote_n_q" CLASS="footref"><SPAN CLASS="txt-tag">[</SPAN>n<SPAN CLASS="txt-tag">]</SPAN></A>footnote definition</SPAN> That way these sorts of styles could be applied: A.footref {vertical-align: superscript; font-size: 90%} // a good default. Superscripts references, but preserves brackets so the way to create footnotes is easy to deduce. A.footref {vertical-align: superscript; font-size: 90%} A.footref SPAN.txt-tag SPAN.txt-tag {display: none} SPAN.footnote {font-size: 90%} // book style. Supercripts references, removes brackets, shrinks footnote text.
Component: Mail Back End → Networking
Product: MailNews → Browser
Component: Networking → Mail Window Front End
Product: Browser → MailNews
> However, I think that this > algorithm isn't exclusive enough in one respect: it doesn't pay > attention to quotation levels. Good point. > A footnote reference in a quoted line > most likely does not refer to a footnote in the later document. But it should still work (if the footnote is available). If you have the following: ... baz[1] ... >> ... foo[1] ... >> [..] >> [1] Foo something ... > > ... bar[1] ... > [...] > [1] Bar something ... [1] Baz something ... All footnote references should work, and point to different footnotes. I agree with you about the styling of footnotes.
Karl Ove, I intentionally moved it to Networking, since that is where the code lives. It's not special to Mailnews. Back to Networking.
Component: Mail Window Front End → Networking
Product: MailNews → Browser
KArl Ove: yes, that's what I meant. That's why I said the link should be #footnote_n_q for footnote [n] at quote level |q|. That would make sure the links all pointed to the correct note. I'd like to add that I think "A [2] when no [1] exist earlier in the message should be ignored (this goes for all other [n] with no [n-1] earlier in the same message too" is probably overkill if "All [n]'s should have coresponding _CRLF[n] Footnote definition_ at the bottom of the message (if not, they should be ignored)" is implemented. It would be particularly problematic for quoted footnotes, since preceding notes could easily have been (and should be) edited out if they are irrelevant to the reply.
> It > would be particularly problematic for quoted footnotes, since > preceding notes could easily have been (and should be) edited out if > they are irrelevant to the reply. Yes, for quoted footnotes, this will be a problem, and shouldn't be done, but I still think we should do this for unquoted footnotes (as an extra precaution against accidental false positives).
mass assignment of text->HTML bugs to MailNews w/ esther as QA.
Component: Networking → Mail Back End
Product: Browser → MailNews
Version: Trunk → other
Component: Mail Back End → MIME
Summary: Conversion of footnotes to links → [mozTXTToHTMLConv] Conversion of footnotes to links
Product: MailNews → Core
Moving a bunch of mozTXTToHTMLConv bugs into Core / MailNews Backend to live with their bretheren.
Component: MailNews: MIME → MailNews: Backend
Filter on "Nobody_NScomTLD_20080620"
QA Contact: lchiang → backend
Product: Core → MailNews Core
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.