Bug reports (Korean character, non-English)

fullchan7 commented 1 year ago

Hi I really love this program and thank you for making Klayout.

I'm using Mac version of this. (I recently switched from the windows version).

An error message was popped up when I try to load a gds file in the folder with its name in Korean.

It will be great if this can be fixed.

Thank you again for this nice app.

Kazzz-S commented 1 year ago

Edited: To take up an example from the KLayout source. ==> Issue-1213.zip

Thank you for your report.

In my observations, this problem occurs only if:

a design file (like *.gds) is chosen via the file selection dialog window AND
the full path of the design file contains non-ASCII characters like Korean, Japanese, etc.

However, if KLayout is invoked from a terminal, it can open such files.

Non-ASCII characters exist only in the directory name

MacBookPro2{sekigawa} 韓国+日本+かんこく+にっぽん (1)% which klayout
klayout: aliased to /Applications/klayout-HB.app/Contents/MacOS/klayout

MacBookPro2{sekigawa} 韓国+日本+かんこく+にっぽん (2)% klayout RingOsc.gds
or
MacBookPro2{sekigawa} ~ (3)% open -a klayout-HB.app ~/zzz/韓国+日本+かんこく+にっぽん/RingOsc.gds

Non-ASCII characters exist in the file name (don't care about the directory name)

MacBookPro2{sekigawa} 韓国+日本+かんこく+にっぽん (1)% which klayout
klayout: aliased to /Applications/klayout-HB.app/Contents/MacOS/klayout

MacBookPro2{sekigawa} 韓国+日本+かんこく+にっぽん (2)% klayout リング発振器.gds
or
MacBookPro2{sekigawa} ~ (3)% open -a klayout-HB.app ~/zzz/韓国+日本+かんこく+にっぽん/リング発振器.gds
or
MacBookPro2{sekigawa} ~ (4)% open -a klayout-HB.app ~/zzz/xxx/リング発振器.gds

Kazzz-S

fullchan7 commented 1 year ago

Thanks for the reply

You mean that I should type commands in terminal app for every time to load gds files?

Kazzz-S commented 1 year ago

I believe this is a macOS-specific issue that needs to be fixed. My suggestion is a workaround for the time being if it works for you. Another option is, of course, changing the directory and file name using ASCII characters only.

Kazzz-S

fullchan7 commented 1 year ago

I hope this will be fixed. T.T

Thank you again.

Yeah I changed the folder names in English but I prefer Korean HAHA...

Maybe I should go back to windows T_T.. and blame APPLE

klayoutmatthias commented 1 year ago

I just tried with Linux (Ubuntu 22.04 in my case) and it seems to work.

I got a file with called "~/klayout/testdata/韓国+日本+かんこく+にっぽん/ringo.gds" (I understand that means "Korea + Japan + Kankoku + Nippon" :) ). That works on command line, "File/Open" and also from the MRU list.

Same for a file called "~/klayout/testdata/韓国+日本+かんこく+にっぽん.gds".

So I also assume the problem is MacOS specific. Or rather Qt specific :(

My personal recommendation is to switch to Linux :)

Matthias

Kazzz-S commented 1 year ago

Hi @fullchan7 and @klayoutmatthias,

I believe I found the root cause: this issue is not a bug of the core KLayout but insufficient localization info provided in making the DMGs for macOS.
Looking into the experiment results above, I have also found a simple solution: writing a wrapper shell script where we set the LANG environment variable.
This approach may not be the best (and not the last: I need to study more), but let me show you my attempts.

1. Start the Automator tool Automator-1

2. Select Application Automator-2

3. Select Run Shell Script Automator-3

4. Choose a shell (Bash here) and set how to treat the arguments Automator-4

5. Write the Bash script: the core part is (1) export LANG=... and (2) open -a ... Automator-5

#=======================================================================================
# Bundle: KLayout-HB-Starter.app
#
# Author: Kazzz-S
# Last modified: 2022-12-10
#
# Aims:
#   To provide the contents of a script bundle to address the issue discussed in:
#      https://github.com/KLayout/klayout/issues/1213
#
# The author has:
#   [A] installed a Homebrew development environment, including
#          1) qt@5, 2) ruby@3, and 3) python@3.8
#
#   [B] installed "LW-klayout-0.27.13-macOS-Monterey-1-qt5Brew-Rhb31Phb38.dmg"
#          as "/Applications/klayout.app"
#          and he can start the KLayout application normally.
#
#   [C] renamed the application bundle to "/Applications/klayout-HB.app"
#       to imply that it uses the "Homebrew" environment.
#=======================================================================================

