'분류 전체보기'에 해당되는 글 410건

이번에는 별 내용은 아닙니다. 다만 한국어 자료가 적고 한국 유통사 CFK의 태클과(한글패치의 가능성 때문...실제 한글 패치가 가능했습니다. 하다가 말았지만.)한국에서 PC판 구매가 불가능한 점(해외 리셀러 사이트인 G2A.com 등을 이용하면 되기는 합니다만..) 덕분에 자료가 상당히 부족합니다.

https://steamcommunity.com/sharedfiles/filedetails/?id=409454600

일단 스팀 커뮤니티를 찾으면 나름대로 Mod를 하려고 많은 것을 벌여놓았습니다. 이 때 사용되는 툴이 상당한데 영상을 보시면 적당히 이해는 갈 것이라 생각이 듭니다.

nep2modding_02.06.15_v2.zip

해당 파일은 Re;birth2용을 나온 것이지만 Re;birth1도 잘 됩니다. 다만 GUI따위는 없고(...) 커맨드에 익숙해져야하는 것이 좀 어렵습니다. (다시 Data를 묶어주는 툴인 packer는 제외)

일단 pac파일을 풀어주시면 되는데 다른건 다 필요없고 GAME000000.pac 파일하고 SYSTEM000000.pac파일만 풀어주시면 웬만한 모델과 텍스쳐 그리고 시스템파일들을 볼 수 있습니다. 풀어주시는 방법은

cmd를 여시고

nr2_unpacker.exe "C:\SYSTEM000000.pac"

이런식으로 절대경로로 실행해 주시면 되는데 어려우시면...

그냥 pac파일을 드래그해서 nr2_unpacker.exe파일에 올려놓으세요. 그러면 pac이 풀립니다.(...간단...)

gbin, gstr, cl3 파일은 대사와 동작 스크립트들이 들어있는 파일입니다. txt파일로 변환이 가능하지만 길이가 변하면 아에 먹히지 않는 것으로 보아 그냥 적절히(...)Hex 에디터를 사용하는 것을 추천합니다.

하지만 제한적이지만 Modding중 제일 기본에 충실한 것이 텍스쳐를 수정해서 고해상도와 질감을 표현하는 것일 겁니다. 그 파일이 tid파일인데 

nr2_tidtool.exe를 쓰시면 됩니다. 아까와 마찬가지로 커맨드를 쓰시거나(절대경로!) 그냥 tid파일을 드래그해서 놓으시면 됩니다.(...그냥 이게 편해요)

그러면 기본적으로 PNG파일로 풀리게 되는데 같이 생성된 nr2_tidtool.ini파일을 손을 대서

ExtractImageFormat=1 부분을

ExtractImageFormat=2 로 바꾸어 주시면 TIF파일로 풀리게 됩니다. 텍스쳐 파일이니 적절히(...)수정해주시면 됩니다. 참고로....므흣*_*한 패치도 이미 돌더군요.

모델은 아직 분석이 안 된 것인지 아니면 수정이 빡센것인지 안 돌아다니던데 Left4Dead스킨이 돌아댕기는 것을 보면 분석 되기는 한 것 같습니다. 

GAME200000.pac 안에 있는 duh파일등을 이용하고 아래의 툴을 쓰면 된다고 하는데...저는 처음봅니다. 일단 모델 수정은 다음에.

http://sourceforge.net/projects/petars-programs/files/Ego%20PSSG%20Editor/

그리고....

....CFK님이 이 글을 싫어합니다.

SYSTEM000000.pac 파일 안 window/font/안에 파일이 3개 있는데 이게 당연하게도 폰트파일입니다.

비트맵타입이고 비트맵폰트 수정 전문 도구인 CrystalTile2를 쓰면 수정이 쉽게 됩니다. 폰트가 마음에 안 드시는 분들은 여기서 수정하면 됩니다. 한국어화 해보신 분들은...아실 겁니다. 일본제 게임인지라 Shift-JIS로 되어 있더군요. 적절히...폰트를 수정하고 대사 스크립트(아까 txt로 하지 말고 헥스에디터로 수정하라고 했습니다...이유가 여기 있습니다. 폰트가 애초에 Shift-JIS 인코딩이라 UTF-8이나 EUC-KR인코딩을 하면 안 됩니다.) Shift-JIS중 한자영역에 한글 완성형폰트를 밀어 넣고 개노가다로 해야 겨우 한글패치가 만들어 집니다. 그냥 하지 마세요. 어차피 중학 영어 수준으로 공부하시면 적당히 알아 먹으실 겁니다.

참고..

sysfont.ffu의 3​​bpp 32x36
msgfont.ffu 32x39 N64 4BPP
advfont.ffu 16x42 GBA8BPP (여백부분을 고려하면서 16X34 bytejump128 해 주시면 편합니다.)

마지막으로 다시 pac으로 묶는 것은....

백문이 불여일견! 직접 보세요.

http://web.archive.org/web/20150611182521/http://a.pomf.se/uvvqvf.mp4

여길 보세요. packer프로그램으로 밀어넣을 pac파일을 열고 폴더트리째로 드래그해주시면 됩니다. 일본어로 되어 있는 것도 무시할 정도로 쉽습니다.

이제 스크립트 분석만 하면 Modding이 거의 끝납니다만...

컷신 Mod...왜 처음보는 애들이 나오고 난리냐..(신작인줄 알았네..)

...뭔가 분위기가 이상해졌네요. 좀 더 Modding범위가 자유로웠으면 좋았을 텐데...

(원피스나 나루토가 나오는 Mod도 있던데...)

