[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] patch: compilation fix for wx 2.9
From: |
Greg Chicares |
Subject: |
Re: [lmi] patch: compilation fix for wx 2.9 |
Date: |
Sat, 15 May 2010 14:27:47 +0000 |
User-agent: |
Thunderbird 2.0.0.24 (Windows/20100228) |
On 2010-05-15 12:24Z, Vadim Zeitlin wrote:
> On Sat, 15 May 2010 11:49:07 +0000 Greg Chicares <address@hidden> wrote:
[...no useful diagnostic for wide-character filenames...]
> Without this the only thing we can do is to give an error message if a
> non-ASCII file name is used. This is not ideal, to say the least, but
> would still be better than the current situation. Should I make a patch
> implementing this?
Instead, could you just give an example of how you'd detect the problem?
E.g., perhaps there's a wx function that returns 'true' if a wxString
contains any wide character:
bool CensusDocument::DoSaveDocument(wxString const& filename)
{
if(SomeFunctionWhoseNameIDoNotKnow(filename)) // PLEASE TELL ME THIS
SomeCodeToDisplayAnErrorMessage; // AND I'LL HANDLE THIS
std::ofstream ofs(filename.mb_str(), ios_out_trunc_binary());
This approach saves you the trouble of changing multiple files, and
lets me experiment with various ways of addressing the issue.
> GC> - For printing, we use apache 'fop', which seems to restrict us
> GC> to a subset of the ASCII filenames that msw would accept. See the
> GC> documentation for orthodox_filename() in lmi's 'path_utility.cpp',
> GC> or click here:
> GC>
> http://www.tt-solutions.com/vz/lmi/docs/path__utility_8cpp.html#a6a72c37f6e4f2b09366aa92a55d1e23a
>
> A very convenient link, thanks :-)
Thank *you*.
> Anyhow, I don't know about fop but I'm surprised it doesn't support
> Unicode.
It's conceivable that fop has full unicode support, yet disallows certain
ASCII characters. IIRC, we found that characters like '#' were unacceptable
to fop; instead of trying to find out exactly what its rules are, I made
orthodox_filename() arbitrarily restrictive.
> GC> - lmi's problem domain really is quite USA-specific because life
> GC> insurance is governed by national regulation. I doubt it would
> GC> be useful even in Canada. No end user has ever asked us to
> GC> support non-ASCII filenames.
>
> I still think it's not impossible that e.g. a native Spanish-speaker might
> be using LMI and want to use some non-ASCII name for the file. Of course,
That is important: many Americans speak Spanish, and AIUI Spanish is
an official language in Puerto Rico (whose insurance regulations are
similar to the states'). I believe we already support Spanish filenames
as well as English--this filename works just fine:
Hernán Cortés.ill
and so does even this:
¿¡ÁáÉéÍíÑñÓóÚúÜü!.ill
[Non-inverted question-mark '?' is forbidden by the operating system,
for English as well as any other language.]
So it looks like today we can accommodate any Spanish name--but not
El Greco's real name, or my Γιαγιά's, or any name that requires
non-Latin characters, as long as MinGW libstdc++ lacks std::wstream.
> GC> Can we make the diagnostics say something more than
> GC> Unable to save ''.
> GC> ? If not, then is there a way to constrain filenames to strings
> GC> that we can at least print in diagnostics?
>
> AFAICS the only way for a Unicode string to find it into LMI now is via
> the file selection dialog. Unfortunately LMI doesn't use this dialog itself
> but gets the file names from the docview framework. So this problem could
> be solved in two ways:
>
> 1. Straightforward but error-prone: find all places in the program where we
> use the file names and add checks for their ASCII-ness there. This is as
> simple as it gets but the problem could easily creep in if/when new code
> operating on file names is added.
We've identified three places in each of two files.
I think that's enough.
> 2. Elegant but more difficult:
[...code that would be...]
> removed all at once LMI ever does decide to support Unicode filenames).
I'm happy to support Unicode filenames once MinGW supports std::wstream.
> of course, I'd be interested in doing this according to the usual
> principle of "Why spend 15 minutes on doing this manually if you can
> spend 5 months on automating it". But this will clearly take more time.
It's not worth doing because we'd throw it away when we get std::wstream,
and there are other tasks more deserving of lavish attention.
- Re: [lmi] patch: compilation fix for wx 2.9, Greg Chicares, 2010/05/15
- Re: [lmi] patch: compilation fix for wx 2.9, Vaclav Slavik, 2010/05/15
- Re[2]: [lmi] patch: compilation fix for wx 2.9, Vadim Zeitlin, 2010/05/15
- [lmi] MinGW, wstring, and wstream [Was: patch: compilation fix for wx 2.9], Greg Chicares, 2010/05/15
- Re: [lmi] MinGW, wstring, and wstream [Was: patch: compilation fix for wx 2.9], Vadim Zeitlin, 2010/05/15
- Re: [lmi] MinGW, wstring, and wstream [Was: patch: compilation fix for wx 2.9], Greg Chicares, 2010/05/15
- Re[2]: [lmi] MinGW, wstring, and wstream [Was: patch: compilation fix for wx 2.9], Vadim Zeitlin, 2010/05/15
- Re: [lmi] patch: compilation fix for wx 2.9, Greg Chicares, 2010/05/15
Re[2]: [lmi] patch: compilation fix for wx 2.9, Vadim Zeitlin, 2010/05/15
- Re: [lmi] patch: compilation fix for wx 2.9,
Greg Chicares <=