14713 - Default for unsupported CSS2 list-style-type

Status: RESOLVED WORKSFORME

(Core :: Layout, enhancement, P4)

Description

[sue]

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.

Comment 1

[troy]

I don't know if this is you or Peter

Comment 2

[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.

Comment 3

[kipp]

Attachment: snapshot from linux system

Comment 4

[kipp]

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

Comment 5

[sue]

Attachment: Screen shot win'95 9-22 build

Comment 6

[Frank Tang]

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 [e-mail] 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

Comment 7

[Frank Tang]

Mark this as M14 assigned.

Comment 8

[Frank Tang]

reassign to erik.

Comment 9

[Erik van der Poel]

Moving all of my M15s to M16. Please add comments if you disagree.

Comment 10

[Erik van der Poel]

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.

Comment 11

[Hixie (not reading bugmail)]

Pierre, thought you might be interested. You might want to ping DG about it too.

Comment 12

[Frank Tang]

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

Comment 13

[Frank Tang]

accept

Comment 14

[Hixie (not reading bugmail)]

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...

Comment 15

[Frank Tang]

I think we can fix this one once we have realiable HaveFontFor implementation in
GFX.

Comment 16

[Greg K.]

Adding qawanted; needs a testcase. The original URL is 404.

Comment 17

[sue]

Updated URI for testcase

Comment 18

[Greg K.]

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.

Comment 19

[Frank Tang]

We now have the API now. we can use nsIFontEnumerator->HaveFontFor to see we
have the font for specific lang group or not. 

Comment 20

[Boris Zbarsky [:bzbarsky]]

Wouldn't we render '?' anyway for glyphs we did not find?

Can anyone still reproduce this problem?

Comment 21

[Boris Zbarsky [:bzbarsky]]

ping?  Is this still a problem?

Comment 22

[Boris Zbarsky [:bzbarsky]]

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?

Comment 23

[Jungshik Shin]

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.  

Comment 24

[rbs]

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...).

Comment 25

[rbs]

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.

Comment 26

[Boris Zbarsky [:bzbarsky]]

Yeah, that's what I'd want to do....  Dealing with a failing DrawString from
that code would be very unpleasant.

Comment 27

[Hixie (not reading bugmail)]

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.)

Comment 28

[Boris Zbarsky [:bzbarsky]]

OK.  In that case, I propose we mark this worksforme...

Comment 29

[Boris Zbarsky [:bzbarsky]]

*** Bug 263062 has been marked as a duplicate of this bug. ***

Comment 30

[Frank Tang]

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.

Comment 31

[Travis Chase]

Mass Reassign Please excuse the spam

Comment 32

[Travis Chase]

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

Comment 33

[Travis Chase]

Reassigning Franks old bugs to Jungshik Shin for triage - Sorry for spam

Comment 34

[Jesse Ruderman]

Marking WFM as suggested by bz.