[Libreoffice-commits] core.git: vcl/unx

[Stephan Bergmann (via logerrit)]

 vcl/unx/gtk/fpicker/SalGtkPicker.cxx |   19 +++----------------
 1 file changed, 3 insertions(+), 16 deletions(-)

New commits:
commit 90e33df14a1bdff55c4759102658dba7510a733a
Author:     Stephan Bergmann <sbergman at redhat.com>
AuthorDate: Wed Aug 28 09:49:01 2019 +0200
Commit:     Stephan Bergmann <sbergman at redhat.com>
CommitDate: Wed Aug 28 10:59:56 2019 +0200

    Always using translateToInternal should be fine in SalGtkPicker::uritounicode
    
    When SalGtkPicker::uritounicode was originally introduced in
    27994c3831e55174af313e74e09905003ff34440 "INTEGRATION: CWS cmcfixes4: #i46017#
    to and from system locale encoding when url is file:///", it only contained the
    g_filename_from_uri code and no translateToInternal fallback (though the
    SalGtkPicker::unicodetouri counterpart, already introduced then, only used
    INetURLObject::getExternalURL, the precursor to today's translateToExternal,
    from the beginning).  The translateToInternal fallback was only added later
    with e68b4920b0a726578094013b819b1e0833929acb "INTEGRATION: CWS c07v007_SRC680:
     #b6465588# cope with URI encoded in non UTF8 encoding".
    
    But I see no reason to not always use just translateToInternal in uritounicode
    (matching the translateToExternal in unicodetouri).  Trying with both
    LC_ALL=en_US.UTF-8 and LC_ALL=en_US.ISO-8859-1 and the gtk3 VCL plugin (on
    GTK 3.24.10), the only difference between using the g_filename_from_uri and the
    translateToInternal code is that the former produces an IURI sURL where non-
    ASCII Unicode characters are written as such (later on in the LO code to be
    encoded as %XX...), whereas the latter produces an sURL where those non-ASCII
    Unicode characters are already encoded as %XX...
    
    One difference is for filenames containing bytes that cannot be represented in
    the current LC_CTYPE encoding.  g_filename_from_uri reports them as
    U+FFFD REPLACEMENT CHARACTER, so producing an IURI sURL containing "�" (that is
    later on in the LO code encoded as %EF%BF%BD), while translateToInternal keeps
    the single %XX representing the original byte intact.  (And even though LO can't
    properly handle such a file URL with non--UTF-8 payload, this change is a small-
    step win of keeping the URL at least intact and not garbling it completely with
    "�" aka %EF%BF%BD).
    
    Change-Id: If27fc64c75e986dbb467e147a7e43df3a01db640
    Reviewed-on: https://gerrit.libreoffice.org/78216
    Tested-by: Jenkins
    Reviewed-by: Stephan Bergmann <sbergman at redhat.com>

diff --git a/vcl/unx/gtk/fpicker/SalGtkPicker.cxx b/vcl/unx/gtk/fpicker/SalGtkPicker.cxx
index 01671fb1afc6..3e443ea04692 100644
--- a/vcl/unx/gtk/fpicker/SalGtkPicker.cxx
+++ b/vcl/unx/gtk/fpicker/SalGtkPicker.cxx
@@ -56,22 +56,9 @@ OUString SalGtkPicker::uritounicode(const gchar* pIn)
     {
         // all the URLs are handled by office in UTF-8
         // so the Gnome FP related URLs should be converted accordingly
-        gchar *pEncodedFileName = g_filename_from_uri(pIn, nullptr, nullptr);
-        if ( pEncodedFileName )
-        {
-            OUString sEncoded(pEncodedFileName, strlen(pEncodedFileName),
-                osl_getThreadTextEncoding());
-            g_free (pEncodedFileName);
-            INetURLObject aCurrentURL(sEncoded, FSysStyle::Unix);
-            aCurrentURL.SetHost(aURL.GetHost());
-            sURL = aCurrentURL.getExternalURL();
-        }
-        else
-        {
-            OUString aNewURL = uri::ExternalUriReferenceTranslator::create( m_xContext )->translateToInternal(sURL);
-            if( !aNewURL.isEmpty() )
-                sURL = aNewURL;
-        }
+        OUString aNewURL = uri::ExternalUriReferenceTranslator::create( m_xContext )->translateToInternal(sURL);
+        if( !aNewURL.isEmpty() )
+            sURL = aNewURL;
     }
     return sURL;
 }