TeXworks / texworks

Main codebase for TeXworks, a simple interface for working with TeX documents
https://tug.org/texworks/
GNU General Public License v2.0
697 stars 127 forks source link

Spell-checker not working when username contains non-latin (russian) letters #177

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Create a windows user with name containing russian letters (for example
"Юля")
2. Login to the system with this username
3. Run Texworks, it will create "TeXworks" directory in "C:\Documents and
Setting\Юля"
4. Put some spelling dictionaries in the "C:\Documents and
Setting\Юля\TeXworks\dictionaries"  
5. Re-run Texworks, turn on one of the installed dictionaries.

What is the expected output? What do you see instead?
Spell-checker should work, but it does not while user name contains
non-latin letters. 

Using Filemon (from sysinternals) i've found that spell-checker tryes to
get access to "C:\Documents and Settings\Юля\TeXworks\dictionaries\"
instead of "C:\Documents and Setting\Юля\TeXworks\dictionaries". 

If username contains only english letters - everything's fine.

I'm using temporary workaround - i created directory "C:\Documents and
Settings\Юля\TeXworks\dictionaries\" and copyed dictionaries in it, and
now it's working fine. 

What version of the product are you using? On what operating system?
TeXworks 0.1(r.404)
Microsoft Windows XP [Версия 5.1.2600] (russian)

Please provide any additional information below.

Original issue reported on code.google.com by filimono...@gmail.com on 25 Aug 2009 at 2:29

GoogleCodeExporter commented 9 years ago
Hi,

this sounds like an encoding problem. My guess is that this happens with any
non-ascii character (umlauts, accents, Chinese characters etc.). It should also 
be
possible to use texworks-setup.ini to store configuration files in a path 
containing
such characters (so one doesn't have to create a user). Unfortunately, I can't 
test
it right now (I'm on Linux).

It would be perfect if you (or someone else who can reproduce this issue) could 
try
to compile Tw yourself (see the wiki for guidelines) with the following 
modification:
in TWUtils.cpp, find the function TWUtils::getDictionary. In it, replace the 
lines
        h = Hunspell_create(affFile.canonicalFilePath().toUtf8().data(),
                            dicFile.canonicalFilePath().toUtf8().data());
by
        h = Hunspell_create(affFile.canonicalFilePath().toLocal8Bit().data(),
                            dicFile.canonicalFilePath().toLocal8Bit().data());
and then try again.

Note however that this is only a test, not a general solution. Does anyone know 
which
encoding different versions of Windows (e.g. Russian, Chinese, ...) use?

Original comment by st.loeffler on 26 Aug 2009 at 8:07

GoogleCodeExporter commented 9 years ago

Original comment by st.loeffler on 8 Sep 2009 at 12:40

GoogleCodeExporter commented 9 years ago
I've checked in this change as r.420.

I think toLocal8Bit() is probably the right thing to use; at least for files 
whose pathname can be represented in 
the system codepage on Windows, it should be correct. I guess files with 
Unicode names that can't be 
mapped to the system default codepage will still fail, but that should be 
pretty rare.

On OS X, the "local 8-bit encoding" seems to be utf-8, so this change is OK 
there as well. Stefan, if you have a 
chance to experiment on Linux, that would be great. I suspect it's probably OK 
there too - most Linux distros 
these days use utf-8 by default, so I expect Qt will probably recognize that. 
If it breaks, we could put a 
platform conditional here.

Original comment by jfkth...@gmail.com on 15 Sep 2009 at 11:47

GoogleCodeExporter commented 9 years ago
I did a quick test on Ubuntu 9.04 and it works. AFAIK, Ubuntu uses utf8 
internally.

Note however that this issue probably didn't affect Linux, anyway, as the
dictionaries are expected to be in /usr/share/myspell/dicts - no special 
characters
or user customization here.

Original comment by st.loeffler on 16 Sep 2009 at 5:11

GoogleCodeExporter commented 9 years ago

Original comment by st.loeffler on 12 Apr 2011 at 8:55