사운드 쪽은 스팀 커뮤니티 쪽에서도 다른 별 이야기가 없네요. 이쪽도 손을 댈 수 있으면 좋을 텐데 어쩔 수 없지요 뭐. xwb파일로 튀어나온다고 하는데 이건 Xbox용 아닌가..?

...그리고 CFK가 가장 우려하는....스크린샷..

....하지만 여기까지 하는데 2시간 넘게 걸립니다. 안 할 겁니다. 그냥 가능성만 보여 드린거에요.

이유는 잘 모르지만 Wine 환경에서 Windows Media Player 관련하여 계속적인 문제가 생기고 있습니다.

대표적인 예가 Power Point인데요. 슬라이드에 동영상을 추가하려 들면 코덱이 없다고 난리칩니다. 없는 것은 아닙니다. 다만 인식이 안 되고 있는 것 뿐입니다. 그런데 코덱이 자꾸 인식이 안 되나 봅니다. *.ax 형태를 밀어넣고 등록해도 안 되는 것은 안 됩니다.

그런데 오늘 이상한 것을 발견 했습니다.

일부 게임에서 동영상이 삽입되어 있는 경우 Windows Media Player관련 문제로 인하여 동영상이 재생이 안 되야 하는데 갑자기 정상적으로 동영상이 나옵니다. (다만 하드웨어 가속이 안 되는 관계로 프레임이 뚝뚝 떨어집니다.) 즉, 코덱이 인식되었고 비디오 렌더러가 작동을 했다는 의미인데...

winetricks를 이용해서 WMP9하고 devenum만 네이티브로 설치하면 됩니다. 그런데 어떤 프로그램은 동영상이 안 되더군요...뭐지?

결론부터 말씀드리자면...

스팀이 범인이었습니다.

스팀은 최근 스트리밍을 지원하기 때문에 LAVFilter를 내장하고 있습니다. 그리고 스팀이 실행되면 동영상 인코딩을 준비하기 때문에 LAVFilter가 미리 시스템에 올라오게 됩니다. 그런데 Windows용 LAVFilter는 DirectShow를 사용하는데 스팀과 연결된 프로그램(게임입니다...)에서 DirectShow를 요청하자 스팀과 같이 올라와 있던 LAVFilter가 작동을 하게 되었고 WMV를 비롯한 동영상 코덱이 인식이 되어버린 듯 합니다. 혹시나 하고 Non-Steam게임을 돌려보니 이건 동영상이 안 나오네요.

대표적인 것이 BioHazard4인데요. 저는 패키지판과 스팀판 둘 다 있어서 이를 통해서 확인 했습니다. 스팀판은 동영상이 나오지만 패키지판은 동영상이 안 나오네요.

약간 어이가 없기는 하지만 한가지 확실해진 것은 LAVFilter를 임의로 설치하면 Non-Steam게임도 동영상이 나올 가능성이 높다라는 것입니다. Powerpoint도 LAVFilter를 올리고 이를 쓰게 하면 동영상이 삽입될 수 있을듯 합니다! 이것만 되면 MSOffice가 Wine환경에서 완벽하게 돌아가게 됩니다!

다만...피곤하군요. 시간나는 대로 해봐야 겠습니다.

2015.1.14

...안되네요.

LAVFilter를 따로 설치해봤으나 동영상이 인식이 안 됩니다. PPT가 제일 중요해서 이를 써봤는데 안 됩니다.

뭐 디버거는 YV24니 NV24니 하는 코덱이 없다고 난리를 치는데 wine에서 구현이 안 되었거나 저부분을 무시하게 하는 패치를 하거나 해야 겠는데 전 못하겠습니다. 아쉽군요.

zRam이란 기술은 리눅스가 임베디드기기에 올라가던 시절에 생각했었고 2010년 스마트폰에서 안드로이드가 미친듯이 성장하면서 많은 발전을 이룬 기술 중 하나입니다. 즉 2015년 현재 zRam은 상당히 나온지 오래된 기술중 하나입니다.

간단하게 말하자면 zRam은 램드라이브 스왑 파티션이라고 생각하면 의외로 간단합니다. 물론 그와는 큰 차이가 있습니다. (실제로 램드라이브를 보통의 스왑파티션으로 잡으면 상당히 병맛납니다. 하지마세요.)

리눅스는 윈도우의 그것과 같이 메모리가 모자르면 디스크를 메모리처럼 사용하기 위해 스왑을 시도합니다. 그 덕에 메모리가 부족하면 무시무시하게 늘어지는 데스크탑을 볼 수 있었습니다. 그렇다고 스왑을 안 쓸 수는 없었습니다. 당장 메모리가 없는데 일단 지금 돌아가는 프로그램을 선택적으로나마 종료하려면 그나마도 메모리가 필요했으니까요.

zRam은 이 생각을 뒤집고 다르게 생각한 기술입니다.

"프로그램의 사용량을 판단해서 잘 안 쓰는 메모리는 압축해 두는 것은 어떨까?"

사실 리눅스는 잘 안 쓰는 데몬이나 프로그램들이 의외로 많습니다. 당장 cups만 봐도 프린터를 안 쓸 때는 굳이 돌아가지 않아도 됩니다. (이는 Windows의 Printer Spooler 서비스만 봐도 알 수 있습니다. 수동 모드로 되어있지요.) 1시간에 한번씩 체크하는 업데이트 서비스도 비슷하다고 볼 수 있구요. 그런데 이 놈들은 전부 메모리에 올라앉아서 아까운 메모리를 쳐묵쳐묵하고 있습니다. 요새 컴퓨터에 워낙 성능이 좋으니 큰 문제를 일으키지는 않지만 아까운것은 아까운 겁니다. 저 데몬들이 메모리를 잡으면서 발생하는 전력소모도 상당히 아깝습니다.