#------------------------------------------------------------------------
# Detect and set the language
#------------------------------------------------------------------------
export LANG=$(defaults read -g AppleLocale).UTF-8
#export LANG=ko_KR.UTF-8 # Korean
#export LANG=ja_JP.UTF-8 # Japanese

#------------------------------------------------------------------------
# If you keep the original application name "klayout.app" unchanged,
# modified the lines below accordingly.
#------------------------------------------------------------------------
myklayout=/Applications/klayout-HB.app
myconfig=$HOME/.klayout/klayoutrc-HB

#------------------------------------------------------------------------
# Start the KLayout application.
# With "-n" option, you can invoke multiple instances.
#------------------------------------------------------------------------
open -n -a $myklayout --args -e -c $myconfig -style=fusion $@

# EOF

6. Save the application bundle Automator-6

7. A new application is ready

You can change the application icon, as shown in the image if you like.
Customized icon files are available here.

8. Start KLayout by double-clicking the icon, then open input files via the system file dialog

Let's open two files at the same time.

9. Done! Automator-9

Kazzz-S

fullchan7 commented 1 year ago

Thank you for the new idea.

I guess if there is a config file, we might set the locale(?) to JP, CN, or KR

Kazzz-S commented 11 months ago

Hi @fullchan7 and @klayoutmatthias,

I believe I found the root cause: this issue is not a bug of the core KLayout but insufficient localization info provided in making the DMGs for macOS.

Looking into the experiment results above, I have also found a simple solution: writing a wrapper shell script where we set the LANG environment variable.

This approach may not be the best (and not the last: I need to study more), but let me show you my attempts.

I have found a solution that can coexist with the wrapper approach I proposed. I can include the changes in the next maintenance release (0.28.13?).

Kazzz-S

fullchan7 commented 11 months ago

Dear Mr. Kazunari Sekigawa

Thank you for your efforts to solve this problem.

I have no idea about what you say because I’m not the programming/coding guy, just drawing simple layouts for research.

But I’m glad that you have made a progress.

Thank you again.

Best regards.

오전 6:56, Kazunari Sekigawa @.***> 작성:

Hi @fullchan7 https://github.com/fullchan7 and @klayoutmatthias https://github.com/klayoutmatthias,

I believe I found the root cause: this issue is not a bug of the core KLayout but insufficient localization info provided in making the DMGs for macOS. Looking into the experiment results above, I have also found a simple solution: writing a wrapper shell script where we set the LANG environment variable. This approach may not be the best (and not the last: I need to study more), but let me show you my attempts. I have found a solution that can coexist with the wrapper approach I proposed. I can include the changes in the next maintenance release (0.28.13?).

Kazzz-S

— Reply to this email directly, view it on GitHub https://github.com/KLayout/klayout/issues/1213#issuecomment-1789746928, or unsubscribe https://github.com/notifications/unsubscribe-auth/A4S74FLKUONM6XLOQJFCGNDYCLASFAVCNFSM6AAAAAASVIY2OKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBZG42DMOJSHA. You are receiving this because you were mentioned.

klayoutmatthias commented 11 months ago

Hi @Kazzz-S,

Thank you for taking care of this. I will release 0.28.13 soon.

Here is some heads-up: because of https://github.com/KLayout/klayout/issues/1514, I am integrating a Git client into KLayout. This requires libgit2 as a dependency. This library is quite popular, so I think it is available on MacOS. The version is not important - I tested from 0.24 to 1.7 myself.

It is basically possible to disable libgit2 during the build, but I don't recommend so as finally people will not be able to install packages from Git-hosted repositories in the future.

Thank you and best regards,

Matthias

Kazzz-S commented 11 months ago

Hi @klayoutmatthias,

Thanks for the heads-up. I have checked the availability of libgit2 in various development environments, as shown below.

Dev. Env.	URL	libgit2 version
Homebrew	https://formulae.brew.sh/formula/libgit2	1.7.1
MacPorts	https://ports.macports.org/port/libgit2/	1.7.1
Anaconda3	https://anaconda.org/conda-forge/libgit2	1.7.1

I will install them for the next maintenance release (0.28.13) build.

Warm regards, Kazzz-S

EDIT: [Installed to Monterery]

Homebrew

MacBookPro2{kazzz-s} opt (1)% pwd
MacBookPro2{kazzz-s} opt (1)% pwd
/usr/local/lib

