Re: [lmi] patch: compilation fix for wx 2.9

[Greg Chicares]

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.