Per http://code.google.com/p/sumatrapdf/issues/detail?id=1188 , compiling openjpeg under codepage 932 isn't warning free due to the "é" in the license header. Since we compile with warnings-as-errors, this seems to prevent developers on Japanese systems from compiling vanilla openjpeg 1.4.

Reencoding the files in UTF-8 (with or without BOM) seems to fix this issue - at least for MSVC.

I removed the "é" in license header.

Please tell me if it works ok now.

Thanks. We've found one more character not having an equivalence in codepage 932: in jp2.c around line 1055 one comment contains en-dashes ("61966–2–1"). Replacing them with ASCII-hyphens would allow us to compile without disabling warning C4819.

Done. Could you confirm that I can set the issue to 'fixed' ?

I've checked out trunk and been able to compile without disabling warning C4819, so this issue has been fixed. Thanks.

One detail, though, is that I've discovered that we also already have silenced a warning C2220 (conflict between 'signed' and 'unsigned') through the following modification:

diff -r 02387baf5bdd ext/openjpeg/jp2.c --- a/ext/openjpeg/jp2.c Sat Jan 29 22:36:06 2011 +0000 +++ b/ext/openjpeg/jp2.c Sun Jan 30 21:24:56 2011 +0100 @@ -624,11 +624,11 @@ bool jp2_read_jp2h(opj_jp2_t *jp2, opj_c if (!jp2_read_bpcc(jp2, cio)) return false; } jp2_read_boxhdr(cinfo, cio, &box);

• while(cio_tell(cio) < jp2h_end)
• while((unsigned int)cio_tell(cio) < jp2h_end) { if(box.type == JP2_COLR) { if( !jp2_read_colr(jp2, cio, &box, color)) {

Should I file a new issue for this one-liner?

Thanks for having pointed this.

It has been fixed in r724 (jp2h_end is now defined as 'int' rather than 'unsigned int').