• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
1

SDK: LrStringUtils is broken (Windows)

Enthusiast ,
Jan 11, 2023 Jan 11, 2023

Copy link to clipboard

Copied

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()...

Bug Investigating
TOPICS
SDK , Windows

Views

344

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines

correct answers 1 Pinned Reply

Adobe Employee , Jan 12, 2023 Jan 12, 2023

Adding bug number - setting status

Status Investigating

Votes

Translate

Translate
9 Comments
LEGEND ,
Jan 11, 2023 Jan 11, 2023

Copy link to clipboard

Copied

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

 

johnrellis_0-1673478588873.png

 

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

 

johnrellis_1-1673478643197.png

 

Votes

Translate

Translate

Report

Report
LEGEND ,
Jan 11, 2023 Jan 11, 2023

Copy link to clipboard

Copied

@Rikk Flohr: Photography, please move to Bugs.

Votes

Translate

Translate

Report

Report
Enthusiast ,
Jan 11, 2023 Jan 11, 2023

Copy link to clipboard

Copied

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

By @johnrellis

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...

Votes

Translate

Translate

Report

Report
Enthusiast ,
Jan 11, 2023 Jan 11, 2023

Copy link to clipboard

Copied

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?

Votes

Translate

Translate

Report

Report
LEGEND ,
Jan 11, 2023 Jan 11, 2023

Copy link to clipboard

Copied

"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.

 

 

Votes

Translate

Translate

Report

Report
LEGEND ,
Jan 11, 2023 Jan 11, 2023

Copy link to clipboard

Copied

"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...

Votes

Translate

Translate

Report

Report
Enthusiast ,
Jan 11, 2023 Jan 11, 2023

Copy link to clipboard

Copied

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;
}

 

Votes

Translate

Translate

Report

Report
Enthusiast ,
Jan 11, 2023 Jan 11, 2023

Copy link to clipboard

Copied

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

Votes

Translate

Translate

Report

Report
Adobe Employee ,
Jan 12, 2023 Jan 12, 2023

Copy link to clipboard

Copied

LATEST

Adding bug number - setting status

Rikk Flohr - Customer Advocacy: Adobe Photography Products
Status Investigating

Votes

Translate

Translate

Report

Report