웹 브라우져, libreoffice 문서 작성기, 기타 편집기에서 한글 낱말 잘라내는 문제
글쓴이: andysheep / 작성시간: 금, 2017/03/03 - 9:36오후
화면 폭에 정해진 길이가 넘어가면 영어는 낱말 전체를 다음
줄로 넘기지만 한글은 여전히 낱말 중간을 잘라버려요.
한글은 한자가 아닌 소리 글자로 낱말 단위로 붙여야 합니다.
영어처럼 낱말처리하게 구현하는 건 소스 코드 몇줄이면 끝나는데
수십년이 지났지만 바뀌지 않는 이유가 뭘까요?
습관이 무서운 건지, 이점에 관심을 두고 패치할 수 있는 개발자가 부족한 건지.
전자라고 보는데요.
우선 불여우는 51.0.1, LibreOffice는 4.3.3.2 한글 담당자 찾아 따져야 겠어요.
Forums:
http://stackoverflow.com
http://stackoverflow.com/questions/26044322/dealing-with-korean-text-breaking-words
https://bugs.chromium.org/p/chromium/issues/detail?id=141792
눈에 단순해 보인다고 얕잡아 보는 거 아닙니다.
만약 그게 정말 몇 줄 패치만으로 가능한 일이라면,
만약 그게 정말 몇 줄 패치만으로 가능한 일이라면, 담당자를 찾아 따지는 것보다 직접 패치를 작성하시는 게 더 빠르게 문제를 해결하는 방법이 아닐까요.
혹은 귀하 대신 패치를 작성해 줄 개발자를 고용하시는 것도 좋은 방법이지요.
아쉬운 기능이 있으면 직접 구현할 수 있다는 게 오픈소스의 장점 아니겠습니까.
고맙게 생각합시다.
리브레오피스 관련 회사 또는 관련 개발자는
무상으로 배포하고 있습니다.
그들이 정성을 들여서 개발하여 사람들에게 도움되라고 무상으로 배포하는 것인데... 도와주지는 못할 망정
왜 이것밖에 안돼냐고, 왜 이 것 밖에 못해주냐고 따지는 것은 오픈소스 소비자 갑질입니다.
그리고 그 담장자가 당신 부하 직원이 아닙니다.
그리고 그 담장자가 당신 부하 직원이 아닙니다.
오픈 소스 소프트웨어는 공짜가 아니다. 자유
오픈 소스 소프트웨어는 공짜가 아니다. 자유 소프트웨어지 똘아이들아.
자유건 상용이건 버그있거나 심각한 오류가 있으면 사용자로서 비판하는 거야.
1990년대 초에 나온 아래 한글 문서작성기 한글 처리 수준도 못따라가니가 한심해서 쓴소리하는 거다.
오픈 소스가 뭔지도 모르는 좀비들이 익명에 숨어 댓글질하는 꼴이라니.
Devuan 1.0 (Debian without systemd)
amd64 station: AMD FX(tm)-6100 Six-Core Processor, 8 GB memory, 1 TB HDD
amd64 laptop: HP Touchsmart
글쇠판: 세벌 최종식, 콜맥 (Colemak)
물론입니다.
물론입니다.
귀하께서는 자유 소프트웨어를 실행하고, 복제하고, 배포하고, 연구하고, 변경하고 개선할 자유를 가지십니다.
물론 어떤 기능이 아쉽거나 버그를 발견했을 때 비판할 자유도 가지고 계시지요.
형식을 갖추어 버그 리포트까지 해 주신다면 자유 소프트웨어 사용자로서 상당히 모범적인 분이시지요.
다만,
1) 어떤 문제가 "소스 코드 몇줄이면 끝난다"는 식으로 말씀하시는 것은 적절치 않다고 생각합니다.
그 문제를 직접 해결하시려는 분들의 노고를 깎아내리는 것으로 들릴 수 있기 때문이지요.
문제를 해결하시고 나서 "그저 소스 몇 줄 고쳤을 뿐이다" 라고 말씀하셨다면 겸양의 의미로 들렸겠습니다만.
2) 담당자를 찾아 따져야겠다는 말씀 역시 적절하지 않습니다.
귀하께서 별도의 유지보수 계약을 맺으신 게 아니라면, 어느 누구도 귀하께서 바라시는 대로 기능을 구현하거나 버그를 고칠 의무를 가지지 않습니다.
3) 예의를 잃으시는 모습이 매우 보기 좋지 않군요.
귀하께서도 그저 닉네임을 걸어 두셨을 뿐 익명이나 다를 바 없지 않으십니까.
더군다나 공개된 자리에서 다짜고짜 말씀을 낮추시고 똘아이니 좀비니 하는 원색적인 표현을 쓰시다니요..
Bug#856817: It breaks all Korean words end of colum.
Package: libreoffice-writer
Version: 1:4.3.3-2+deb8u5
Severity: important
Hi,
Version: 4.3.3.2
Build ID: 430m0(Build:2)
Hangul is Korean alphabet that writes Korean speaking words. Each word is
combination of individual Hanguls such as English words. The space or newline
are separators of each word.
Commercial Korean word processors understand it and handle Korean words as
basic unit that composes whole sentence. If the sentence is longer than maximum
column, it pushes down the last word to the following line without breaking the
word's structure.
LibreOffice-writer ignores cohesion of Korean word and breaks any Korean words
at the end of column. Because of it writing a book or serious document demands
manual formatting of each sentence, which is absurd.
I give an example. Suppose there are five Korean words - AAA to EE - at the end
of sentence. Position of the 2nd D in DDD exceeds maximum column width.
AA BB CC, DDD EE
(아주 급한 가속, 과도한 멈춤,)
A Korean word proccesor handles it as below:
AA BB CC,
DDD EE,
LibreOffice-writer breaks DDD into two wrong words "DD" and "D".
AA BB CC, D
DD EE,
Until LibreOffice-writer fixes this outstanding problem, LibreOffice as a whole
package won't be welcomed by Korean users on any operating system.
I partly understand why Korean version of LibreOffice-writer in such sorry
state. Firefox, Chrome have exact same problem. I think one capable developer
who knows Hangul can fix it quickly.
Regards,
-- System Information:
Debian Release: 8.2
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages libreoffice-writer depends on:
ii libabw-0.1-1 0.1.0-2
ii libc6 2.23-5
ii libe-book-0.1-1 0.1.1-2
ii libgcc1 1:4.9.2-10
ii libicu52 52.1-8+deb8u4
ii libmwaw-0.3-3 0.3.1-2
ii libodfgen-0.1-1 0.1.1-2
ii libreoffice-base-core 1:4.3.3-2+deb8u5
ii libreoffice-core 1:4.3.3-2+deb8u5
ii librevenge-0.0-0 0.0.1-3
ii libstdc++6 4.9.2-10
ii libwpd-0.10-10 0.10.0-2+b1
ii libwpg-0.3-3 0.3.0-3
ii libwps-0.3-3 0.3.0-2
ii libxml2 2.9.1+dfsg1-5+deb8u1
ii uno-libs3 4.3.3-2+deb8u5
ii ure 4.3.3-2+deb8u5
ii zlib1g 1:1.2.8.dfsg-2+b1
Versions of packages libreoffice-writer recommends:
ii libreoffice-math 1:4.3.3-2+deb8u5
Versions of packages libreoffice-writer suggests:
ii default-jre [java5-runtime] 2:1.7-52
pn fonts-crosextra-caladea
pn fonts-crosextra-carlito
ii libreoffice-base 1:4.3.3-2+deb8u5
pn libreoffice-gcj
ii libreoffice-java-common 1:4.3.3-2+deb8u5
ii openjdk-7-jre [java5-runtime] 7u111-2.6.7-1~deb8u1
ii openjdk-8-jre [java5-runtime] 8u121-b13-3
Versions of packages libreoffice-core depends on:
ii fontconfig 2.11.0-6.3
ii fonts-opensymbol 2:102.6+LibO4.3.3-2+deb8u4
ii libatk1.0-0 2.14.0-1
ii libboost-date-time1.55.0 1.55.0+dfsg-3
ii libc6 2.23-5
ii libcairo2 1.14.0-2.1+deb8u1
ii libclucene-contribs1 2.3.3.4-4
ii libclucene-core1 2.3.3.4-4
ii libcmis-0.4-4 0.4.1-7
ii libcups2 1.7.5-12+devuan1.01
ii libcurl3-gnutls 7.38.0-4+deb8u5
ii libdbus-1-3 1.10.8-1+devuan1
ii libdbus-glib-1-2 0.102-1
ii libeot0 0.01-3
ii libexpat1 2.1.0-6+deb8u2
ii libexttextcat-2.0-0 3.4.4-1
ii libfontconfig1 2.11.0-6.3+deb8u1
ii libfreetype6 2.5.2-3+deb8u1
ii libgcc1 1:4.9.2-10
ii libgdk-pixbuf2.0-0 2.31.1-2+deb8u4
ii libgl1-mesa-glx [libgl1] 10.3.2-1+deb8u1
ii libglew1.10 1.10.0-3
ii libglib2.0-0 2.42.1-1+b1
ii libgltf-0.0-0 0.0.2-2
ii libglu1-mesa [libglu1] 9.0.0-2
ii libgraphite2-3 1.3.6-1~deb8u1
ii libgtk2.0-0 2.24.25-3+deb8u1
ii libharfbuzz-icu0 0.9.35-2
ii libharfbuzz0b 1.2.7-1+b1
ii libhunspell-1.3-0 1.3.3-3
ii libhyphen0 2.8.8-1
ii libice6 2:1.0.9-1+b1
ii libicu52 52.1-8+deb8u4
ii libjpeg62-turbo 1:1.3.1-12
ii liblangtag1 0.5.1-3
ii liblcms2-2 2.6-3+b3
ii libldap-2.4-2 2.4.40+dfsg-1+deb8u2
ii libmythes-1.2-0 2:1.2.4-1
ii libneon27-gnutls 0.30.1-1
ii libnspr4 2:4.12-6
ii libnss3 2:3.26.2-1
ii libodfgen-0.1-1 0.1.1-2
ii libpango-1.0-0 1.36.8-3
ii libpangocairo-1.0-0 1.36.8-3
ii libpangoft2-1.0-0 1.36.8-3
ii libpng12-0 1.2.50-2+deb8u2
ii librdf0 1.0.17-1+b1
ii libreoffice-common 1:4.3.3-2+deb8u5
ii librevenge-0.0-0 0.0.1-3
ii libsm6 2:1.2.2-1+b1
ii libssl1.0.0 1.0.1t-1+deb8u5
ii libstdc++6 4.9.2-10
ii libx11-6 2:1.6.2-3
ii libxext6 2:1.3.3-1
ii libxinerama1 2:1.1.3-1+b1
ii libxml2 2.9.1+dfsg1-5+deb8u1
ii libxrandr2 2:1.4.2-1+b1
ii libxrender1 1:0.9.8-1+b1
ii libxslt1.1 1.1.28-2+b2
ii libxt6 1:1.1.4-1+b1
ii uno-libs3 4.3.3-2+deb8u5
ii ure 4.3.3-2+deb8u5
ii zlib1g 1:1.2.8.dfsg-2+b1
-- no debconf information
Devuan 1.0 (Debian without systemd)
amd64 station: AMD FX(tm)-6100 Six-Core Processor, 8 GB memory, 1 TB HDD
amd64 laptop: HP Touchsmart
글쇠판: 세벌 최종식, 콜맥 (Colemak)
내가 바보이거나 똘아이인가?
오후에 윈도우 7깔린 다른 사람 노트북을 켜서 한글 2010이 있어 실행하고
한글 낱말 처리를 시험해봤다. 리브레오피스와 똑같이 낱말 구분을 못하고
폭보다 긴 낱말은 무조건 잘라 다음 줄로 넘긴다.
DOS시절 아래 한글로 논문이나 문서 작성할 때 아래 한글은 그때 당시 많은
사용자들의 관심과 사랑을 받았다고 기억한다. 286이나 386 컴퓨터에
아래한글 깔면 비싼 전자식 타자기가 못하는 문서 작업을 아주 편리하고
빠르게 할 수 있어서였지.
사람이 손으로 글을 쓰는 것과 똑같이 낱말 단위로 폭을 넘어가면 처리를 해주고
원하면 폭 너비에 맞게 자로잰것처럼 양끝이 맞게 공백도 넣거나 빼며 문단을 만들어 줬다.
수십만 원에서 수백만 원 돈을 내고 인쇄소에 맞겨야 했던 출판물을 개인이 하기 시작했다.
익명으로 댓글 싸지른 이들에게 묻고 싶다.
만일 어느 날 한자에 미친 세력이나 중국의 압력으로 아래 신문 기사처럼 한자 섞어쓰고 오른쪽에서 왼쪽으로 세로로 글을 써야 한다고 맞춤법을 개정한다면, 법이니까 개새끼처럼 아무소리 못하고 한자 배우고 즐겁게 문서 작성에 대여섯 시간씩 낭비할 것인가?
1957년 03월 16일 동아일보 기사
1970년 1월 10일 동아일보 기사
1962년 4월 14일 경향신문 기사
1967년 5월 16일 경향신문 기사
설마하는 마음으로 전에 사두었던 한글 맞춤법 책을 열어서 살펴봤더니 한글 낱말 개판이다.
대학 교수며 국어학자로 지낸 이가 한자에 미쳐서 한글과 한자의 기본 차이점도 모르고 맞춤법 책을 써놓았다.
좋은 글의 시작
올바른 맞춤법
최병선 지음, 동광출판사, 2005
예를 들면,
좀비로 변한 지식인, 전문가들이 날뛰고 있고, 나같은 비전문가나 사용자가 잘못된 점을 지적하면 한번정도 관심을 가지고 생각해보면 될걸, 개소처럼 비아냥 거릴 뿐이다.
2017년에 살지만 27년 전에 나온 아래 한글처럼 한글을 처리하는 문서작성기나 편집기가 없어 삽질해야하는 신세.
갈길이 참 멀다.
Devuan 1.0 (Debian without systemd)
amd64 station: AMD FX(tm)-6100 Six-Core Processor, 8 GB memory, 1 TB HDD
amd64 laptop: HP Touchsmart
글쇠판: 세벌 최종식, 콜맥 (Colemak)
국한문 혼용체나 세로쓰기를 부활시키자는 주장이
국한문 혼용체나 세로쓰기를 부활시키자는 주장이 나타난다면 저는 제가 할 수 있는 최대한 반대하고 저항할 겁니다.
어째서 제가 그렇게 하지 않을 거라고 단정하시는지 잘 모르겠습니다.
또 다른 비전문가이자 사용자인 제 입장에서 보면, 낱말 안에서 임의로 줄바꿈이 되는 문제는 다소 불편하긴 하지만 별로 치명적인 문제는 아닙니다. 리허설도 없이 스크립트를 그대로 읽어 연설해야 하는 상황 같은 게 아니라면 보통 텍스트를 읽을 때는 낱말을 재조립하며 읽을 만한 시간은 있기 마련이니까요. 게다가 단어를 적절한 지점에서 분철하지 못한다면 종종 레이아웃이 깨지는 문제가 생기더군요. 주로 텍스트 가로폭이 좁은데 긴 단어를 써야만 할 때 그러고는 하지요.
누군가 이 문제를 해결해주신다면 물론 좋겠지만, 별로 그렇게 아쉽지는 않습니다.
어쨌든, 귀하께서 진정으로 이 문제를 해결하기 위해 타인의 관심과 협조를 구하려고 한다면, 먼저 타인에 대한 존중을 갖추고 논리정연하게 설득하시는 게 바람직하지 않은가 하는 생각이 드는군요. 어느 누구도 귀하의 주장에 관심을 가져야 할 의무를 가지지 않습니다. 그러니 귀하에게 관심을 가지신 분들께 적절한 존중과 감사의 뜻을 전하지 않으신다면, 머지않아 아무런 관심도 받지 못하게 되신다고 해도 그다지 이상한 일이 아니겠지요.
개전의 여지가 보이지 않을 경우에는 저도 이 스레드에서 관심을 끊겠습니다.
관리자님께 andysheep 계정 블럭을 요청합니다
andysheep 님은 공개 게시판에서 썅욕을 하며 반말을 하고 있습니다.
kldp 사이트도 운영 규칙을 만들어서 저런 사람들을 블럭처리할 필요가 있습니다.
익명성 뒤에 숨어서 쌍욕하고 반말하는 것은 예의에 매우 어긋나는 행위이며 상대방에게 불쾌감을 주는 행위입니다. 애초 상대방에 대한 존중감이 있었다면 LibreOffice 라는 자유/오픈소스 소프트웨어 당담자에게 따지겠다는 표현을 하지 않았을 것입니다.
대부분의 오픈소스 라이선스가 그러하듯 LibreOffice도 유지보수의 의무가 없으며 면책 조항이 있습니다.
댓글 달기