이럴 때 zRam은 저 잘 쓰이지 않는 메모리들을 압축해서 자체적으로 만들어진 램 한쪽 구석에 쑤셔넣어버립니다. 이 과정은 눈에 보이지 않고 사용자가 느낄 수도 없기 때문에 이런일이 벌어지는지 사용자는 전혀 눈치를 챌 수 없습니다.

 특히 어마어마한 자동화 스크립트와 데몬이 기본으로 굴러가는 우분투는 데비안같은 배포판에 비해 메모리 사용량이 상당히 높습니다. 2GB이하의 메모리를 지닌 하드웨어는 우분투가 상당히 버거울 지경입니다. 이때 zRam을 활성화한다면 상당한 성능향상을 꾀 할 수 있습니다.

만약 8GB이상의 메모리를 장착한 PC라면 굳이 zRam은 필요없을 것입니다. 그리고 예전에는 안드로이드 스마트폰에서도 상당히 애용되었는데 요즘 스마트폰은 괴물이 많은데다가 최적화기술이 많이 발전되어서인지 zRam이 빠지고 추세입니다. 하지만 3년만 지나면 구형이 되는 이 시대에 zRam은 커스텀롬에서 빠질 수 없는 기술 중 하나입니다.

말만이렇게 주구장창해봐야 소용없고 한번 zRam을 써보셔야 아시겠지요?

우분투 14.04이후에선 아주 간단하게 zRam을 쓸 수 있습니다.

sudo apt-get install zram-config

이렇게 zram-config을 설치해주시면 zRam의 설정은 끝입니다. 

궁금하시면

이렇게 zRam 블록이 추가되었는지만 확인하면 됩니다.

메모리 부족하신분은 이 설정만으로도 어마어마한 성능향상을 느낄 수 있으실 겁니다.

리눅스에서 알파벳 사용권 이외의 사람들이 자국어를 입력하고자 정말 많은 일들을 했습니다. 그리고 한국도 이와 다르지 않아 한글을 입력하고자 많은 사람들이 노력해왔습니다. 이는 Windows에서도 있었고 지금의 리눅스 환경에서도 있었습니다. Windows에서는 90년대만 하더라도 남극성이라던가 AsianSuite같은 것들이 쓰였습니다만 NT시대가 도래하면서 내부적으로 유니코드로 처리를 하게 되었고 기본 한글 입력기인 MS-IME 하나가 독보적으로 쓰입니다. (물론 새나루 같은 3rd-Party입력기도 있습니다.) 하지만 리눅스는 누구 하나가 독점적으로 주도해 나갈 수 없는 상황입니다. 그덕에 한글입력기가 여러가지가 나와있고 어느 하나가 낫다고 말을 못하는 실정입니다. 그 중 가장 많이 쓰이는 리눅스의 한글입력기 3종 세트를 비교해보도록 하겠습니다.

1. 나비(nabi)

2. 벼루(UIM-Byeoru)

3. 아이버스 한글(ibus-hangul)

우선 나비는 한국에 한국에 의한 한국을 위한 입력기 입니다. 무슨 말이냐면 나비는 다른 입력기와는 다르게 오로지 한국어와 영어만이 입력가능합니다. 다른 입력기는 입력 프레임워크위에 한글 입력기능을 추가하는 방식입니다. 하지만 나비는 그 자체만으로 한국어 입력을 위해 만들어졌기에 일본어나 중국어의 입력에 관해 전혀 고려가 되어있지 않습니다. 2004년에 처음 만들어진 나비는 거의 유일하다시피한 한글 입력기여서 많이 쓰였습니다. 하지만 업데이트가 상당히 더디며 새로운 라이브러리에 대응이 느린 덕에 아치리눅스 같이 빠른 업데이트가 생명인 배포판에서는 상당히 골때리는 상황이 자주 연출됩니다. 대표적인 것이 우분투의 Unity버그입니다. Unity가 나온지는 4년이 지난 지금도 입력기가 트레이에 들어가지 않는 버그가 있습니다. 하지만 LXDE나 MATE환경에서는 전혀 문제가 없습니다. 이외에도 QT5대응이 늦어져서 QT개발자들이 다른 입력기로 많이 넘어갔습니다. 여러모로 참 인력난에 시달리는 입력기라고 할 수 있습니다.

벼루는 일본에서 개발된 UIM프레임워크용 한글 입력 시스템입니다. 3종 입력기중에서 제일 오류가 적으며 호환성도 상당히 좋아서 보통 한글입력기를 추천하라고 하면 많이 추천하는 입력기입니다. 벼루 자체도 상당히 완성도가 높아서 Windows의 MS-IME의 입력과 동일한 입력이 가능합니다. 특히 리브레 오피스와 크롬에서 악명을 떨쳤던 끝글자 버그를 해결해버려 상당히 점유율이 높습니다. 지금은 다른 입력기도 해결한 버그지만 벼루가 제일 먼저 해결하여 상당히 선점 효과를 얻었습니다. 그러나 다른 입력기에 비해 메모리를 많이 먹는 것은 단점이라 할 수 있습니다.(UIM자체가 메모리를 많이 먹습니다.)

