676

(56 답글들, 잡담하기에 작성)

제가 저 부분을 삭제한 장본인입니다. 사실, 저도 이유가 있어서 뺀 부분이기 때문에 저렇게 이의를 제기하시는 모습이 썩 좋게 보이지는 않는군요. 다만, 크롤러로 불리는 검색 엔진들이 저 태그를 없애면 잘 못 긁어간다는 부분을 사전에 고려하지 못한 점은 저의 불찰이라고 생각하고 있습니다. 네이버, 미안. 구글, 미안해~.

여기서 하나 드는 생각이, 왜 올블이 왜 웹크롤러로 태그 수집을 하는지 의문입니다. 올블은 회원이 직접 RSS 주소를 등록하고 올블 봇이 그 주소로 들어와 피드버너처럼 긁어가는 구조 아닌가요? 검색 엔진에도 진출하는 건가...

저도 나름 명분이 있고, 골빈해커님에게도 명분이 있으니 서로 터놓고 논의를 해야 하는 점이라고 생각하는데, 솔직히 골빈해커님이 저렇게 치고 나오시는 모습을 보니 기분이 좋지 않습니다. 이 포럼의 존재 목적을 잘 아시는 분이시니까 더욱 그렇군요. 본인의 블로그에서 저러실 게 아니고 직접 이곳에 오셔서 물어보시면 바로 답변을 얻으실 수 있으셨을 테니까요.

답변은 간단합니다. 사용자가 원하면 다시 넣습니다. 그러나 현재는 고정적으로 모든 포스트에 출력되던 rel="tag"를 사용자 선택으로 넘길 것입니다.

rel="tag"가 현재 지원하는 곳이 늘어나고 있는 것은 사실이지만 웹 표준은 아닙니다. 테크노라티에서 시작된 마이너리티 표준이고(웹 표준과는 상관없이 자신들의 편의를 위해 시작한 것입니다) 따라서 저희에게 그것을 따를 의무는 없으며 올블의 입장은 저희에게 그 문제에 대해 권고나 논의 요청을 했어야 하는 상황이라고 생각합니다.

주저리 딴 소리를 적고 있군요. 어쨌든 제가 rel="tag"를 삭제한 이유는 다음과 같습니다.

1. rel="tag" 기입을 스킨 제작자(또는 사용자)에게 넘긴다.

rel="tag" 사용에 관한 파이어준님의 글을 보면, rel="tag" 기입이 검색이 긁어가는데 얼마나 도움을 주는지 잘 알 수 있습니다. 태터툴즈 사용자 중 다수는 검색엔진을 달갑게 생각하지 않고 있고 저는 이 점에 주목했습니다. 그리고 내장 소스로 직접 기입하고 있는 rel="tag"를 스킨 차원에서 기입하게 하여 사용자가 검색엔진 노출에 대한 문제를 선택할 수 있게 하려고 했습니다.

2. REL attribute의 목적은 링크와의 관계를 정의하는 것입니다.

저는 REL의 정의상 tag라는 용법이 맞지 않는다고 판단했습니다. 이는 개인차가 있는 판단일 수 있으니 논의가 되어야 할지도 모르겠습니다. 태터툴즈 포럼은 언제나 논의가 진행되는 곳입니다. 사용자를 위한 논의라면 열린 마음으로 참여하겠습니다. 그러니 논의할 문제가 생긴다면 포럼에 오시면 좋겠습니다.

3. 한 페이지에 다수의 포스트가 같이 출력되는 경우 rel="tag"는 무용지물이다.

블로그의 첫 페이지는 태생적으로 다수의 포스트가 출력되게 되어 있습니다. 예를 들어, A, B, C 포스트가 같이 출력되고 있고 A, B, C에 각각 a, b, c 태그가 붙어 있다고 하겠습니다. 검색엔진은 A-a, B-b, C-c의 관계를 인식하지 못합니다. A-abc, B-abc, C-abc라고 인식을 하죠. 그냥 무식하게 페이지를 로딩해서 전체를 하나로 취급해 버리니까요. 이런 문제점도 rel="tag"를 삭제하도록 하는데 한 원인을 제공했습니다.




lunamoth 작성:

해당 부분에 대해서 논의가 되었으며, 추가될 예정입니다.

