On Sunday, September 24, 2017 at 11:04:23 PM UTC+3, T. Modes wrote:
Am Sonntag, 24. September 2017 21:09:47 UTC+2 schrieb Guy Rutenberg:
>>
>> I'm using Debian 9, with the en_IL.utf8 locale.
>>
> More interesting would be the wxWidgets version and maybe wxWidgets
> configuration (e.g. it is compiled as Unicode version or is Unicode
> disabled).
>
> The steps I've taken to reproduce the bug are:
>> 1. Start a new project where the pto is in some non-ascii path and set
>> the output prefix to be in the same directory (with non-acii name).
>> 2. Attempt to stitch.
>> 3. hugin_stitch_project is executed and fails. I've attached the log it
>> shows.
>>
> By default the stitching processor is PTBatcherGUI and not
> hugin_stitch_project. So you have already changed some settings.
> But again it works fine here on Fedora. I can't reproduce it here.
> Here the output from strace:
> execve("/usr/local/bin/hugin_stitch_project", ["hugin_stitch_project",
> "--delete", "-o", "/home/xxx/\320\257\320...<snip>/pano",
> "/tmp/huginpto_v9oFXG"],
> You see the non-ascii name is correctly passed to hugin_stitch_project.
>
I've removed my ~/.hugin file and tried again and the bug persists. With
ascii-only characters
execve("/usr/bin/PTBatcherGUI", ["/usr/bin/PTBatcherGUI", "-b", "-v",
"/tmp/hugin/abcd/IMG_0421
- IMG_0421.pto", "/tmp/hugin/abcd/IMG_0421 - IMG_0421"],...
But with non-ascii
execve("/usr/bin/PTBatcherGUI", ["/usr/bin/PTBatcherGUI", "-b", "-v", "", ""
],...
and PTBatcherGUI gives "Could not open project file:/tmp/" when stitching.
> So this is not a principal bug, it seems to depend on a special
> configuration or an older wxWidgets version.
>
> PS: Information about wxWigets in Fedora
> wxWidgets Library (wxGTK port)
> Version 3.0.2 (Unicode: wchar_t, debug level: 1),
> compiled at Oct 5 2016 02:40:16
>
> Runtime version of toolkit used is 3.18.
> Compile-time GTK+ version is 3.18.9.
>
This might be the problem. The configuration on my part is
wxWidgets: wxWidgets 3.0.2
wxWidgets Library (wxGTK port)
Version 3.0.2 (Unicode: wchar_t, debug level: 1),
Runtime version of toolkit used is 2.24.
Compile-time GTK+ version is 2.24.31.
These are the default libraries when compiling in Debian Stretch. I'll try
to comile against more recent libraries to see if it persists.
Is there anybody else using Debian with the same libraries that doesn't
have this bug? If so it would help to rule out libraries version as the
problem.
On Monday, September 25, 2017 at 1:24:19 AM UTC+3, Bruno Postle wrote:
> Could this be a problem with right-to-left text? Do you see the same error
> with non-ascii European characters?: øéßæç…
This causes the bug as well.
On Monday, September 25, 2017 at 7:20:22 AM UTC+3, Gunter Königsmann wrote:
>
> I seem to remember that wxWidgets 3.1.x is much better in respect to
> uncode support. But as it is officially "development" it is not used
> everywhere...
>
> ...and the problem wxMaxima always has can be relevant here, too: what if
> wxWidgets uses Unicode, but the file system doesn't?
>
>
If it is indeed only solved in wxWidgets 3.1.x, I think it's better to
apply a workaround, as no linux distro uses wxWidgets 3.1.0, and it would
take years now for the bug to be actually fixed on users' machines.
Both wxWidgets and my file-system (ext4 with a utf8 locale) re unicode
aware.
Thanks,
Guy
--
A list of frequently asked questions is available at:
http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/hugin-ptx/2de8736e-c0a8-4db9-b723-391f57de1c4a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