MacBookPro2{kazzz-s} opt (2)% ll | grep libgit
lrwxr-xr-x   1 kazzz-s admin     47 11  3 06:55 libgit2.1.7.1.dylib -> ../Cellar/libgit2/1.7.1/lib/libgit2.1.7.1.dylib
lrwxr-xr-x   1 kazzz-s admin     45 11  3 06:55 libgit2.1.7.dylib -> ../Cellar/libgit2/1.7.1/lib/libgit2.1.7.dylib
lrwxr-xr-x   1 kazzz-s admin     37 11  3 06:55 libgit2.a -> ../Cellar/libgit2/1.7.1/lib/libgit2.a
lrwxr-xr-x   1 kazzz-s admin     41 11  3 06:55 libgit2.dylib -> ../Cellar/libgit2/1.7.1/lib/libgit2.dylib

MacBookPro2{kazzz-s} opt (2)% ll | grep libgit
lrwxr-xr-x   1 kazzz-s admin   23 11  3 06:55 libgit2 -> ../Cellar/libgit2/1.7.1
lrwxr-xr-x   1 kazzz-s admin   23 11  3 06:55 libgit2@1.7 -> ../Cellar/libgit2/1.7.1

MacPorts

MacBookPro2{kazzz-s} lib (1)% pwd
/opt/local/lib

MacBookPro2{kazzz-s} lib (2)% ll | grep libgit
-rwxr-xr-x    1 root     wheel   1407704  9 11 07:04 libgit2.1.7.1.dylib
lrwxr-xr-x    1 root     wheel        19  9 11 07:05 libgit2.1.7.dylib -> libgit2.1.7.1.dylib
lrwxr-xr-x    1 root     wheel        17  9 11 07:05 libgit2.dylib -> libgit2.1.7.dylib

Anaconda3 2023-11-10: updated by

conda update -c conda-forge libgit2

(base) MacBookPro2{kazzz-s} lib (1)% pwd
/Applications/anaconda3/lib

(base) MacBookPro2{kazzz-s} lib (2)% ll | grep libgit
-rwxr-xr-x    2 kazzz-s staff   1172776  8 15 08:33 libgit2.1.7.1.dylib
lrwxr-xr-x    1 kazzz-s staff        19 11 10 18:38 libgit2.1.7.dylib -> libgit2.1.7.1.dylib
lrwxr-xr-x    1 kazzz-s staff        19 11 10 18:38 libgit2.dylib -> libgit2.1.7.1.dylib

Kazzz-S commented 11 months ago

Hi @fullchan7 and @klayoutmatthias,

I believe I found the root cause: this issue is not a bug of the core KLayout but insufficient localization info provided in making the DMGs for macOS.

Looking into the experiment results above, I have also found a simple solution: writing a wrapper shell script where we set the LANG environment variable.

This approach may not be the best (and not the last: I need to study more), but let me show you my attempts.

I have found a solution that can coexist with the wrapper approach I proposed. I can include the changes in the next maintenance release (0.28.13?).

The solution I found is to set the LANG environment variable at the beginning of the klayout_main() function, as shown in the code fragments below.

<klayout_main/klayout.cc>
/**
 *  @brief The basic entry point
 *  Note that by definition, klayout_main receives arguments in UTF-8
 */
