Simon Montagu :smontagu Reporter
	Description • 18 years ago

Spun off from bug 332646 per bug 332646 comment 6 and 19.

	Simon Montagu :smontagu Reporter
	Comment 1 • 18 years ago

One of the things I'd like to do is consolidate ucvmath with uconv. rbs, in the past you were opposed to doing that. Are you still against it?

	Doug Turner (:dougt)
	Comment 2 • 18 years ago

it will continue to be optional via a #define?

	Simon Montagu :smontagu Reporter
	Comment 3 • 18 years ago

Yes :)

	Simon Montagu :smontagu Reporter
	Comment 4 • 18 years ago

Here's another idea: uconv includes a lot of encoder/decoders for very rare charsets which I've never seen used in web pages. What about giving embedders the option to #define something like MOZ_UCONV_LITE which would exclude all of those?

In ucvlatin I would suggest excluding the following:
x-u-escape (unless we remove it altogether in bug 350830)
ISO-8859-6-E
ISO-8859-6-I
ISO-8856-6-E
ISO-IR-111
TIS-620
All the Mac codepages except MacRoman
GEOSTD8
armscii-8
x-viet-tcvn5712
VISCII
x-viet-vps
UTF-7
x-imap4-modified-8tf7
UTF-32

Jungshik, can you suggest which East Asian codepages could be excluded?

Mike, can you do the same for IBM codepages?

	Jungshik Shin
	Comment 5 • 18 years ago

What a coincidence ! I hit upon the same idea as while I was walking to work this morning :-) 


ko : JamoTTF (1), Johab(4), ISO2022KR(2)
ja : ISO2022JP(3)
cn : ISO2022CN(1), HZ(2)
tw :  
tw2 : This entire directory can be omitted because EUC-TW is rarely used, but ... it's tough to decide... maybe we have to keep them for now
latin: TSCII 

(1) : no problem without them for embedders.
(2) : necessary for mail and news (although their usage share have been rapidly declining)
(3) : mainly for mail/news, but in some rare cases, used for web pages
(4) : little problem without it, but could be necessary if X11fonts are used. That fine-adjustment can be made later. So for now, same as (1)

There are converters only built with MOZ_EXTRA_X11CONVERTERS. Depending on fonts (and toolkit) used in small devices, this may or may not be necessary. So, they should be left alone so that they can be controlled by MOZ_EXTRA_X11CONVERTERS even on small devices.

BTW, x-imap4-modified-utf7 is not necessary for web pages but is required for an imap client. Hmm, having said that, I think we have to build it only for mailnews (i.e. should not build it for firefox) I wonder if we have a variable that can be used to tell whether mailnews is built or not? 

	Benjamin Smedberg
	Comment 6 • 18 years ago

Because Firefox and Thunderbird are supposed to be using the same gecko core (and will be in practice when they both use XULRunner), we should ship one standard set of converters for the platform. Unless of course you could plug converters in separately and ship them with the tbird app instead of the platform, but that doesn't sound useful.

	Mike Kaply [:mkaply]
	Comment 7 • 18 years ago

Actually plugin converters would be great because some platforms need converters that other platforms don't...

	Simon Montagu :smontagu Reporter
	Comment 8 • 18 years ago

(In reply to comment #7)
> Actually plugin converters would be great because some platforms need
> converters that other platforms don't...

So why don't you get sr and checkin your pach for bug 239942?

	Mike Kaply [:mkaply]
	Comment 9 • 18 years ago

(In reply to comment #8)
> (In reply to comment #7)
> > Actually plugin converters would be great because some platforms need
> > converters that other platforms don't...
> 
> So why don't you get sr and checkin your pach for bug 239942?
> 

wow. I totally forgot about that. On my list.

	Masatoshi Kimura [:emk]
	Comment 10 • 13 years ago

We don't have to care about embedders anymore.
https://groups.google.com/forum/#!topic/mozilla.dev.embedding/c_NMcO-N8wo/discussion

	Henri Sivonen (:hsivonen) (away from Bugzilla until 2023-09-11) Assignee
	Comment 11 • 7 years ago

Bug 1261841 made libxul smaller on x86_64 at least.