"font stacks" and a parsing algorithm bug

VERIFIED DUPLICATE of bug 991

Status

()

P1
trivial
VERIFIED DUPLICATE of bug 991
21 years ago
20 years ago

People

(Reporter: jmomose, Assigned: harishd)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

21 years ago
Created by Jared Momose (jmomose@casefinder.com) on Tuesday, June 30, 1998 2:30:24 PM PDT
Additional Details :
There is not a separate section for "logical" bugs, so Ill
present my case in this section.

This bug is deals with text and attribute changing when a
document is displayed on a screen.

From what I have seen, when Netscape loads and displays
documents on the screen, it sets up a "Font Stack" to do its
attribute changing.  Say you change the current text in a
document to bold; Netscape pushes the current font onto a
stack and uses that font + bold for the new font.  The
problem comes when you have a line like the following.

text <B> text <I> text </B> text </I> text

When the </B> tag appears, the font stack is popped, and a
previous font is retrieved.  However, this previous font
does not have bold turned off, but rather has italics turned
off!  If you are following me, take it one step further.
Try putting a <FONT COLOR="#mycolor"> in the above html line
and modifying it such that a different attribute is turned
off before the color is.

Another question arises: "who would do such a thing as
overlap font attributes?".  Well....me!

I would love to hear some input from mozilla developers,
especially reasons *why* this "Font Stack" was implemented
into the browser. (Am I missing something?  Is it faster
than other techniques for formatting and displaying a doc?
Easier?)

Jared Momose.
Geronimo Developement Corp.

Updated

20 years ago
Assignee: djw → dp

Updated

20 years ago
Assignee: dp → nisheeth

Comment 1

20 years ago
Would this be legal HTML: <b> text <i> text </b> more text </i>

Updated

20 years ago
Status: NEW → ASSIGNED

Comment 2

20 years ago
Off the top of my head, I'd say that that is invalid HTML.  I'll check
the spec.  Accepting bug...

Updated

20 years ago
Product: MozillaClassic → Browser
Version: 1998-04-29 → other

Comment 3

20 years ago
not sure if this is still relevant in new codebase... if not feel free to close

Comment 4

20 years ago
per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

Updated

20 years ago
Target Milestone: M7

Comment 5

20 years ago
I just checked out "<B> bold <I> bold-italic </B> italic </I>" in Gecko.  The
"italic" text gets rendered in normal font while IE 5 renders it in italic font.
I remember Rick had ideas on how to deal with this case, so I'm ccing him.
Also, ccing Harish, the in-process-of-becoming parser guru.

Setting milestone to M7 for now...
(Assignee)

Updated

20 years ago
Assignee: nisheeth → harishd
Status: ASSIGNED → NEW
Target Milestone: M7 → M6
(Assignee)

Comment 6

20 years ago
This is a classic case of Residual-Style problem.
In the example, <B> bold <I> bold-italic </B> italic </I>, </B> closes <I> and
<B> leaving the text "italic" to be rendered in a normal font. Rickg and I are
working on this problem.

Reassigning the bug to myself and setting M6 milestone.
(Assignee)

Comment 7

20 years ago
Adding nisheeth to the CC list.
(Assignee)

Updated

20 years ago
Priority: P3 → P1

Updated

20 years ago
Status: NEW → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → DUPLICATE

Comment 8

20 years ago
*** This bug has been marked as a duplicate of 991 ***

Updated

20 years ago
Status: RESOLVED → VERIFIED

Comment 9

20 years ago
Agreed. This is a duplicate of 991.
You need to log in before you can comment on or make changes to this bug.