이상이 제가 rel="tag"를 삭제한 이유입니다. 다시 말씀 드리지만, 사용자가 원한다면 다시 넣습니다. 그러나 검색엔진이 원한다고 넣지는 않습니다. 저를 설득하시려면 논리를 가져오십시오. 논리가 타당하다면 동의해 드리겠습니다. 이상입니다.

PS 1. rel="tag"을 빼고 그것을 삽입할 수 있는 방법을 강구하지 않는 것은 저의 책임이 맞군요. 태터툴즈 사용자 여러분들께 사과 말씀 올립니다.
PS 2. 골빈해커님 블로그에 직접 글을 남기지는 않겠습니다. 좀 기분이 상했습니다. 골빈 해커님이 먼저 포럼을 무시하셨으니(여기서 질문을 하셨으면 바로 답변을 얻을 수 있음에도 안 그러셨으니까요) 저도 이번 건에 한해서는 무시하겠습니다.

677

(10 답글들, 스킨 및 플러그인에 작성)

아하하하하하...ㅡㅡ 무슨 에러일까...

678

(10 답글들, 스킨 및 플러그인에 작성)

Poon! skin Download

좀 복잡하게 만들어 봤습니다. 이름은 Poon!(Poon이라 적고 '뿐'이라 읽습니다) 스킨입니다. 플러그인과 스킨이 함께 묶여서 동작하는 테마입니다. IE6의 투명 PNG 요소는 개발/적용하고 있는 중인데요(기술 테스트는 완료), 일단 0.5 버전에서 공개해 여러분들의 피드백을 받았으면 합니다. 제 블로그를 만들어서 앞으로 지속적으로 업그레이드 할 예정입니다.

Poon! 테마의 구성요소.

1. Poon! 스킨
2. Poon! 스킨을 제어하는 Poon! 플러그인.
3. 방문자 카운터 사이드바 모듈.
4. 아날로그 시계 사이드바 모듈.(Vista 개짓에서 디자인 차용)
5. Poon! 스킨용 StatGraph 사이드바 모듈.

3, 4, 5는 2와 같이 묶여 있으므로 2를 활성화하면 자동으로 같이 활성화 됩니다. 현재는 플러그인 환경설정에서 설정을 변경하도록 되어 있지만 정식 버전에서는 관리자 플러그인으로 변경될 예정입니다.

Poon! 테마의 설치법

1. 다운로드 받은 Poon_Theme.zip의 압축을 푼다.
2. Poon_Skin은 skin 디렉토리에, Poon_Plugin은 플러그인 디렉토리로 옮긴다.
3. 플러그인 리스트에서 Poon! 스킨 전용 플러그인을 활성화시킨다.

플러그인 사이드바 모듈로 3, 4, 5도 같이 등록되므로 사이드바 설정에서 드래그앤드랍으로 사이드바에 추가/제거하실 수 있습니다.

Poon! 테마의 특징

1. 스킨 소스를 수정하지 않고도 배경 이미지와 헤더 이미지, 헤더 타이틀 이미지를 쉽게 변경할 수 있다.
2. 3가지 레이아웃이 제공되므로 취향에 따라 선택해 사용할 수 있다(추후 가지수 확대 예정).
3. 투명한 배경(PNG)을 지원하며, 사용자가 투명도를 제어할 수 있다.

주의하실 점

1. IE6에서 출력되는 디자인이 불완전하므로 컨셉 테스트 용도로만 사용해 주십시오.
2. GPL 라이센스를 따릅니다.
3. 플러그인을 활성화하지 않으시면 스킨이 제대로 출력되지 않습니다.

679

(5 답글들, 티스토리(TiStory.com)에 작성)

CN 작성:
daybreaker 작성:
1up 작성:

그것도 그렇지만 아이콘 이미지좀 바꿔줬으면 합니다.
아이콘의 흰색 부분이 투명처리 되있어서 바탕색이 흰색이 아닐경우에 이상하게 보여요.

반투명 PNG(32bit ARGB 색상)로 아이콘을 쓰면 좋은데, 문제는 IE6 이하가 지원하지 않는다는 문제가 있죠.

파일 첨부 아이콘은 많지 않기 때문에 핵을 써도 무방하지 않을까 싶습니다.

png behavior를 내장하는 것을 고려해 보도록 하겠습니다. 그런데 문제는 저 수많은 아이콘을 전부 투명으로 다시 만들어줘야 한는 건데요... 사실, 저도 저 아이콘들의 원본이 어디에 있는지 몰라요... 원본을 찾아야 투명으로 수정을 할 수 있는데... 쩝...