int
klayout_main (int &argc, char **argv)
{
#if defined(__APPLE__)
  // detect and set the LANG environment variable on the Mac
  int retA = getsetMacLANG();
  if (! retA == 0) {
      return retA;
  }
#endif

  //  install the version strings
  lay::Version::set_exe_name (prg_exe_name);
  lay::Version::set_name (prg_name);
  lay::Version::set_version (prg_version);
:
:

The getsetMacLANG() function and some support functions are defined in macLangSettings.cc (C++) and macUserPreferredLanguage.mm (Objective-C++). Of course, kalyout_main.pro has also been modified.

I found that this idea worked well in Monterey. So I tested the modified code in Ventura and Sonoma with glee, but no luck!!!

It looks like there are some security issues in the legacy coding style. ChatGPT instructs as follows.

ChatGPT:

In macOS Ventura and Sonoma, there have been changes in how environment variables like LANG are managed for applications. If using setenv for LANG is not working as expected, you can try the following approach to ensure that the LANG environment variable is correctly set:

1. Use Launch Services: In Ventura and Sonoma, you can set environment variables at the time of launching your application using Launch Services. This method should help ensure that the LANG environment variable is set correctly.

To do this, you can create a shell script that sets the LANG variable and then launches your application. Here's an example of how to create such a script:

bash

#!/bin/bash
export LANG=ja_JP.UTF-8
/path/to/YourApplication.app/Contents/MacOS/YourApplication

Make sure to replace /path/to/YourApplication.app with the actual path to your application.

2. Info.plist Modification: Another approach is to modify your application's Info.plist file to include environment variables. This method may require adding the following keys to your Info.plist file:

xml

<key>LSEnvironment</key>
<dict>
    <key>LANG</key>
    <string>ja_JP.UTF-8</string>
</dict>

Ensure that this modification is done properly in your .app bundle's Info.plist file.

3. Launchctl Method: If you are working with command-line applications, you can set environment variables using launchctl. Create a .plist file to set environment variables and load it using launchctl. Here's an example:

Create a .plist file (e.g., com.example.yourapp.plist) with the following content:

xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.example.yourapp</string>
    <key>ProgramArguments</key>
    <array>
        <string>sh</string>
        <string>-c</string>
        <string>LANG=ja_JP.UTF-8 /path/to/your/app</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
</dict>
</plist>

Then, load it using launchctl:

bash

launchctl load com.example.yourapp.plist

Make sure to replace /path/to/your/app with the actual path to your application.

By using one of these methods, you should be able to set the LANG environment variable for your application in macOS Ventura and Sonoma. These changes may require some adjustment in your application's deployment and distribution process to ensure that the environment variables are set correctly.

The 1st approach is precisely the same as I suggested above. It is also the simplest. I have confirmed that the 1st approach works universally in Monterey, Ventura and Sonoma.

So I should not consider patching <klayout_main/klayout.cc> as above.

Best regards, Kazzz-S

lighteningq commented 9 months ago

Hey! I am installing Klayout in centos 7 (Amazon EC2 Linux 2) machine through CLI and running into some errors when running the ./build.sh Apparently sudo yum install libgit2-devel is not available in the OS and yum is not able to get me installed

I got this error after installing libgit2 manually using solution suggested above

conda update -c conda-forge libgit2

But I still get this error, any ideas?

../../../src/tl/tl/tlGit.cc: In function ‘int tl::credentials_cb(git_credential**, const char*, const char*, unsigned int, void*)’:
../../../src/tl/tl/tlGit.cc:265:3: error: ‘git_error_set_str’ was not declared in this scope
   git_error_set_str (GIT_ERROR_NONE, "anonymous access is supported only, but server requests credentials");
   ^~~~~~~~~~~~~~~~~
../../../src/tl/tl/tlGit.cc:265:3: note: suggested alternative: ‘giterr_set_str’
   git_error_set_str (GIT_ERROR_NONE, "anonymous access is supported only, but server requests credentials");
   ^~~~~~~~~~~~~~~~~
   giterr_set_str
../../../src/tl/tl/tlGit.cc: In member function ‘void tl::GitObject::read(const string&, const string&, const string&, const string&, double, tl::InputHttpStreamCallback*)’:
../../../src/tl/tl/tlGit.cc:274:141: warning: unused parameter ‘timeout’ [-Wunused-parameter]
 :string &org_url, const std::string &org_filter, const std::string &subfolder, const std::string &branch, double timeout, tl::InputHttpStreamCallback *callback)
                                                                                                                  ^~~~~~~
../../../src/tl/tl/tlGit.cc:274:179: warning: unused parameter ‘callback’ [-Wunused-parameter]
 &org_filter, const std::string &subfolder, const std::string &branch, double timeout, tl::InputHttpStreamCallback *callback)
                                                                                                                    ^~~~~~~~
gmake[2]: *** [tlGit.o] Error 1
gmake[2]: Leaving directory `/local/home/jingwq/cqc/klayout/klayout/build-release/tl/tl'
gmake[1]: *** [sub-tl-make_default] Error 2
gmake[1]: Leaving directory `/local/home/jingwq/cqc/klayout/klayout/build-release/tl'
gmake: *** [sub-tl-make_default] Error 2

Kazzz-S commented 9 months ago

Hi,

You can build libgit2 from its source: https://github.com/libgit2/libgit2 using CMake. To use a relatively newer, but not the latest version of libgit2 on Linux Mint 20.3, I built it from the tag v1.7.1. libgit2 If I remember correctly, I got similar compile errors when using the latest (HEAD) version (v1.8?), where some function names seem to be changed.

Mint20{Kazzz-S}(1)$ ldd klayout | grep libgit
    libgit2.so.1.7 => /usr/local/lib/libgit2.so.1.7 (0x000014a4ad520000)

Maybe it is better to uninstall the conda version to avoid conflict.

klayoutmatthias commented 9 months ago

@lighteningq I don't know why libgit2-devel can't be installed for you. I have no trouble installing it on the "centos:7" docker image using

yum -y update
yum -y install libgit2-devel

I have not experience with EC instances however.

Matthias

KLayout / klayout

Bug reports (Korean character, non-English) #1213

Non-ASCII characters exist only in the directory name

Non-ASCII characters exist in the file name (don't care about the directory name)