이 노트북에는 CPU로 8코어 16쓰레드의 AMD Ryzen Renoir 4800H를 사용하였고, GPU로는 Nvidia GTX 1650 Ti를 사용하여 CUDA연산을 할 수 있습니다.
이번에 재택근무 이슈가 있다보니, 노트북을 뭘로 살까 고민하다 CPU 성능이 우수하면서 GPU가 들어간 노트북을 사용해보게되었습니다! 원래는 이 모델보다 GPU상위 모델(Nvidia RTX 2060)이 달린 TFG7476H를 사용하려고 했으나, 이미 인기가 많아 매진되어 구매 수령을 하려면 9월말까지 기다려야 한다고 하였습니다. 그래서 급하게 필요한지라 얼른 구할 수 있는 TFG7475H(GTX 1650Ti)를 구입하였습니다.
TFG7475H에 오픈수세(openSUSE) 리눅스와 KDE Plasma를 설치 하였습니다. 시스템 정보를 보니 CPU: AMD Ryzen 7 4800H와 GPU: GTX 1650 Ti가 보임을 확인할 수 있습니다.
아래는 오픈수세(openSUSE) 리눅스 설치 화면입니다.
설치가 완료되었습니다.
처음에, 리눅스 설치를 해보니 노트북 LCD엔 출력이 제대로 동작하니, 정상적으로 설치했다 좋아했습니다. 그러나, HDMI로 24인치 모니터를 노트북에 연결해보니 외장모니터 연결은 안되는 문제가 있습니다.
그래서, Nvidia 드라이버를 설치 후, openSUSE의 SUSE Prime 설치해야 노트북 내장 화면(LCD)및 외장화면 (HDMI, miniDP)동시 출력이 가능합니다.(Nvidia 모듈 설치후에 외장모니터만 화면 출력되고, 노트북 LCD가 안나오는 현상 겪으면 멘붕합니다 ㅋㅋㅋㅋㅋㅋㅋ ㅠㅠㅠㅠ )
libcudnn8-8.0.3.33-1.cuda11.0.x86_64.rpm와 libcudnn8-devel-8.0.3.33-1.cuda11.0.x86_64.rpm, nvidia-machine-learning-repo-rhel8-1.0.0-1.x86_64.rpm를 다운로드 받아서 설치하였습니다.
$ sudo zypper in libcudnn8-8.0.3.33-1.cuda11.0.x86_64.rpm libcudnn8-devel-8.0.3.33-1.cuda11.0.x86_64.rpm nvidia-machine-learning-repo-rhel8-1.0.0-1.x86_64.rpm
이후 pip으로 tensorflow-gpu를 설치해봅니다.
$ pip3 install tensorflow tensorflow-gpu
라이브러리 설치가 되었으면, 두근두근
tensorflow에서 Nvidia GPU연동이 잘 되는지 테스트를 해봅니다
$ python3 -c 'import tensorflow as tf; print(tf.__version__)'
2020-09-12 03:28:30.666780: W tensorflow/stream_executor/platform/default/dso_loader.cc:59] Could not load dynamic library 'libcudart.so.10.1'; dlerror: libcudart.so.10.1: cannot open shared object file: No such file or directory
2020-09-12 03:28:30.666814: I tensorflow/stream_executor/cuda/cudart_stub.cc:29] Ignore above cudart dlerror if you do not have a GPU set up on your machine.
2.3.0
아, Python의 tensorflow-gpu는 CUDA 10.1 버전을 사용하고 있더군요. CUDA 동적 라이브러리 10.1 버전이 없어서 에러가 났습니다.
이번에, AMD Ryzen기반 8 코어 16 스레드 지원 CPU 4800H와 Nvidia GTX1650 Ti가 들어간 새로운 17.3인치 랩탑(한성컴퓨터 TFG7475H)을 저렴하게 구입 후, 기본 OS를 openSUSE로 설치하여 사용하고 있습니다.
남들 많이 사용하는 리눅스 배포판(Linux Distribution)인 우분투(Ubuntu), 데비안(Debian)이나 RPM계열인 페도라(Fedora)대신 오픈수세(openSUSE)를 사용하는 관계로, 남들보다 삽질을 더 하는 듯함. (다행히, 우분투와 다르게 오픈수세는 Nvidia 드라이버를 빨리 설치하는 듯)
한글과컴퓨터에서 공개한 리눅스용 HWP뷰어의 리눅스용 설치 파일은 페도라(Fedora) 기반의 rpm파일이나 우분투(Ubuntu) 기반인 deb파일로 제공하고 있습니다.
그러나, 당연 오픈수세(openSUSE)용은 한국 사람들이 많이 사용하는 배포판이 아니니, 한글과컴퓨터에서 오픈수세(openSUSE)용을 내놓을 리는 없습니다. 그래서, 오픈수세(openSUSE)와 그나마 친척관계(?)인 페도라 코어(Fedora Core)용 설치파일(rpm)파일을 다운로드 받았습니다.
이제 Fedora용 설치 파일인 RPM파일을 다운로드하면, 설치를 해보죠.
$ rpm -ivh hancomoffice-hwpviewer-Fedora.x86_64.rpm
오류: Failed dependencies:
libjavascriptcoregtk-3.0.so.0()(64bit) is needed by hancomoffice-hwpviewer-9.20.0.1575-1.x86_64
libwebkitgtk-3.0.so.0()(64bit) is needed by hancomoffice-hwpviewer-9.20.0.1575-1.x86_64
webkitgtk3 >= 1.3.3 is needed by hancomoffice-hwpviewer-9.20.0.1575-1.x86_64
이... RPM의존성 있다고 설치 에러를 뱉습니다. 그럼, 오픈수세(openSUSE)에서 한글(HWP)뷰어 설치를 못하나??? ㅠㅠㅠㅠ
자 각설하고, 오픈수세(openSUSE)에서 어떻게 한글(HWP) 뷰어를 설치해야 하나?
결론을 말하자면, zypper명령어의 옵션을 줘서, 패키지 종속성 확인하면서 강제로 설치하면 됩니다.
$ sudo zypper in hancomoffice-hwpviewer-Fedora.x86_64.rpm
'packman' 리포지토리 메타 데이터를 검색하는 중 .....................................[완료]
리포지토리 'packman' 캐시 빌드 중 ..................................................[완료]
리포지토리 데이터 로드 중...
설치된 패키지를 읽는 중...
패키지 종속성 확인 중...
문제: webkitgtk3 >= 1.3.3(hancomoffice-hwpviewer-9.20.0.1575-1.x86_64에서 필요)이(가) 제공되지 않습니다.
솔루션 1: hancomoffice-hwpviewer-9.20.0.1575-1.x86_64 설치 안 함
솔루션 2: 일부 종속성을 무시하여 hancomoffice-hwpviewer-9.20.0.1575-1.x86_64을(를) 구분합니다.
위의 제안으로부터 하나를 선택하거나 취소 [1/2/c/d/?] (c): 2
종속성을 확인하는 중...
패키지 종속성 확인 중...
다음 새 패키지가 설치됩니다.
hancomoffice-hwpviewer
1 새로운 꾸러미로 설치.
전체 다운로드 크기: 94.2 MiB. 이미 캐싱됨: 0 B. 작업 후에 211.3 MiB이(가) 추가로
사용됩니다.
계속하시겠습니까? [예/아니오/버전/...? 모든 옵션 표시] (예):
꾸러미 hancomoffice-hwpviewer-9.20.0.1575-1.x86_64 검색 중
(1/1), 94.2 MiB (211.3 MiB 압축 풀기)
hancomoffice-hwpviewer-Fedora.x86_64.rpm:
패키지가 서명되지 않았습니다!
hancomoffice-hwpviewer-9.20.0.1575-1.x86_64 (일반 RPM 파일 캐시): 서명 확인 실패 [6-파일이 서명되지 않음]
중단, 재시도 또는 무시하시겠습니까? [a/r/i] (a): i
파일 충돌 확인: ....................................................................[완료]
(1/1) 설치 중: hancomoffice-hwpviewer-9.20.0.1575-1.x86_64 .........................[완료]
%posttrans 스크립트 실행 중 ........................................................[완료]
$
설치가 완료 후, 한글(HWP) 뷰어를 실행하면 아래와 같이 나옵니다.
즉, 한글(HWP) 뷰어는 우분투(Ubuntu), 데비안(Debian)등의 deb기반의 배포판이나, 오픈수세(openSUSE), 페도라 코어(Fedore Core), 센트오에스(CentOS)등의 RPM기반의 배포판이나 현재의 배포판에서 설치 시 의존성 문제가 있으나, dpkg나 rpm으로 강제로 옵션 줘서 설치하거나, 배포판에서 의존성 관련으로 설치를 도와주는 명령어 입력하여 설치할 수 있습니다.
# zypper se x11-video-nvidiaG0*
Retrieving repository 'NVIDIA' metadata --------------------------------------------------------------------------------------------------------------------------[|]
New repository or package signing key received:
Repository: NVIDIA
Key Name: NVIDIA Corporation <linux-bugs@nvidia.com>
Key Fingerprint: 9B763D49 D8A5C892 FC178BAC F5113243 C66B6EAE
Key Created: Fri Jun 16 01:13:18 2006
Key Expires: (does not expire)
Subkey: F016EEAA03224CDD 2006-06-16 [does not expire]
Rpm Name: gpg-pubkey-c66b6eae-4491871e
Do you want to reject the key, trust temporarily, or trust always? [r/t/a/?] (r): a
Retrieving repository 'NVIDIA' metadata .......................................................................................................................[done]
Building repository 'NVIDIA' cache ............................................................................................................................[done]
Loading repository data...
Reading installed packages...
S | Name | Summary | Type
--+---------------------+---------------------------------------------------------+--------
| x11-video-nvidiaG04 | NVIDIA graphics driver for GeForce 400 series and newer | package
| x11-video-nvidiaG05 | NVIDIA graphics driver for GeForce 600 series and newer | package
이제, Nvidia 드라이버 패키지를 설치합니다.
# zypper in x11-video-nvidiaG04
Loading repository data...
Reading installed packages...
Resolving package dependencies...
The following 13 NEW packages are going to be installed:
Mesa-libGLESv1_CM1 Mesa-libGLESv2-2 libX11-6-32bit libXau6-32bit libXext6-32bit libglvnd-32bit libxcb1-32bit nvidia-computeG04 nvidia-gfxG04-kmp-default
nvidia-glG04 plasma5-applet-suse-prime suse-prime x11-video-nvidiaG04
The following 4 recommended packages were automatically selected:
Mesa-libGLESv1_CM1 Mesa-libGLESv2-2 nvidia-glG04 x11-video-nvidiaG04
13 new packages to install.
Overall download size: 79.2 MiB. Already cached: 0 B. After the operation, additional 366.0 MiB will be used.
Continue? [y/n/v/...? shows all options] (y): y
Do you agree with the terms of the license? [yes/no] (no): yes
설치가 완료되었으면 재부팅 합니다.
재부팅 후에도 Intel 그래픽카드로 사용되는걸 확인할 수 있습니다. openSUSE에서 Nvidia 그래픽카드 사용 활성화를 하려면 아래의 명령어로 활성화합니다
$ sudo prime-select nvidia
Logout to switch graphics
위의 내용처럼 로그아웃을 하고 난 후 새로 로그인 하면 변경되는 걸 확인할 수 있습니다.
ps. 이제 이 노트북으로 Nvidia GPU를 이용한 AI연산, 딥러닝을 사용할수 있다.
/home/dhsung/Projects/gnome-hello/configure: line 11964: syntax error near unexpected token `maximum'
/home/dhsung/Projects/gnome-hello/configure: line 11964: `GNOME_COMPILE_WARNINGS(maximum)'
위의 메세지를 띄우며 빌드가 안될때 해결책. 'gnome-common'라이브러리( Common Files to Build GNOME )이 없어서 나오는 문제.
한국어 소개: 그놈(GNOME) 프로젝트는 사용자를 위한 완전히 자유롭고 사용하기 쉬운 데스크탑 환경과 동시에 소프트웨어 개발자를 위한 강력한 어플리케이션 프레임워크를 만들고 있습니다.그놈은 GNU 프로젝트의 일부이며, 자유 소프트웨어입니다(흔히, 오픈 소스 소프트웨어라고 불립니다). 그놈은 많은 BSD와 GNU/리눅스에 포함되어 배포되고 있으며, 다른 여러 UNIX 시스템에서도 작동합니다.
저는 한자(漢字/汉字)에 관심이 많은 개발자이며, 취미로 중국어(中國語,漢語,汉语, Chinese)와 일본어(日本語, Japanese)를 배우고 있습니다.
저는 어릴때 중국어에서 사용하는 한자(漢字·汉字,hànzì,ㄏㄢˋㄗˋ)와, 일본어에서 사용하는 한자(漢字・かんじ, kanji), 그리고 한국어에서 사용하는 한자(漢字, hanja)가 다르다는 것을 깨닫고, 어릴때부터 한자에 대하여 관심을 갖게 되었습니다.
어릴때 집에서 구독하는 조선일보 기사를 보면 나라 국(國)에 대한 한자를 国로 사용하고, 더불, 줄 여(與)에 대한 한자 与를 쓰는 경우를 보았습니다.
조선일보에서 한자를 표준에 안맞게 쓸까 궁금했습니다. 여기에 대하여 아버지에게 여쭤보면 "조선일보가 일본의 기계로 찍어내서 약자를 쓴다"라고 하시며 "한자 쓸때에는 약자를 쓰면 안된다"라면서 정자체[正字體,일본에서는 구자체(舊字體,旧字体),중국에서는 번자체(繁字體)로 부름]를 배워야 한다고 강조한 적이 있습니다.
조선일보(朝鮮日報,The Chosun Ilbo) 1986년 12월 10일 3면 - 小康정국…与・野의 「対話異夢」(소강정국…여・야의 「대화이몽」, 小康정국…與・野의 「對話異夢」)
동아일보(東亞日報,The Dong-a Ilbo) 1986년 12월 9일 1면 - 與野 代表회담 적극추진(여야 대표회담 적극추진, 與野 代表會談 積極推進)
위의 조선일보에서 여(與)를 "与"로 표기를 하였고, 동아일보에서 여(與)를 "與"를 표기하였습니다.
이후, 고등학교때에 제2외국어로 중국어를 배우고, 대학교때에도 중국어 수업을 들었습니다. 중국 대륙에는 한자를 간체자(簡體字,简体字)로 바꿔서 일상생활에 사용한다 것을 알게 되곤, 한자의 모양이 다양해지고 파편화되고 있구나를 깨달았습니다.
예를 들어 차례, 버금 차(次)에 대한 한자 표기는 각 나라마다 다릅니다.
차례, 버금 차(次)에 대한 다양한 표기 - 중국, 홍콩, 대만, 일본, 한국, 베트남 순으로 표기가 각기 다르다는 걸 확인할 수 있습니다. 次 - Variant Glyphs in China(Mainland), Hong Kong, Taiwan, Japan, Korea, Vietnam.
Table 3-99 that was excerpted from page 174 of CJKV Information Processing (Second Edition) that provides examples of CJK Unified Ideographs whose shapes may be different depending on the locale or region.
Reference: Genuine Han Unification https://blogs.adobe.com/CCJKType/2012/01/genuine-han-unification.html
순서대로 일(一), 여(与,與), 판(判), 기(器), 자(字), 해(海), 일(逸), 골(骨)로 읽습니다.
(각 나라의 한자 모양을 보면, 현재의 Android OS탑재 단말기들이 제조사마다 다르게 구현되어 파편화 되고 있다는 것과 비슷한 느낌으로 받아들이면 될것 같습니다.)
그놈(GNOME)을 처음 접할때...
대학교 입학때, 리눅스 데스크탑을 접하게 되면서 문자표(GNOME gucharmap, KDE kcharselect)를 접하게 되었습니다.
위의 문자표에서 여러가지 한자가 나오면서, 한자에 대한 한국어 표기가 나옵니다만, 영어로 나와서 실망했고, 로마자표기법이 현재 대한민국에서 사용하고 있는 로마자 표기법이 아닌 것이 나와 당황한 기억이 납니다.
시간이 지나며, 중국어 수업을 들으며 간체(简体字)와 번체(繁体字)의 차이에 대하여 관심을 많이 가지게 되었지만, 컴퓨터로 어떻게 처리할지는 그 당시에 생각을 하지 않았습니다.
이후 대학원 다닐때, 저는 CJKV Information Processing이란 책을 알게 되었습니다.
이 CJKV책은 Perl 사용자 모임의 yongbin님께서 주신 책입니다.
저는 이 책을 쭉 훑어보다 머릿속에 충격을 받는 다는 표현이 어떤 것인지에 대하여 알게 되었습니다.
앞부분에는 동아시아 국가에서 사용하는 언어에 대한 인문환경, 표준에 대한 내용이기때문에 기본적인 한자, 중국어와 일본어를 알고 있어서 읽는 것에 그렇게 큰 어려움이 없었습니다.
컴퓨터로 일본어, 중국어, 한국어를 어떻게 처리할지에 대하여 정리한 책인데, 책의 저자가 미국인이라는 것에 놀라도, 한국에서 한국어로 이런 책이 나온 적이 없는데, 미국인이 작성했다는걸 보고 충격을 아주 쎄게 받았습니다.
이 책을 보면서, 미국인이 동아시아문자처리에 대한 정리를 너무 잘했다는 생각이 들면서, 한국어에 대한 처리에 대한 책을 쓰고 싶단 생각을 예전부터 하였습니다.
이후 2012년도 한국 펄 워크샵(Korea Perl Workshop)에서 운이 좋게 "동아시아 문자 처리"라는 주제로 발표를 하게 되었습니다.
이후 KDE kcharselect의 소스코드와 GNOME gucharmap의 소스코드를 일단 확인했습니다.
KDE kcharselect의 소스코드는 C++(QT Library), Python 스크립트로 구성되어 있습니다.
Python 스크립트로 Unicode 관련 txt파일[UnicodeData.txt, NamesList.txt, Blocks.txt, Unihan_Readings.txt (you need to uncompress it from Unihan.zip)]을 읽고, 자체적으로 사용하는 구조체를 이용하여 데이터베이스 파일 생성하는걸 확인하였습니다.
GNOME gucharmap의 소스코드는 C(GTK+ Library), Perl 스크립트로 구성되어 있습니다.
gucharmap에서는 Unicode Consortium에서 정의한 파일 Blocks.txt, NamesList.txt, Scripts.txt, UnicodeData.txt, Unihan.zip 파일을 이용한다고 나와 있습니다.
Perl 스크립트로 Unicode 관련 txt파일을 읽어 들인후 여러 C언어 파일을 생성하는 것이 인상적이였습니다.
Unicode Consortium에서 제공하는 파일중 어떤 파일을 사용하는가?
GNOME gucharmap
KDE kcharselect
UnicodeData.txt
NamesList.txt
Blocks.txt
Scripts.txt
Unihan.zip
UnicodeData.txt
NamesList.txt
Blocks.txt
Unihan_Readings.txt
GNOME gucharmap, KDE kcharselect에서는 한자(漢字/汉字, CJK Unified Ideographs)에 대한 내용은 Unihan.zip파일 내부의 Unihan_Readings.txt의 내용을 참조하는 것을 확인 하였습니다.
저는 유니코드 컨소시엄에서 정의한 Unihan.zip 내부의 한자를 읽는 방법을 정의한 Unihan_Readings.txt파일을 읽고, 내부구조를 확인해보았습니다.
gucharmap based on UNICODE Consortium's specification.
I read Unicode Consortium's Unihan Databases file. (Unihan_readings.txt)
Unihan_readings.txt file includes CJK Ideography's english meanings and pronunciations (such as Chinese, Japanese, Korean, Vietnamese, etc. East Asian cultural sphere's languages)
I found lack of Korean Hangul and Vietnamese pronunciation at GNOME gucharmap.
so, I add Korean Hangul, Vietnamese pronunciation in GNOME gucharmap.
Unihan_Readings.txt에 있는 한국어 발음, 베트남어 발음 추가
Copyright ⓒ 2016 DaeHyun Sung
It's amazing. I add my name "Copyright ⓒ 2016 DaeHyun Sung" in GNOME gucharmap.
I'm Open Source Developer and gucharmap contributor! Also GNOME Developer!
The following is My Gucharmap source code commit log.
Unihan_Readings.txt included in Unihan.zip defines the
notation and pronunciation of East Asian languages such as Chinese,
Japanese, Korean, Vietnamese.
Unihan_Readings.txt’ has some properties.
Such as
kCantonese, kDefinition, kHangul, kHanyuPinlu, kHanyuPinyin,
kJapaneseKun, kJapaneseOn, kKorean, kMandarin, kTang, kVietnamese,
kXHC1983.
I add Unihan_Readings.txt defined kVietnamese property and kHangul property in this program.
Unihan_Readings.txt’s property kVietnamese describe Vietnamese
character(Quốc ngữ) pronunciation. this property defined Unihan version
3.1.1. Now Unihan database version is 9.0.0.
Unihan_Readings.txt’s property kHangul describe Korean
character(한글,Hangul) describe Korean pronunciation for this character in
hangul.(Hangul is Korean Alphabet) this property defined Unihan version
5.0. Now Unihan database version is 9.0.0.
Why do I add kHangul(Korean Alphabet[Hangul]) property?
Because, Unicode Consortium presented kHangul property on Unihan version 5.
Unicode Unihan database document ( http://www.unicode.org/reports/tr38/ ) describe “kKorean” property.
“kKorean property’s description”
The Korean pronunciation(s) of this character, using the Yale romanization system. (See http://en.wikipedia.org/wiki/Korean_romanization for a discussion of the various Korean romanization systems.)
Use of the kKorean field is not recommended. The kHangul field, which is
aligned to the KS X 1001 and KS X 1002 standards, is recommended to be
used instead.
Now, Revised Romanization of Korean (RR, also called South Korean or
Ministry of Culture (MC) 2000) is the most commonly used and widely
accepted system of romanization for Korean instead of "Yale romanization
system"[kKorean property] in Unihan database.
So, I add kHangul property and add “Korean Alphabet(Hangul)” notation.
Why do i add kVietnamese(Vietnamese pronunciation[Quốc ngữ]) property?
“Unicode Consortium’s version9 guide chapter18. East Asia shows these paragraph.
In Vietnam, a set of native ideographs was created for Vietnamese based
on the same principles used to create new ideographs for Chinese. These
Vietnamese ideographs were used through the beginning of the 20th
century and are occasionally used in more recent signage and other
limited contexts.
Although the term “CJK”—Chinese, Japanese, and Korean—is used
throughout this text to describe the languages that currently use Han
ideographic characters, it should be noted that earlier Vietnamese
writing systems were based on Han ideographs. Consequently, the term
“CJKV” would be more accurate in a historical sense. Han ideographs are
still used for historical, religious, and pedagogical purposes in
Vietnam. “
So I read Unihan documentation specification, then support Vietnamese language.
ps1. Now, I summited KDE kCharSelect's new features. but rejected.
because, kCharselect Committer says "this will break distributions that update the data file separately from the library code."
Maybe KDE kCharSelect will change some features.
KDE Committer says "If you have additional ideas which other k* fields from Unihan.txt for CJK languages are useful to be included in KCharSelect, your input is welcome either on kde-utils-devel list, or on kde-frameworks list." to me.
If KDE kCharSelect's new version released, I'll share some East-Asian(CJKV) information processing for committers.
Buy me a coffee
Unihan_Readings.txt included in Unihan.zip defines the notation and pronunciation of East Asian languages such as Chinese, Japanese, Korean, Vietnamese.
Unihan_Readings.txt’ has some properties.
Such as
kCantonese, kDefinition, kHangul, kHanyuPinlu, kHanyuPinyin, kJapaneseKun, kJapaneseOn, kKorean, kMandarin, kTang, kVietnamese, kXHC1983.
I add Unihan_Readings.txt defined kVietnamese property and kHangul property in this program.
Unihan_Readings.txt’s property kVietnamese describe Vietnamese character(Quốc ngữ) pronunciation. this property defined Unihan version 3.1.1. Now Unihan database version is 9.0.0.
Unihan_Readings.txt’s property kHangul describe Korean character(한글,Hangul) describe Korean pronunciation for this character in hangul.(Hangul is Korean Alphabet) this property defined Unihan version 5.0. Now Unihan database version is 9.0.0.
Because, Unicode Consortium presented kHangul property on Unihan version 5.
Unicode Unihan database document ( http://www.unicode.org/reports/tr38/ ) describe “kKorean” property.
“kKorean property’s description”
The Korean pronunciation(s) of this character, using the Yale romanization system. (See http://en.wikipedia.org/wiki/Korean_romanization for a discussion of the various Korean romanization systems.)
Use of the kKorean field is not recommended. The kHangul field, which is aligned to the KS X 1001 and KS X 1002 standards, is recommended to be used instead.
Now, Revised Romanization of Korean (RR, also called South Korean or Ministry of Culture (MC) 2000) is the most commonly used and widely accepted system of romanization for Korean instead of "Yale romanization system"[kKorean property] in Unihan database.
So, I add kHangul property and add “Korean Alphabet(Hangul)” notation.
“Unicode Consortium’s version9 guide chapter18. East Asia shows these paragraph.
In Vietnam, a set of native ideographs was created for Vietnamese based on the same principles used to create new ideographs for Chinese. These Vietnamese ideographs were used through the beginning of the 20th century and are occasionally used in more recent signage and other limited contexts.
Although the term “CJK”—Chinese, Japanese, and Korean—is used throughout this text to describe the languages that currently use Han ideographic characters, it should be noted that earlier Vietnamese writing systems were based on Han ideographs. Consequently, the term “CJKV” would be more accurate in a historical sense. Han ideographs are still used for historical, religious, and pedagogical purposes in Vietnam. “
So I read Unihan documentation specification, then support Vietnamese language.