inureyes 작성:

플러그인중에 1.1.1 에서 동작하지 않는 것이 있는 것으로 보입니다. smile 한 번 다 끄고 테스트 부탁드립니다.

거의 99퍼센트 확률로 플러그인 중 fetchquery 계열의 태터 내장 함수를 사용하는게 있을겁니다. 그 함수 계열이 이번에 전부 deprecated 되었습니다. 원칙적으로 컴포넌트 이외의 함수를 플러그인에서 사용해서는 안되거든요. 최적화 프로그램 때문에 smile

일단 config.php에서 display가 off 되어 있을 거에요. 이걸 on으로 돌리시고 다시 해보시면 무슨 메세지가 출력될 수도 있습니다. 이 메세지가 있다면 알려주시겠어요?

inureyes 작성:

그런 경우를 제가 직접 겪고 있습니다. 동일 계정 동일 디비인데, 테스트용 블로그는 플러그인이 종종 꺼지고 원블로그는 전혀 그런 일이 없습니다. 관련해서 코드 리뷰를 했었는데, 다른 모든 조건이 동일한데도 발생해서 이게 왜 이러나 싶습니다.

사실 하나 딱 다른점이 있습니다. 모든 점이 똑같은데, 꺼지는 블로그는 테이블 첨자가 tt_trunk_를 쓰고 있고 안그런 블로그는 디폴트 첨자인 tt_를 쓰고 있습니다. 설마 이게 문제인가 싶어 코드를 확인했습니다만, 프리픽스는 다 제대로 들어가고 있군요.

설치한 환경과 설치시 첨자까지 모든 데이터를 좀 부탁드리겠습니다. 워낙 희귀한 일이라고 생각했었는데, 한 명 더 있다니 제대로 한 번 파고 들어야겠네요.

저는 이상하게도 사이드바 플러그인만 활성화가 안 된 적도 있었어요. 귀차니즘에 그냥 새로 설치하고 말았는데... (어이! 너 개발자 맞아??)

inureyes 작성:

그냥 잡담입니다만, 이 글 적을 시 아침에 메신저를 보니 온라인이신 분들의 백퍼센트 공통점을 하나 발견했습니다.

all solo ;;

그 아래 away로 빨간 분들은 전부 all couple ;;;;;;

솔로를 두 번 죽이시는군요.;;

683

(4 답글들, 아이디어 및 기능 제안에 작성)

작은인장 작성:

첫 번째 건의는 댓글 수정에 관해서입니다.
주인장으로서 댓글을 수정하면 댓글을 쓴 사람의 이름이 주인장으로 바뀝니다. 하지만 이 부분이 문제여서 원래 댓글을 작성한 사람이 누구인지 알 수가 없으므로 원래 글을 쓴 사람이 오해를 하거나 할 수 있습니다.

네, 이건 확실히 문제가 될 수 있는 부분이죠. 제가 전에 루틴을 바꾼 적이 있었는데, 여러가지 이유에 의해 revert 되었습니다. '방문자가 작성한 댓글을 관리자가 수정했다는 기록을 남겨야 하는가' 하는 부분에서 일단은 작은 인장님 말씀처럼 명시적으로 '관리자가 수정을 했다'는 문구를 보여주는 편이 상호 오해를 발생시키지 않을 수 있습니다. 그런데, 이 기록을 남기기 위해서는 현재의  DB  구조로는 좀 어렵다는 것이죠... 관리자가 방문자의 댓글을 수정했을 때를 위한 필드가 따로 필요하게 되는데... 이게 어지간 해서는 발생하는 상황이 아니라 필드 하나를 추가하는 것이 옳은 것인지 판단이 서지 않았습니다. 그렇다고 해서 제로보드처럼 본문에 "관리자가 수정했다"라고 텍스트를 추가하는 방식도 좋은 방법은 아닌데요... 악의적인 방문자가 악용할 수 있습니다. 그래서 이래저래 하다 여기까지 왔는데... 더 방치할 수 없는 시점이 된 것 같습니다. 뭔가 결론을 내서 이 문제는 반드시 해결하고 갔으면 하는데... 다른 분들께서도 좋은 의견 내주셨으면 합니다.

작은인장 작성:

