SDK: LrStringUtils is broken (Windows)

[FSt0p]

Hi.

I'm writing Ligtroom plugin, and faced the fact that at least LrStringUtils.upper() and LrStringUtils.lower() doesn't work as expected.

For example for LrStringUtils.upper() documentation says:

Converts a string to uppercase using the operating system's localized case conversion. Unlike the Lua string.upper function, this function properly converts characters outside the 7-bit ASCII space.

In practice: it's not any different from the string.upper() - only characters a-z are properly converted to uppercase.

Here is my test code:

local LrDialogs=import("LrDialogs")
local LrStringUtils=import("LrStringUtils")
local s1=tostring(LrStringUtils.upper("ТеСт-TeSt-óó"))
local s2=tostring(LrStringUtils.upper("тЕсТ-tEsT-óó"))
LrDialogs.message(s1..", "..s2..", "..tostring(s1==s2))

The result is

ТеСт-TEST-óó, тЕсТ-TEST-óó, false

As you can see - only latin characters were converted to uppercase.

Tested under Lightroom Classic v12.1, running on Windows 10 x64 22H2

I can't believe such a thing left unnoticed for so long.

So maybe it's just me missing something...

Can someone test this and confirm?

If this is indeed bug - what's the best way to workaround?

Basically I need to compare file system paths in a case-insensitive manner, and can't find a (working) way to do so without calling external utilities via LrTasks.execute()...

[John R Ellis]

It appears to be a Windows-only bug.  On Mac LrStringUtils returns the correct result:

but on Windows it doesn't convert the case of the Cyrillic letters:

[John R Ellis]

@Rikk Flohr: Photography, please move to Bugs.

[FSt0p]

but on Windows it doesn't convert the case of the Cyrillic letters:

By @John R Ellis

Actually, it doesn't convert anything apart from Latin latters, not only Cyrillic.

Don't know if this can be fixed thouth - seems to be system or runtime (CRT) related.

I tried to create simple test app in C for case conversion which just calls couple of CRT functions, and behaviour is the same - only Latin letters are converted if I specify UTF8 locale.

For CP1251 codepage for example conversion works...

[FSt0p]

One more question - maybe someone can help.

Is it possible to write native library (*.dll or *.so) and load it using require() from LrC plugin?
I know how it should be done from LUA point of view, the question here is it allowed in Lightroom environment or not?

[John R Ellis]

"Don't know if this can be fixed thouth - seems to be system or runtime (CRT) related."

Adobe can surely fix it by invoking a correctly implemented Unicode library. 

For your immediate needs, you could look for a pure-Lua Unicode library.  A quick Google search suggests there are lots of reinventing-the-wheel packages available:

http://lua-users.org/wiki/LuaUnicode

Many of the links on that page are dead, but I did find this:

https://github.com/Stepets/utf8.lua 

which appears to provide optional pure-Lua lower() and upper(), using this module:

https://github.com/artemshein/luv/blob/master/utf8data.lua 

A quick skim suggests it won't be entirely correct for languages in which there isn't a one-to-one mapping between upper- and lower-case, but it's probably good enough for the most common languages used with LR.   I have no idea how well it works.

[John R Ellis]

"Is it possible to write native library (*.dll or *.so) and load it using require() from LrC plugin?
I know how it should be done from LUA point of view, the question here is it allowed in Lightroom environment or not?"

The standard Lua method isn't supported for LR plugins. There is an undocumented method _PLUGIN:nativeFunction() that no one has published how to use:

https://community.adobe.com/t5/lightroom-classic-discussions/lr-5-functions-methods-and-properties-n...

[FSt0p]

Thanks a lot, I really appreciate this - it's very helpfull.

As for my tests - the issue seems to be with C runtime (CRT).

Not sure when it was improved, but my sample code compiled with Visual Sudio 2010 gives wrong results (same as LrC), and exactly same code built with Visual Studio 2019 works correctly.

My test code is:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <locale.h>
#include <mbstring.h>

wchar_t *MultibyteToWidechar(char *mbstr)
{
    wchar_t *wcstr=NULL;
    int count=(int)mbstowcs(NULL, mbstr, 0);
    if(count<=0) return NULL;
    wcstr=malloc((count+1)*sizeof(wchar_t));
    if(wcstr)
    {
        mbstowcs(wcstr, mbstr, count);
        wcstr[count]=0;
    }
    return wcstr;
}

int main(int argc, char *argv[])
{
    wchar_t *wcstr=NULL;
    char str1[]="ТеСт-TeSt-óó";
    char str2[]="тЕсТ-tEsT-óó";

    setlocale(LC_ALL, ".UTF8");

    wcstr=MultibyteToWidechar(str1);
    printf("%S -> ", wcstr);
    _wcsupr(wcstr);
    printf("%S\n", wcstr);
    free(wcstr);

    wcstr=MultibyteToWidechar(str2);
    printf("%S -> ", wcstr);
    _wcsupr(wcstr);
    printf("%S\n", wcstr);
    free(wcstr);

    return 0;
}

[FSt0p]

Thanks, lack of documentation is not a big issue - I use debugger in such cases 🙂

[Rikk Flohr: Photography]

Adding bug number - setting status