Closed Bug 14713 Opened 21 years ago Closed 13 years ago
Default for unsupported CSS2 list-style-type
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.
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 firstname.lastname@example.org 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
Mark this as M14 assigned.
reassign to erik.
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
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.
Adding qawanted; needs a testcase. The original URL is 404.
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.
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 → ---
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.
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...
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 ago → 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.