또 손님의 댓글을 숨길 수 있는 기능이 없습니다. 숨기면서 주인장의 말을 등록할 수 있는 기능을 추가해 주셨으면 좋겠습니다.
또 방명록에도 숨김 기능을 도입해 주세요. ^^;

이 문제는... 현재 태터툴즈가 로그인 방식을 사용하지 않기 때문에 약간 구현이 주저되는 영역입니다. 부모 댓글의 패스워드를 입력하면 자식 댓글도 볼 수 있게 할 수 있지 않겠느냐라는 의견도 있으나, 댓글 리스트에 "비밀댓글입니다" - "비밀댓글의 답변 댓글입니다"라고 적혀 있는 상황에서, 재 방문한 사용자가 저 댓글이 자신이 올린 댓글이라는 점을 확인할 수 있는 방법은 문맥 뿐입니다. 즉, 앞뒤를 보고 자신이 적었던 비밀댓글을 찾는 수밖에 없는 것이죠. 그런데 여러면에서 이 문맥을 파악할 수 없게 되면, 사용자는 해당 게시물에 붙은 비밀댓글에 전부 비밀번호를 적어야 하는 상황을 맞게 됩니다. 행여나 비밀번호를 잘못 입력하기라도 하면 이게 자기가 잘못 입력해서 못 보는 건지, 관리자가 손을 댄 건지, 아니면 다른 이유가 있는 것인지 알 수가 없게 되는 거죠... 이처럼 현재의 시스템을 개편해도 현재와 비슷한 수준의 문제가 다시 발생하기 때문에 더하고 빼면 헛수고라는 결론이 나오게 됩니다. 따라서 다른 명쾌한 해법이 필요한데, 현재는 이 명쾌한 해법이 없습니다. 역시 다른 분들의 선견지명을 기다리고 있습니다.

작은인장 작성:

두 번째 건의는 주석에 관해서입니다.
현재 주석은 footnote라는 플러그인으로 구현되어 있는데, footnote는 줄바꿈이나 태그 등을 사용할 수 없어서 불편합니다. 또 화면의 이동이 크니까 불편할 때도 있습니다. 그런데 footnote가 또 편리할 때도 있습니다.
그래서 새로운 하나의 주석을 더 만들어 주실 것을 건의드립니다. 이 주석은 필요한 곳에 마우스를 대면 풍선말처럼 떠서 주석을 보여주는 형식이었으면 좋겠습니다. 줄바꿈이나 태그도 지원했으면 좋겠구요. (footnote도 줄바꿈이나 태그를 허용했으면 좋겠네요. ^^)
기왕이면 다홍치마라도 그림도 지원한다면 작은 그림을 넣어서 이해를 도울 수도 있지 않을까 생각합니다.

이건, gofeel님이 해결해 주실 수 있을 것 같군요. 태터툴즈 공식 플러그인은 아니지만,  gofeel님이 TNF 멤버이시니 이 글을 보시고 출력 형태를 결정할 수 있는 설정을 추가해 주시지 않을까 생각합니다. 일종의 압박? 흐흐흐흐...

정모한지도 꽤 됐습니다, 그려. 방학도 되었으니 한 번 모여봐야죠?

685

(4 답글들, 아이디어 및 기능 제안에 작성)

태터툴즈 DB가 UTF-8 기반이라서 ks_c_5601-1987로 출력하려면 글자를 하나하나 전부 변환해줘야 합니다. 더 이상 말씀 안드려도 다들 뭔소린지 이해하시겠죠? T_T

686

(16 답글들, 잡담하기에 작성)

3개월만에 주류에서 밀렸구나... ㅡㅡ

날개달기 작성:

1.1.0.2로 재설치하니 괜찮아지네요.

태터툴즈 1.1.1 정식 후보 1를 다른 폴더에 처음 설치를 해도 글이 안 보이는 건 마찬가지네요. ^^;
계정환경은 PHP 5.1.6, MySQL : 5.0.27입니다.

죄송하지만, 스크린샷 한 장 부탁드릴 수 있을까요?

diasozo 작성:

지난번 논의가 되었길래 이번에 수정된줄 알았는데
지금 보니 비밀글로 입력된 태그가 출력됩니다.
어찌 수정이 안될까요??

전 지금 티스토리 씁니다.

비밀글로 입력된 태그가 무슨 말씀인지 좀 더 설명 부탁드릴 수 있을런지요? 요즘 배포판에 거의 신경을 못 쓰고 있습니다. 죄송할 뿐입니다...