ibus는 우분투의 기본 입력 시스템으로 쓰이기에 우분투와 상당히 궁합이 좋습니다. ibus프레임워크는 중국에서 개발되었습니다. 즉, 개발팀의 규모가 UIM이나 나비와 상대가 되지 않습니다. 피드백도 빠르고 업데이트도 상당히 빨리 나오는 편입니다. 하지만 업데이트가 빠른만큼 버그가 상당히 많아서 한국어 사용자들에게 상당히 이미지를 많이 깎였습니다. 리브레 오피스에서 끝글자 버그라는 버그를 거의 7년 넘게 갖고 있었고 한영전환이 자유롭게 되지 않아서 수동으로 전환하는 삽질을 하게 되는 의외로 이런 일이 비일비재합니다. 하지만 또 그만큼 사용자층이 두껍다보니 다른 프로그램과의 호환성은 매우 좋습니다. 특히 Wine환경 같이 입력기의 호환성이 애매할 때는 그냥 ibus를 이용하면 한글 입력에 큰 문제를 안 일으킵니다. 무엇보다 입력기의 커버리지가 상당해서 전혀 생각지도 못한 언어도 입력이 가능하다는 점도 장점이라면 장점입니다. 다만, 한국어 사용자들의 피드백이 적은 탓인지 한글쪽은 입력기의 문제가 해결이 잘 안 되는군요.(한국은 워낙 피드백이 적어서 7년넘게 버그가 해결이 안 된다거나 합니다.)

무엇을 쓰던지 상관은 없습니다만, 결국 한국어를 입력하기 위해서 어떤 입력기를 사용하던지 큰 문제는 없을 듯 합니다. 다만, 개인적으로 UIM은 고사양용이며 ibus는 한국어에 한해 버그가 참 많습니다. Nabi는 업데이트가 늦습니다. 자 그래서 여러분들은 어떤 한글입력기를 쓰시나요?

Plae Moon은 창백한 달이란 의미입니다. 웹브라우저의 성능과는 큰 관계가 없지만 기존의 Firefox의 로고에서 여우만 지워버리면 대충 비슷하게 생기기는 했습니다.

Pale Moon은 이제 개발이 시작되고 10년이 넘어가는 Firefox를 Fork하여 만들어진 브라우저입니다. 속도와 메모리 사용량을 꽤나 생각했습니다. 다만, Firefox도 원래부터 메모리를 적게 먹기로 유명한 물건이니 메모리 사용량이 큰 차이는 나지 않았습니다. (한 100MB차이 나더군요.) 

Pale Moon과 Firefox의 메모리 사용량 비교 큰차이는 나지 않지만 Pale Moon은 탭이3개였고 Firefox는 탭이 1개였다. (아래 스크린샷 참조)

실제로 Pale Moon은 Firefox 사용자들의 입소문을 타고 많이 알려져 있던 변종 중 하나 입니다. 이제서야 써보게 되었는데 상당히 만족스럽습니다. 메모리도 약간이나마 적게 쓰는 것 같고요. Chrome이 속도는 제일 빠르지만 메모리를 너무 먹어대서 일을 보기위해 가상 머신이라도 하나 열면 버벅버벅대는 꼴이 보이더군요. 그러다보니 Chrome은 그냥 가끔 쓰고 Firefox를 주 웹브라우저로 쓰고 있었는데 Pale Moon은 Firefox보다 더 가볍군요.

설치하기전에 Firefox와 비교를 안 할 수는 없겠지요? 한번 비교를 해보겠습니다.

인터페이스 비교. 아래 스크린샷을 보시면 미묘하게 차이가 보입니다.

Firefox에는 제가 확장을 이것저것 깔아놓아서 좀 지저분 하기는 합니다만 전체적으로 깔끔한 인상을 줍니다. 그에비해 Pale Moon은 구버전의 Firefox의 인터페이스를 고수하다보니 약간 옛날 느낌이 나더군요.(물론 2.x~10.x 시절을 안 쓰셨던 분들은 잘 모르실겁니다.) 저야 과거를 추억하며 익숙해지는데 금방 걸렸습니다만 처음 쓰시는 분들은 해메실지도 모르겠습니다.특히 메뉴표시줄의 존재가 차이가 나는군요.

렌더링 속도차이

..으음... 사이트마다 약간씩 다릅니다만, 체감상 1~2초 정도 더 빠르다는 인상입니다. 하지만 요즘 컴퓨터같이 빠른 컴퓨터에서는 큰 차이는 안 느껴질겁니다. Pale Moon 측에서는 과거의 오래된 CPU를 버리고 최신 CPU에 맞춰 컴파일해서 빠르다고 하는데 요즘 하드웨어가 워낙 빨라 의미는 없을 듯 합니다. 그러나 상대적으로 메모리를 적게 먹는다는 것 하나는 꽤 중요합니다. 굉장히 오래된 넷북에서 인터넷 하나만 하려고 해도 버벅댄다면 Pale Moon의 성능이 상당히 체감이 될 것이라고 생각됩니다. (심지어 Atom용 Pale Moon도 배포중입니다!)

기술적인 차이..??

아래의 링크를 참조하시길 바랍니다. 그냥 Pale Moon이 Firefox와 어떤 차이를 보이고 왜 더 빠른지에 대한 글입니다.

https://www.palemoon.org/technical.shtml

일반적으로 쓰시는 분들은 그냥 무시해도 좋습니다. 빠르면 좋은겁니다.(펜티엄3 이하는 지원이 안 된다는 것이 중요하군요. 아직도 쓰는 건가 싶지만...)

그럼 이제 제일 중요한 어떻게 설치할 것인가? 이군요. Pale Moon은 아쉽게도 아직 우분투용 공식 저장소에 등록되지 못했습니다. 그리고 PPA도 없습니다. 하지만 공식홈페이지에서 인스톨러를 따로 제공하고 있습니다.

http://linux.palemoon.org/download/installer/

위 주소로 접속하면 인스톨러를 다운로드 받을 수 있습니다.

Downlaod 링크를 누르면 인스톨러를 다운로드 받을 수 있다. 다른 것은 다 필요없을터이니.

