Closed Bug 14713 Opened 21 years ago Closed 13 years ago

Default for unsupported CSS2 list-style-type

Categories

(Core :: Layout, enhancement, P4)

enhancement

Tracking

()

RESOLVED WORKSFORME
mozilla1.3alpha

People

(Reporter: sue, Assigned: jshin1987)

References

()

Details

(Keywords: css2, intl, testcase, Whiteboard: [Hixie-P5] WFM per comment 27/28?)

Attachments

(2 files)

I'd like to see a default other than '.' for list-style-types which are
unsupported. Even:

1. First in katakana
2. Second in katakana

is preferable to:

. First in katakana
. Second in katakana

Or a default disc for each list item would suffice.
I don't know if this is you or Peter
Assignee: troy → kipp
Actually, we support each and every type. For some reason they don't always
render properly, probably due to a lack of fonts on the test system. I've
attached a screen snapshot of how it looks on *my* linux system; I'm reassigning
to frank tang so that he can check that we are in fact doing the right thing.
Assignee: kipp → ftang
Hey frank, maybe this is just erik's problem...I dunno...if you are convinced
your code is doing the right thing, then please reassign it to erik to deal
withe font rendering issues...thanks
Yea, the issue is GFX on Linux and Window render NOTHING when the glyph is not
available.

You linux do not have georgian/armenian/greek font so it does not show those
three. We plan to add Symbol font support in the future and then you should see
the lower-greek correctly.

The screen shot from sue@css.nu show no CJK/katakana/hiragana because his system
have NO CJK font installed.


Try it after you install those fonts listed in
http://people.netscape.com/ftang/communicatorfont.html
Status: NEW → ASSIGNED
Target Milestone: M14
Mark this as M14 assigned.
QA Contact: petersen → chrisd
Assignee: ftang → erik
Status: ASSIGNED → NEW
reassign to erik.
Status: NEW → ASSIGNED
Target Milestone: M14 → M15
Keywords: css2
Moving all of my M15s to M16. Please add comments if you disagree.
Target Milestone: M15 → M16
These list styles are relatively obscure and rarely used. Since Japanese users
are likely to have Japanese fonts, it will work on their systems. Likewise for
Greek and Armenian. It would be nice if we substituted numerals (1, 2, etc) when
the glyphs are not available, but this bug is already marked Enhancement, and I
have tons of more important work to do, so I'm targetting M20.
Target Milestone: M16 → M20
Pierre, thought you might be interested. You might want to ping DG about it too.
I think we need a GFX API to tell layout a given character can be render or not.
reassign back to ftang for now and mark Future
Assignee: erik → ftang
Status: ASSIGNED → NEW
Target Milestone: --- → Future
accept
Status: NEW → ASSIGNED
Netscape's standard compliance QA team reorganised itself once again, so taking 
remaining non-tables style bugs. Sorry about the spam. I tried to get this done 
directly at the database level, but apparently that is "not easy because of the 
shadow db", "plus it screws up the audit trail", so no can do...
QA Contact: chrisd → ian
I think we can fix this one once we have realiable HaveFontFor implementation in
GFX.
Whiteboard: [Hixie-P5]
Adding qawanted; needs a testcase. The original URL is 404.
Keywords: qawanted
Updated URI for testcase
FWIW, WorksForMe using FizzillaCFM/2002071208. I see symbols that I can only
presume are right for all the types demonstrated as dots in the testcase.
Keywords: qawanted
We now have the API now. we can use nsIFontEnumerator->HaveFontFor to see we
have the font for specific lang group or not. 
Target Milestone: Future → ---
Priority: P3 → P4
Target Milestone: --- → mozilla1.3alpha
Wouldn't we render '?' anyway for glyphs we did not find?

Can anyone still reproduce this problem?
ping?  Is this still a problem?
OK, I had some people test and they say that '?' is rendered for the list styles
the have no fonts for.

jshin, what do you think?  Should we just wontfix this?  Or should we try to use
the HaveFontFor stuff?
I'm not sure. I'm inclined to go with 'WONTFIX'. Judging from that you asked me,
I guess CSS spec doesn't have much to say about cases like this. Anyway, to make
up my mind, I have to check how (well) 'HaveFontFor' works.  
Keywords: intl
OS: Windows 95 → All
Hardware: PC → All
The present 'HaveFontFor' in the enumerator is not really what is needed.

Layout (in nsBulletFrame) is just passing its label text to DrawString(). What
is needed is an API that tells whether or not the text passed to DrawString is
guaranteed to appear fully without question marks. Using this information,
layout can decide whether or not to pass the equivalent 'numeric' text instead.

This is a small word... I had such an attempt in bug 78211 (in a different
context which wasn't critical and thus it didn't capture enough interest...).
Actually, |HaveFontFor| can be of some help too, by hard-coding (in
nsBulletFrame) a mapping of the language atom (or list of languages) most likely
to cover the glyphs that will appear with each list-style-type. This alternative
might be much easier to implement with what is already in the codebase. It will
amount to determining if the needed font is there _before_ making up the
numbers. The lack of the font would therefore override the style, allowing to
fallback back to decimal right at the beginning.
Yeah, that's what I'd want to do....  Dealing with a failing DrawString from
that code would be very unpleasant.
FWIW, the expectation from the CSS point of view is that you'd display the ? 
characters. Whatever we do here will likely either get dropped or have to be 
shoehorned into the more generic world when (if, heh) we implement lists the 
proper CSS3 way, through generated content and counters. (With counters, you 
want the right characters to appear at the DOM level.)
OK.  In that case, I propose we mark this worksforme...
Keywords: testcase
Whiteboard: [Hixie-P5] → [Hixie-P5] WFM per comment 27/28?
*** Bug 263062 has been marked as a duplicate of this bug. ***
what a hack. I have not touch mozilla code for 2 years. I didn't read these bugs
for 2 years. And they are still there. Just close them as won't fix to clean up.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
Mass Reassign Please excuse the spam
Assignee: ftang → nobody
Mass Re-opening Bugs Frank Tang Closed on Wensday March 02 for no reason, all
the spam is his fault feel free to tar and feather him
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Reassigning Franks old bugs to Jungshik Shin for triage - Sorry for spam
Assignee: nobody → jshin1987
Status: REOPENED → NEW
Marking WFM as suggested by bz.
Status: NEW → RESOLVED
Closed: 15 years ago13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.