The current way we load hyphenation dictionaries is to call GetNativePath on a nsIFile. This method can fail on Windows, because on Windows not every file can be represented by a char*: the only reliable way to represent a file path is with a WCHAR*/PRUnichar*. http://hg.mozilla.org/mozilla-central/annotate/787ebf02a8c1/intl/hyphenation/src/nsHyphenator.cpp#l50 This can probably be fixed by bug 65537, but if not we need to modify libhyphen to take a windows-style path on Windows.
(In reply to Benjamin Smedberg [:bsmedberg] from comment #0) > This can probably be fixed by bug 65537, but if not we need to modify > libhyphen to take a windows-style path on Windows. Correction: bug 655337.
Created attachment 559690 [details] [diff] [review] patch, use URI spec rather than utf8 file path to specify hyphenation dictionary As the code only uses very basic stdio calls to access the dictionary, it looks like we could easily #define those functions in the hnjalloc.h header (which is a custom mozilla version anyway) in order to work around the issue here without having to actually patch the hyphen.c source (which I'd prefer to avoid if possible). Here's a first attempt at a simple implementation - this replaces fopen, fgets and fclose (for the libhyphen code only) so that the string we pass to hnj_hyphen_load is a URL spec instead of just a pathname, and nsIInputStream is used to read from it - basically as Ehsan suggested in bug 655337 comment #6, point 3. This version avoids changing the API of hnj_hyphen_load (e.g. to take an nsIURI instead of a C string), so that we don't have to patch core libhyphen code. This should also provide a basis for loading hyphenation dictionaries from resource:// URLs referencing JARs, rather than individual files; as such, it's a first step towards fixing bug 655337.
Comment on attachment 559690 [details] [diff] [review] patch, use URI spec rather than utf8 file path to specify hyphenation dictionary Looks good to me.