그리고 다운로드 받은 파일의 압축을 풀면 안에 Readme파일 하나와 sh스크립트 하나가 튀어나옵니다. 그냥 스크립트를 실행하시면 됩니다.

이제 저 스크립트를 그냥 실행하자(sudo 따위 쓰지말자..) 지가 알아서 관리자 권한을 요구한다. sudo를 쓰면 꼬일 가능성이 있으니 쓰지 말라고 한다.

이제 Install Pale Moon을 선택하고 OK만 누르면 끝! 설치는 알아서 해준다.

이제 Pale Moon의 설치가 다 끝났습니다. 이제 한글을 설정해 보도록 하겠습니다.

Pale Moon은 Firefox와 언어팩이 호환되지 않습니다. 그래서 Pale Moon 홈페이지에서 언어팩을 설치해야 합니다.

https://www.palemoon.org/langpacks.shtml

여기서 ko.xpi파일을 다운로드받아 설치합니다.

Korean만 찾자...ko.xpi를 누르면 알아서 확장 설치 모드로 열릴 것이다.

한국어 확장을 설치 후에 Locale을 한번 바꿔주셔야 한글로 나오게 됩니다. locale설정을 위해 한번만 더 삽질을 합시다.

주소창에 about:config 이라고 쳐서 들어갑시다.

그리고 Search창에 general.useragent.locale 이라고 검색하면

다음과 같은 화면이 나옵니다.

잘 안보이겠지만 general.useragent.locale 이라는 항목이다! (이미 한국어로 설정되어있어서 한글로 뜨는 것 뿐..)

en-US로 되어있는 것을 ko-KR로 바꾸자.

이제 창을 닫았다가 다시 실행하면 한국어로 잘 될 겁니다.

나머지는??? 그냥 즐기세요.

일부 사이트에서 로그인이 안되는 현상을 찾았습니다. 인증서 문제인가 하고

http://moordev.tistory.com/4

이 작업을 했음에도 계속

요렇게 나옵니다. 이건 신뢰 받는 연결 어쩌고 이전에 Pale Moon에서 Firefox와 다르게 설정이 된 탓이라고 합니다.

우리나라에서만 이러한 것이 아니라고 하네요. 그런데 보안에 취약한 것으로 드러나서 안 쓰는 방식을 아직도 고수하는 것이 더 문제 아닐까 싶지만...