J. Parker 작성:
graphittie 작성:

커밋 권한 있으시지 않나요...? 그냥 필요한 거 있으시면 마음대로 추가하세요.;;

정말요? ^^; 그렇다면, 마음의 뜻에 따르겠습니다.~~
점심 식사 맛있게 하세요~~

그런 거 하시라고 드린 커밋권한이데요. 흐흐흐... 단, QA 단계에서 혹시 잘릴 수도 있으니 알고 계시고요. 참고로 말씀드리자면 이벤트는 여태까지 잘린 적이 한 차례도 없었습니다.

잘 나오고 있는 것을 확인했습니다. 파일이 잘못 업로드된 것이 아닐까요. 종종 파일이 불완전하게 업로드되어 레이아웃이 깨지는 상황을 겪는 분들이 계셨습니다...

Ikaris C. Faust 작성:
LonnieNa 작성:
laziel 작성:

...1기가짜리 백업파일 만들어드릴까요?[..]

text로 1G라... -0-

제 컴퓨터에 들어있는 소설로는 3GB도 나오는걸요;;;

어지간하면 사서 보시길 권장합니다... ebook을 구매하신 것이라면 송구스러울 뿐...

커밋 권한 있으시지 않나요...? 그냥 필요한 거 있으시면 마음대로 추가하세요.;;

가로줄 달력의 저장방식에서 문제가 생기는 것 같습니다. 해당 플러그인의 index.php 파일을 여시고 새로 저장하시면서 Unicode Signature를 삭제하세요. 이게 무슨 말인지 이해불가시라면, http://www.emeditor.com에 가셔서 emeditor라는 편집기를 받으신 후 이 프로그램으로 가로줄 달력 플러그인의 index.php 파일을 여시고 새로 저장(영문으로는 save as...) 메뉴를 선택, 나오는 다이알로그 창에서 "Add a Unicode Signature(BOM)"의 체크를 해제하고 저장하세요. 아마 "덮어쓸까?" 비슷한 내용의 창이 뜰 텐데 OK하시면 됩니다.

PS. 해당 플러그인의 문제는 제작자에게 질문하는 것이 가장 빠른 해결책을 얻는 길입니다.

htna 작성:

관리자 모드에서 글을 읽을때...
각 글당,
"Change status to Private | edit(win) | delete | trackback"
의 선택 메뉴가 있습니다만.
여기에, change category to 정도와 같은 메뉴가 있으면 좋을 듯 하군요...
"Change status to Private | Change category to | edit(win) | delete | trackback"
"Change category to"를 클릭하면, 카테고리 트리를 보여주는 popup window가 뜨면서, 하나를 선택하면 지정된 article의 category가 변경되는...

따로 그 부분만 빼내야 하는 이유가 잘 납득이 되지 않는데요... 음...
카테고리 변경절차가 더 간편해진다고 하면 타당성이 있어 보이는데, edit를 누르면 창 하나 뜨고, 카테고리 변경하고, 저장하고 끝...과 비교했을 때 동선에서 얻을 수 있는 이익은 없다고 생각합니다.
이 부분이 추가되었으면 하는 적절한 이유를 같이 제시해 주시면 이야기하는데 더 편하지 않을까 합니다.

흐흐;; 자답하셨네요... 죄송해라...;;

696

(2 답글들, 아이디어 및 기능 제안에 작성)

컴ⓣing 작성:

제로보드와 같은 경우에..
같은 내용이 입력되는 것을 검사를 하는 것 같습니다..

(".. " 이런 것들 이죠...)

스팸 트랙백을 보면 같은 내용의 글이 많이 올라오는데, 일단 동일한 내용만 걸러낼 수 있도록만 해도

스팸트랙백이 많이 줄어들지 않을까요??

같은 글을 걸러내는 것을 제로보드에서도 구현한걸로 보면.. 서버에 무리가 가지 않는 한도내에서
검색할 수 있는 것 같은데..
(제가 개발쪽을 잘 몰라서 그게 아니라면 죄송합니다..;;)

제가 얼핏 듣기로 물 건너 스팸업자 중 누군가가 태터툴즈를 분석하고 스팸을 날리고 있다고 하더군요. 뭐, 저 방법이 실효가 있을지도 모르겠지만 금방 또 분석해내고 다른 공격/회피법을 알아내겠지요... 결국 막고 뚫고의 반복이 되는 겁니다. 먼저 나가 떨어지는 쪽이 지는 쪽... gendoh님 화이팅...;;