일단 방법은 about:config에서 두 번만 수정하면 됩니다. (출처 : http://forum.palemoon.org/viewtopic.php?f=3&t=3342)

security.ssl3.rsa_rc4_128_md5

security.ssl3.rsa_rc4_128_sha

그냥 더블클릭 하면 true로 바뀐다. 간단!

요 두개만 true로 바꿔주시면 문제없이 잘 될 것입니다.

근데 MD5뚫린게 언제인데(...)

Adobe Reader는 PDF파일을 볼 때 제일 많이 쓰이는 뷰어 입니다. 그런데 Adobe가 만들었지만 ISO에 교환용 문서 표준으로 등록되면서 Adobe외에 다른 뷰어들이 많이 만들어지게 되었습니다. 대표적인 것이 Windows 8에 들어간 PDF리더가 있고 리눅스에서 많이 쓰는 그놈 문서 뷰어도 당연히 PDF를 지원합니다. 심지어 파이어폭스와 크롬도 웹브라우저에서 PDF리딩을 지원합니다.

우분투 기본 PDF뷰어인 문서보기 보통의 PDF는 이걸로 다 볼 수 있다.

그런데 Adobe는 PDF에 자신들만의 기능들을 추가한 적이 있습니다. 문서라고 보기는 어려운 기능인데 대표적인 것이 3D PDF입니다. 3D의 모델일 PDF뷰어로 읽어서 뷰어에서 이리저리 모델을 돌려보며 볼 수 있게 만들어 놓았습니다. 보통 3D 모델을 다른 회사에 전달할 때 수정은 불가하면서 모양은 볼 수 있게 할 때 많이 애용합니다.

3D PDF는 전달용으로 애용중. 출처-Simlab-soft.com

그런데 이건 아직 다른 뷰어에서 지원되는 것을 못 봤습니다. 오로지 Adobe Reader에서만 볼 수 있는 것이더군요. 3D CAD가 널리 쓰이면서 3D PDF로 도면을 전달하는 경우가 많이 늘고 있습니다만 일반PDF리더는 이를 지원하지 못하므로 Adobe Reader를 무조건 설치해야만 하는 상황입니다.

그래서 Adobe Reader의 리눅스 버전을 설치하기 위해 Adobe 홈페이지에 들어갔는데...

리눅스는 아에 존재자체가 말살 당했다!!!! Adobe는 이제 리눅스를 없는 운영체제로 취급하기 시작했다.

이제는 Adobe가 리눅스 버전의 리더의 링크조차 삭제해버렸습니다. 예전에는 그나마 구버전이라도 링크를 걸어줬던것 같은데...

Adobe Reader가 필요한데 이럴때는 방법이 2가지가 있습니다.

1. Wine을 이용해서 Windows버전을 이용한다.

2. 구버전의 리눅스용 버전을 설치한다.

1.안은 Flash Player나 Adobe Air같이 그냥 Wine에서 Adobe Reader를 실행하면 그만입니다. https://appdb.winehq.org/objectManager.php?sClass=version&iId=27093

11.x버전도 3D PDF읽기 정도는 잘 된다고 합니다.

2. 구버전을 설치하는 방법은 안드로이드에서도 Flash Player를 쓰기위해 이미 쓰이고 있던 방법입니다. Adobe는 홈페이지에서 링크를 삭제했습니다만, 아직 서버에는 가지고 있습니다. ftp://ftp.adobe.com/pub/adobe/reader/unix/9.x/9.5.5/enu/

여기에 들어가시면 Adobe Reader의 최후의 리눅스 버전을 보실 수 있습니다. 여기서 deb형태를 받아서 설치하면 됩니다.

만약 위 링크가 작동 안 한다면 아래의 미러 링크를 사용하세요.

https://www.dropbox.com/s/e686bqgwuekxcl2/AdbeRdr9.5.5-1_i386linux_enu.deb?dl=0

그리고 아래의 명령어를 터미널에 붙여넣으세요.

sudo apt-get install libgtk2.0-0:i386 libnss3-1d:i386 libnspr4-0d:i386 lib32nss-mdns* libxml2:i386 libxslt1.1:i386 libstdc++6:i386

필요한 32비트 라이브러리를 설치함으로써 구동이 되도록 합시다. 보통은 구동이 될테니 걱정 마세요. 우분투 14.04기준으로 잘 됩니다.

영문판밖에 없기는 하지만 쓰는데 지장은 없으니 Adobe Reader를 이용해주시면 됩니다. 

이런식으로 설치된 Adobe Reader 리눅스버전. 오래된 버전이지만 아직까지는 쓰는데 지장없다

하지만 어쨌거나 구버전이기 떄문에 보안문제가 있을 수 있고 최신기술에는 여전히 안 읽힐 것입니다. 임시로 쓸 수는 있겠지만 결국에는 필요해질터이니 3D PDF기능이 지원되는 오픈소스 뷰어가 있다면 댓글에 써주시면 감사드리겠습니다.

조이패드나 조이스틱은 게임을 하는 사람에게 있어서 참 좋은 물건입니다. 최근에는 Xbox나 PlayStation의 기본패드가 참 잘빠지게 나와서 이를 적용하고자 한때 많은 사람들이 칼을 빼 들곤 했습니다. 지금은 USB포트라는 참 범용성 높은 포트를 쓰기 때문에 PC에서 콘솔을 쓰는 느낌을 주기 쉬워 졌습니다.

윈도에서 패드로 키보드게임 할려고 하면 제일 먼저 생각났던 프로그램 JoyToKey 이제는 쉐어웨어가 되었다.

그런데 콘솔,PC멀티 게임은 그렇다 치지만 본래 PC에서 패드 없이 했던 게임을 하고자 했을 때는 이야기가 조금 달라집니다. 몇몇 게임은 애초에 패드를 지원 안 합니다. 게다가 돈이 부족한 인디게임에선 패드를 지원하지 않는 경우도 더러 있습니다. 이럴때 Windows에서 이용하던 프로그램이 JoyToKey였습니다. 조이패드를 키보드로 인식시키는 프로그램이었는데 참 다용도로 쓰였습니다. 요새는 무선패드가 많아서 이를 무선 마우스 대용으로 쓰는 사람도 있었으니까요. 하지만 리눅스에서 이런 물건은 없나 살펴봤더니 있습니다. Qjoypad란 놈인데 보시면 아시겠지만 QT기반입니다. QT가 본래 조이패드를 지원하는 기능이 있었는데 이를 이용한 것으로 보입니다. 덕분에 많이 가볍습니다.

Qjoypad의 모습...JoyToKey랑 다른 것이 하나도 없다.

다만 다 좋은데 이 프로그램은 업데이트가 중단된지 한참 지났습니다. QT4를 쓰는 것으로 확인되는데 QT5로 전환이 될 필요가 있음에도 아직 아무도 QT5로 전환하지 않았더군요. 일단 소스코드는 남아있으니 누군가 새로이 업데이트를 하던가 미래에는 본인이 하던가 해야 합니다. 아니면 그 때에는 더 좋은 다른 프로그램이 나와있을 수도 있습니다.

참고로 joyTokey를 써본신분은 익숙하실지도 모르지만 처음 쓰시는 분들은 처음 실행했을 때 당황스러우실 수도 있습니다. 그도 그럴것이 화면에 창이 안 뜨거든요.

하지만 시계근처에 보통 있는 실행바를 보시면 빈공간(?)이 생긴 것을 볼 수 있는데 여길 왼쪽클릭하거나 오른쪽 클릭 함으로써 Qjoypad를 설정할 수 있게 됩니다. 왼쪽 클릭을 하면 위와 같은 창이뜨는데 여기에서 키를 설정해주시고 게임을 해주시면 됩니다.

만약 어떤 버튼이 어떤 버튼인지 모르시는 분들은 jstest-gtk를 같이 실행해놓고 조이패드의 버튼을 눌러보면서 하는 것을 추천합니다.

JSTest의 모습. 윈도의 제어판에 있던 게임컨트롤러 설정과 나름 비슷하게 만들려고한 흔적이 보인다.어쨌건 이녀석을 통해 내 조이패드의 버튼이 몇 번 버튼인지 확인하자.

참고로 Qjoypad는 QT로 만들어졌기 때문에 마음먹으면 Windows로 포팅이 가능한데요. 쉐어웨어인 Joytokey랑 비교했을 때 가장 중요한 기능은 꿀리지 않습니다. Windows에서도 리눅스처럼 이 녀석을 한번 추천하고 싶군요.

공돌이들의 친구 Matlab은 3대 OS를 모두 지원하는 프로그램입니다. 저도 덕분에 리눅스용을 설치해서 엄청 애용하고 있습니다.

 대다수 학교나 공공기관은 Windows용을 사용합니다만, 어차피 라이센스가 OS상관없이 호환되기 때문에 학교에서 구입한 Matlab을 리눅스에서도 별 문제없이 잘 쓰고 있습니다. 그런데 리눅스용을 쓰다보면 기존 Windows사용자들과 충돌이 가끔 벌어지는데 Windows용과 리눅스용은 단축키가 다르다는 문제가 있습니다.

원인은...Mathworks사에서는 리눅스용 Matlab을 만들때 리눅스에 기본적으로 포함된 Emacs의 단축키로 기본 세팅하기 때문이었습니다. 헌데, 리눅스 데스크탑도 Emacs단축키보다는 Windows단축키를 사용하는 것을 감안하면 뻘짓이지요.

Emacs를 쓰시는 분들이 그다지 많지 않은 관계로 대표적인 단축키가 어떤 차이가 있는지 말씀드리겠습니다.

제가 제일 많이 쓰는 단축키 3개만 놓았는데도 이러한 차이가 나옵니다. 심지어 Windows단축키가 더 갯수가 많습니다. Emacs는 보통 본인들이 세팅해서 쓰는 스타일이니 그러려니 합니다.

어쨌거나 Windows단축키가 더 익숙해진 지금 Emacs단축키는 새로 외우기도 힘들고 심지어 어렵습니다.(Ctrl+Y는 한손으로 치기 어렵습니다... 손이 워낙 작아서...)그러면..세팅을 바꾸면 되는데 이 방법은 아주 간단합니다.

2014이전 버전에서는 File-Preference로 들어가시기 바랍니다. 이후 버전이라면...

도구상자에 있는 기본설정 버튼을 눌러주세요.

그리고 키보드-바로가기(Keyboard-Short cut)에서 Emacs 설정을 Windows Default로 바꿔주시면 됩니다.

이제 그냥 쓰던데로 쓰시면 됩니다.(!)

대체 이것은 무엇인가??? 첨부파일은 다 어디간거야??

가끔 Thunderbird나 기타 이메일 클라이언트를 쓰다보면 첨부파일로 winmail.dat 라는 파일을 받을때가 있습니다. 이건 사실 Microsoft의 규격에 의해 생긴 일로 Outlook 이외의 클라이언트로 Outlook에서 첨부파일을 보낼 때 생기는 일로 쉽게말해서 MS의 농간입니다.(...)

개나소나 Outlook을 쓰고 있지만 아직 이를 잘 활용하는 업체는 0에 가까운 고로(...어떤 회사에서든지 뉴스그룹 같은 것을 쓴 것을 본 적이 한 번도 없습니다.)그냥 기본설정으로 쓰다보니 생긴 폐해입니다.

https://support.mozilla.org/ko/kb/what-winmaildat-attachment

이를 보시면 잘못된 설정에 의해 생긴 폐해인데요. TNEF형태는 MS독점 형태이며 MS만이 사용가능합니다. 물론 이미 역 어셈블해서 분석이 완료되었지만 라이센스의 문제도 있어서 이래저래 문제가 있습니다.

결국 보내는 쪽(Outlook사용자)측에서 TNEF형태를 안 쓰도록 하는 것이 가장 좋지만 우리나라는 알다시피 그렇고 그런 나라(인데다가 관심도 없지요)이기에 TNEF를 그냥 쓰고 있을 겁니다.

일단은, 첨부된 것을 다시 보내달라고 하기는 힘드니(애초에 설정 건드는 것 자체가 고역인 사람들이라...) 잘못 날라온 winmail.dat파일을 열어서 확인하는 것을 알려드리겠습니다.

1. Thunderbird 확장 중 LookOut이란 확장을 쓰자.

위의 링크에보시면 나오는 것이라서 간단합니다만, 지원이 끊기면 답이 없습니다. 하지만 일단 설치해 놓으면 Thunderbird에서 바로 파일을 열 수 있어서 편리합니다.

하지만 제일 좋은 것은 TNEF자체를 사용하지 않는 것!

2. tnef 패키지를 쓰자.

위의 Lookout 확장에서 사용한 코드입니다. MS의 TNEF를 분석해서 만든 프로그램이며 메일에 첨부된 winmail.dat 파일의 암호를 디코딩해줍니다.

sudo apt-get install tnef

위 명령어로 설치하고

tnef winmail.dat

명령으로 디코딩합니다. 하지만 윈도우는......다른 프로그램을 사용합니다.

winmail opener라는 프리웨어를 사용하시면 됩니다. 이건 구글링하면 금방 나옵니다.(...윈도 사용자는 저한테 약간 무관심영역이다보니...)

그나저나 IE전용코드에 이어서 Outlook전용코드라니....이건 진짜 너무합니다. Thunderbird가 점유율이 아직 현저히 낮은 것이 원인인가요?

볼 사람은 아무도 없겠지만 Outlook을 사용하시는 분들께 고합니다.

제발 다른사람들이 요청하면 좀 모두가 볼 수 있는 설정을 사용해주시기 바랍니다. 그동안은 모르고 사용하셨겠지만 웹메일에서도 TNEF 형태는 에러가 납니다. 세상에는 이메일클라이언트가 Outlook만 있는 것이 아니랍니다. 모두에게 평등한 웹이 됩시다.

실시간 게임번역기란 물건이 있습니다. Monkey head's OCR Realtime Translator - 이하 Mort (http://www.steambb.com/bbs/board.php?bo_table=gamebb&wr_id=479632) 라는 물건입니다. 기존의 텍스트 후커는 API후킹방식을 주로 이용하여 이루어졌는데요. 이 방법은 그냥 화면에 나오는 문장을 OCR로 읽어서 텍스트를 읽어들입니다. 사실 이는 이전에 VNR(Visual Novel Reader)란 프로그램에서도 지원되는 기능이었지만 이 물건은 워낙 묵직했던데다가 API후킹도 지원되던 탓에 OCR방식은 잘 쓰이지 않았습니다. (모르는 사람도 있습니다.) 그에 비해 Mort는 성능도 괜찮고 그럭저럭 쓸만합니다. 단점이라면 Tesseract의 학습 기능을 어느 정도 쓰지 않았다면 인식률이 개판입니다. Mort는 학습 기능과 함께 이미지 전처리 기능을 넣어서 어느정도 인식률을 올린 듯 합니다. 그럼에도 여전히 엉망이라 Spell Checker 기능까지 우겨넣어서 인식률을 끌어 올려야 하더군요. 

그래도 상당히 좋은 물건인 듯 해서 리눅스에서 돌릴 수 있는지 봤는데...

닷넷 프레임워크를 필요로 합니다. mono로는 실행이 안 됩니다. 그래서 약간의 폭발 이후 비슷한 클론을 하나 만들어 냈습니다.

...물론 대충 만들어서 모양은 별로이며 동일한 Tesseract 엔진이라 인식률은 꽝입니다. 심지어 이미지 전 처리 기능도 없습니다.....(PIL이나 OpenCV를 써서 넣으면 되기는 합니다만...)

적당히 만들어서 Gitjub 정도에 올리면 되지 않을까 생각하고 있습니다. 자신 있게 올리기엔 코드가 더러운게 흠이지만요.(저는 프로그래밍 전공이 아닙니다. 그래서 알고리즘이 최적화 되어있지 않습니다.)

제작 언어는 제작 속도가 더럽게 빠르기로 유명한 Python 2.7입니다.(3.x는 일부 라이브러리 때문에 사용 불가) 그리고 Tkinter와 기타 플랫폼 독립적 라이브러리를 이용했기 때문에 (OSX, Windows, Linux만 되기는 하지만)크로스 플랫폼(!) 입니다. Tesseeract-OCR를 라이브러리 형태가 아니기에 따로 추가 설치 해주셔야 합니다. (하지만 Tesseract-OCR도 각 플랫폼 별 바이너리를 제공하기에 큰 문제는 없습니다.)

Mort에 비하면 UI가 공대 감성입니다. 미리 말씀드리자면 완성된 프로그램도 아니고 그냥 비슷한 기능을 구현한 것입니다. 작동 되면 좋고 아님 마는 겁니다.

구성은 창 2개입니다. 왼쪽 터미널 위에 있는 컨트롤 창과 오른쪽 Scan Area 창 두 개입니다.

우선 캡쳐 하고자 하는 부분을 Scan Area 창으로 가려 버립니다(!) 저 Scan Area 창은 X버튼의 기능을 삭제 했습니다. 때문에 그냥 구역 설정 기능만 갖춘다고 생각하시면 됩니다.

...그리고 Start를 누르면...Scan Area창이 최소화되면서 해당 Area 부분을 캡쳐한 뒤 신나게 OCR로 읽어들입니다. 인식률은????.........아직은 포기하면 편해요. 이미지 전처리 기능을 만들지 않는 이상 인식률을 효과적으로 끌어올리기는 힘들 듯 합니다.

그리고 한국어 번역을 쓰는데 구글 웹 번역기(?)를 씁니다. goslate란 모듈이 이를 지원합니다. (영어 → 한국어) 보다는 (영어 → 일어 →한국어)가 더 번역율이 높다고 들어서 한번 해봤는데 구어체는 별 차이가 없습니다. 그래서 그냥 (영어 → 한국어) 로 처리 중입니다.

그냥 한번 어떻게 되는지 구경이나 해봅시다.

번역을 하고 싶은 부분을 찾아서 Scan Area 창을 신나게 가지고 놀자

일단 게임을 실행하고 작성한 파이썬 스크립트를 실행합니다. 항상 위 옵션으로 걸려있으므로 Scan Area 창은 절대로 게임 창 뒤로 가지 않습니다.

번역을 하고자 하는 구역을 Scan Area 창으로 가려버리자! 추후 여기에 번역문을 띄울까 하는 생각도 해봤지만...그건 별로

번역을 하고자 하는 부분 위에 창을 올려놓고 조절합니다. 그냥 가리면 됩니다. 참 쉽죠?

그리고 Start를 하면??? Scan Area 창이 자동으로 최소화 됩니다. 그리고 터미널에 보면!!!

왼쪽에 터미널을 주목하자 아직 출력 창을 안 만들었기에 터미널에 번역문을 대신 띄우고 있다. 참으로 공대감성이 아닐 수 없다.

....번역기의 성능은 기대 안 하는 것이 좋습니다. 어차피 구글 번역기이니까요. 심지어 잘 못 인식된 글자도 있네요. 저것은 이미지 전 처리 기능과 Spell Checker를 추가로 붙여서 보완해야 합니다. 하지만 이를 리눅스로 구현했다는 데에 의의가 있습니다. (그런데 테스트에 쓴 게임은 Windows용 Wine 구동 게임...)

이걸 조금만 더 다듬으면 훌륭한 크로스 플랫폼 실시간 번역기가 될 수 있을 듯한데 모양도 별로고 조금 공대 감성을 탈피해야 합니다. (범인은 Tkinter) 하지만 3일만에 만든 것 치고는 그럭저럭 괜찮네요. 이제 OCR된 문자열 및 번역문 츨력창을 따로 만들고 이미지 전 처리 기능을 넣고 Hunspell- Spell Checker (http://hunspell.sourceforge.net/)을 적용하면 인식률을 엄청 끌어 올릴 수 있을 것 같은데 뭐....언젠가는 하겠지요 뭐...