697

(17 답글들, 잡담하기에 작성)

아놔. 커플은 오늘 전부 출근햇!!:|

inureyes 작성:
CN 작성:

툴팁의 경우 많은 정적 레이어로도 구성될 수 있을텐데 단순 롤오버는 CSS 수준에서도 어느정도 지원할 수 있으니 보여줄 수 있을 것입니다. 하지만 그 경우 속도가 문제가 될 것 같습니다. 물론 느리다는 것도 생각일 뿐이니 얼마나 느려지는지 실제 테스트를 해봐야할 것 같습니다.

css 렌더링 속도 관련해서 테스트가 필요하겠군요. 아윽 =_= 1.1 개발 초반에 고생하던 생각이...

그라피티에님 ~ (자꾸 불러서 죄송하지만) 테스트와 처리좀 부탁드려요^^ (CN님에게 결자해지의 칼이 있지만 핑백 부탁을 드려야 하기 땜에;; )

이거야 뭐... CSS 롤오버는 이미 이미 로딩된 이미지 파일을 background-position으로 장난쳐서 얻는 결과이기 때문에 속도에는 문제될 것이 없습니다. 다만, 관리자 화면의 글 목록에서처럼 자바스크립트를 이용해서 class 장난을 치고 거기에 CSS 롤오버를 입히면 IE6에서 아~주 느려지죠.

포엠 작성:

태터&컴퍼니에 사이다님이 올린 글입니다.

----------------------------------- 원문 -----------------------------------
이미지를 올릴때 -> 두개의 파일을 중앙정렬, 세개의 파일을 중앙정렬
이렇게 하면 background에 흰색이 채워집니다.

하나일경우 가운데 정렬이나 프리일때 또는 이미지 갤러리일때는 흰색이 없는데 유독 두개와 세개일때만 흰색이 포함됩니다. 왜 그런거죠?
클랙식 버전이하 0.9x에서는 흰색이 채워지지않았는데 1.x로 올라오면서 생긴것 같습니다.

container영역이 흰색으로된 스킨에는 사용하는데 큰 무리는 없지만
다른색으로 쓰인 스킨에 좀 영향이 있네요.

혹 이 흰색을 없애는 방법이 있을까요? 없다면 다음 버전업하면서 이것을 빼주셨으면합니다.
------------------------------------------------------------------------------

저도 이게 궁금했는데 어떻게 방법이 없을까요? 예전같이 하는것이 좋을것 같은데요....

태터툴즈 자체에서는 배경색을 넣지 않고 있습니다. 즉, 스킨의 CSS에서 배경색을 넣고 있는 것으로 보입니다. 현재 1.1에 기본으로 포함되어 배포되고 있는 tistory 스킨의 경우가 위와 같이 처리를 하고 있습니다. style.css에서 해당 부분을 찾아 background-color 속성을 지워주시면 해결됩니다.

rEwritemaster 작성:

그리고 텍스트모드에서 줄바꿈이 br로 변환되지 않는것도 텍스트모드로 글 작성하는것에 좀 더 부담을 주지 않을까요?

이게 좀 난감한 문제라... 자동 <br/>이 입력되지 않기를 바라는 사용자도 있습니다. 자동 줄바꿈 기능은 \n을 전부 <br />로 바꿔주다보니 원하지 않는 곳에 <br />이 추가되기도 합니다. 그렇다면, <br />이 안 들어갔으면 하는 유저와, <br />이 들어갔으면 하는 유저가 있다는 것인데, 왜 <br />이 안 들어갔으면 하는 유저의 손을 들어줬는가 하면(표현이 좀 이상하군요...) HTML 모드는 HTML의 편집이 자유로워야 하기 때문입니다. 보통 HTML 모드를 쓰시는 분들은 깔끔하게 semactic 편집을 하시는 분들인데, 그 분들에게 <br />은 손댈 수 없는 영역이 되는 것이죠. 자동으로 들어가 버리니까요. 그래서 일부러 플러그인을 만들어 자동입력된 <br />을 다시 \n으로 되돌리는 사용자도 보았습니다. 에디터 <-> HTML 모드의 변환에서 문제가 발생하고 있는 것 같아 죄송스럽습니다만 차츰 개선하도록 해야겠지요.