Venti Americano: 2008

2008년 12월 30일 화요일

Joshua Tree

게으른 발걸음은
사진에서 나타난다.

열걸음을 더 걷고 안걷고의 차이.
어깨위의 삼각대를 펴고 안펴고의 차이...

더 이상 거리의 문제가 아니다.

대충 찍는 건
대충 나온다...

2008년 12월 27일 토요일

대형카메라: ① 과촛점거리와 DoC

대형카메라를 이용할때 가장 마음을 두근거리게 하는 것은 그 디테일과 박력이다.
디테일은 틸트/스윙등의 렌즈 무브먼트와 큰 조리개값의 도움으로 구현되는데, 항상 머리를 아프게 하는 것은 정확한 포커싱과 정확한 조리개값이다.
그 중, 적정 조리개값에 대해서는 순전히 감에 의존하였는데 이 부분을 나름 정리할 필요성을 느낀다.

...

Hyperfocal Distance에 대한 의문을 풀기 위해 googling과 excelling을 통해 다음과 같은 그래프를 만들었다.

45mm 렌즈를 f/11에 두면 과촛점 거리는 5.57m가 되며 near limit of DoF와 far limit of DoF는 각각 2.81m 와 무한대가 된다. 즉, 조리개가 f/11일때 5.57m에 포커싱을 하면 2.81m ~ 무한대는 촛점이 맞은 상태 (허용착란원:CoC 크기가 1/30mm 이하가 되는)가 된다.

그렇다면 f/11에서 촛점을 5.57m 가 아닌 다른 곳에 맞추면 어떻게 될까?

아래 그래프는 촛점을 5.0m 에서 5.56m 까지 변화 시킬때 DoF가 어떻게 변하는지를 계산한 것이다.
DoF Chart.jpg

Near Limit의 경우 촛점위치에 따른 변화가 거의 없는 것을 알 수 있다.

그러나 Far Limit의 경우 촛점 위치가 과촛점 거리에 가까워 질 수록 촛점위치에 따른 far limit의 변화가 급격하게 일어나는 것을 알 수 있다.

5.5m에서 5.56m로 변화 시킬때 far limit은 약 444m 에서 3,941m 로 증가 된다. 이러한 far limit의 증가는 어떤 의미가 있는 것인가?

만약 촛점 5.5m에 맞췄을때 far limit이 444m 이라면 444m 보다 멀리 있는 것들은 허용 CoC를 만족하지 못하고 완전 흐릿하게 (out of focus) 되는 것인가?

그렇지는 않다.
5.5m에 맞춰 있어도 아주 먼거리 (ex. 4,000m)의 피사체도 허용착란원 크기(0.03mm)내로 상을 맺는다.
그러나 촛점을 5.5m가 아닌 3m 정도에 맞추면 4,000m 거리의 피사체의 착란원 크기는 0.06mm 정도가 되어 허용착란원 크기인 0.03mm 에 비해 두배 커지며 해상도가 나빠지게 된다.

만약 촛점을 1m에 맞추면 4,000m 거리의 경우 착란원 크기가 0.19mm가 되어 6배 커지게 된다.

비록, 피사계심도(DoF)의 far limit가 변하더라도 이미 충분히 먼거리에 있는 경우, 그리고 촛점이 과촛점 거리에 충분히 가깝게 있는 경우라면 이 거리차이(과촛점거리 - 현재 촛점거리)가 상의 선명도에 끼치는 영향은 그리 크지 않으며 허용착란원 값과 비근한 값을 갖는다.

그렇다면 먼지를 털어내며: ② Hyperfocal distance & Infinite Focusing에서 보았던 과촛점거리에 촛점을 맞춘 경우와 무한대에 촛점을 맞춘 경우의 원경의 선명도 차이는 무엇으로 설명할 수 있을까?

Harold M. Merklinger는 이러한 부분에 의문을 품고 CoC(Circle of Confusion)를 이용하는 hyperfocal distance의 개념에 disk of confusion이라는 새로운 개념을 도입했다.

이 개념은 거리에 따라 얼만큼 큰 점(disk)이 필름상에서 구별이 되는지를 수치화 한 것이다. 촛점을 맞춘 거리에 존재하는 point는 당연히 필름상에 하나의 point로 상이 맺히며 구분이 된다. 그러나 맞춘 촛점 거리 보다 가깝게 있는 경우는 특정 지름을 갖는 disk 크기의 점(또는 object)들로 이루어진 것으로 보이게 되며 이 디스크보다 작은 크기는 필름 상에서 구별할 수가 없다.

위의 그림에서 카메라(즉, 렌즈)는 특정 촛점거리 D 보다 가까운 곳의 물체는 해당 지점에 위치한 크기의 푸른색 디스크로 이루어진 것으로 보게 되고, D 보다 먼곳의 물체는 붉은 색 디스크로 이루어진 것으로 보게 된다.

촛점이 D에 맞춰져 있고 X ( X < D) 위치하는 디스크의 크기는
Sx = d * (D-X) / D, where d is f/N (f : focal length of lens, N: f value of aperture)

물체가 Y ( Y > D )에 위치하는 경우
Sy = d * (Y-D) /D
로 정의 된다.

X 거리에 있는 물체는 지름이 Sx 이하인 경우 하나의 점으로 필름에 상이 맺히기 때문에 필름상에서 Sx 크기 이하의 물체/패턴에 대해서는 구분할 수가 없다는 것이다.

위의 수식을 이용해 계산해 보면 촛점이 5.56m에 맞춰져 있을때 카메라로 부터 4,000m 떨어진 곳은 지름 2.93m의 원형으로만 사물이 구분된다( Y=4,000m D=5.56m d=4.5cm/11). 즉, 일반 승용차 크기 이하는 구분이 어렵다는 것이다. 또한 렌즈와 50cm 떨어진 곳에 있는 물체의 경우 0.37cm이하는 구분이 안된다.

만약 촛점이 무한대로 설정되어 있다면, 4,000m 거리에 있는 물체는 0.4cm ( d = 4.5cm/11) 크기 디스크로 분해가 되기에 0.4cm 보다 큰 물체는 원형이 다 구분이 된다. 즉, 4,000m 거리에 있는 4mm 콩알이 구분이 될 수 있다는 의미이다. 물론 실제로는 렌즈의 회절 현상 등으로 인해 구분하기는 힘들다.

먼지를 털어내며: ② Hyperfocal distance & Infinite Focusing의 그림 ④를 다시 살펴 보자.

창문으로 보이는 부분의 구분이 과촛점거리를 이용해서 촬영한 윗쪽 이미지와 무한대에 촛점을 맞춘 아랫쪽 이미지에서 확연하게 틀림을 알수 있다. 관련문서를 좀 더 읽어 봐야 확실해 지겠지만, 이러한 차이는 Disk of confusion과 관련이 있는 것 같다.

그나저나 90여 페이지나 되는 분량이라 언제 다 볼런지...

2008년 12월 26일 금요일

먼지를 털어내며: ② Hyperfocal distance & Infinite Focusing

사진을 찍을때 마다 생기는 골치 중에 하나가 '과연 pan focusing이 잘 될까?' 라는 걱정 아닌 걱정이다.

사진을 좀 찍다 보면 듣게 되는 용어 중에 하나가 과촛점거리(Hyperfocal distance)라는 것이다.
특정 조리개에 대해 특정 근경 부터 무한대까지 촛점이 다 맞는 촛점 거리를 과촛점 거리라고 하는데, 정밀 포커싱을 하기 어려운 스냅사진이나 거리 촬영때 유용하게 사용하기도 하고 풍경을 촬영 할때도 유용하게 쓰기도 한다.

과연 과촛점거리를 쓰면 pan-focusing이 구현 되는 것일까?

아래 사진을 보자.

위의 사진은 삼각대에 거치한 EOS 5D + TS 45mm f/2.8 : 조리개 f/11 1/40"로 촬영된 이미지다

촬영 방법은 f/11에 해당하는 과촛점 거리에 포커싱을 맞추고 촬영했다. f/11에서 과촛점 거리에 맞추게 되면 3m ~ 무한대까지가 촛점이 맞게 된다. 엄밀하게 이야기 하면 촛점이 맞는 것이 아니라 허용 CoC( Circle of Confusion)의 한도내에 들게 된다.

가까운 난간은 대략 1m 거리에 있어 과촛점 거리 밖에 존재하게 되며 두번째 난간 부터 무한대까지는 촛점이 맞는다고 볼 수 있다.

과연 과촛점거리를 믿어도 되는 것일까?

이를 실험하기 위해 동일한 조건에서 촛점을 무한대에 맞춰 촬영한 다음 두 이미지를 비교 해 보았다. 그리고 ① ~ ④ 까지 네곳의 이미지를 확대해서 비교 해 보았다.

① 먼저, 가까운 난간 이미지 비교이다

이미지들은 원본 대비 300% 확대 한것이다.
카메라에서 1m 정도 떨어져 있기 때문에, 과촛점거리의 near focus limit 안쪽 범위에 있어 out-of-focus 되어 있는 것이 보인다.

그러나 과촛점거리에 맞춘 경우가 무한대에 촛점을 맞춘 것 보다 조금 더 촛점이 맞아 보인다.
난간 사이로 보이는 나뭇잎의 경우 카메라와의 거리가 3m 이상이므로 둘 다 촛점이 맞은 것을 알 수 있다.

'촛점이 맞았다'라는 말은 두가지를 의미할 수 있다. 렌즈를 포커싱을 했을때 어떤 사물 위의 한 점이

❶ 필름면에 점으로 표시되는 경우 (exact focus)
❷ 허용 착란원의 크기 이하로 보이는 경우 (in the depth of field) 인데,

❶의 경우는 카메라 렌즈로 부터 특정거리에 있는 사물들만 정확하게 점의 연속으로 필름에 상이 맺히게 되며(exact focus) 그 외의 경우는 전부 ➋경우이다.
➋의 경우는 심도(Depth of Field) 안에 있는 점들이 해당한다.

② 두번째 난간 부분을 확대한 사진이다.

이 경우도 과촛점거리 촬영의 결과가 더욱 선명해 보인다.
그렇다면 역시 팬 포커싱을 노릴때는 과촛점 거리를 이용해야 하는 것일까?

③ 이번에는 촬영 지점에서 50m 정도 떨어진 곳의 창문을 비교해 보자.

창문을 통해 보이는 blinder의 디테일을 보면 과촛점거리로 촬영한 왼쪽 이미지 보다, 무한대촛점으로 촬영한 오른쪽 이미지의 디테일이 훨씬 좋은 것을 알 수 있다.

④ 이번에는 무한대라고 볼 수 있는 건물의 디테일을 살펴보자.

이미지를 좀 더 잘 확인할 수 있게 레벨 조정으로 식별이 쉽게 하였다.
이 경우도 무한대 촛점 맞추기가 훨씬 더 선명한 이미지를 보여준다. 물론 거리가 멀기 때문에 빛의 회절현상으로 인해 흐려지긴 했지만 화살표로 표시된 건물의 유리창 부분이 확연하게 구분이 된다. 그러나 과촛점 거리를 이용한 경우 창문 부분이 거의 뭉게져서 보이는 것을 알 수 있다.

과연 과촛점거리의 유용성은 어떤 경우에 있는 것일까?

근경의 경우 과촛점거리로 촛점을 맞춘 것이 무한대 촛점에 맞춘 것 보다는 선명한 이미지를 가져다 주지만, 무한대 촛점을 맞춘 경우도 그리 나쁘지 않은 결과를 보여준다. 그러나 위치가 멀어질 수록 과촛점 거리는 기대와는 다르게 선명도가 나빴으며 오히려 무한대에 촛점을 맞춘 것이 결과가 더 좋았다.

이렇다면 풍경사진 혹은 근경-원경으로 이루어지는 구도에서 과촛점거리를 쓸 수 없는 것 아닌가! 그동안 경우에 따라 맹신하고 있던 과촛점거리에 대한 불신이 생기기 시작한다.

선명한 이미지를 얻기 위해서 우선 촛점 맞추기와 적절한 조리개 값 선정에 대한 이론적 근거를 공부해야 될 것 같다.

2008년 12월 23일 화요일

Mac mini에 멀티 서버 돌리기

드디어 Mac mini에 두개의 도메인을 설치했다.
하나는 현재 시험운영하고 있는 Textcube blog server이며, 다른 하나는 가족들간의 교류를 위한 Web Server이다.

두개의 서버는 각각 다른 도메인을 가지고 있어 apache 설정과 /etc/hosts 설정을 변경함으로서 간단하게 설치 되었다.

Web Server는 php와 연동이 되지 않는 간단하게 apache로만 운영되고 있으며, 저작도구로는 mac에 번들로 따라온 iWeb 1.1.2를 사용했다.
물론 제로보드나 현재 사용 중인 blog 소프트웨어를 사용할 수도 있지만, 가족싸이트다 보니 UI를 꾸미는데 skin 만으로는 한계가 있는 것 같아 iWeb으로 결정했다.
꼬맹이들과 할아버지, 할머니를 고려할때 제로보드 혹은 블로그 형태의 웹은 아무래도 적합해 보이지 않았기 때문이다.

iWeb을 이용하면 일반적인 웹페이지 뿐만 아니라 블로그 형태, 갤러리 형태 등을 꾸미는 것은 그리 어려운 일이 아니지만, php+MySQL 서버의 도움 없이 댓글을 어떻게 지원할 것인가 하는 부분이 가장 골치거리였는데 의외로 간단한 해결책을 찾았다.
시스코 출신의 프로그래머가 차린 js-kit.com 이라는 곳에서 제공하는 js-kit을 사용하면 어느 웹싸이트에서도 쉽게 댓글 기능을 제공할 수 있다.

다중 도메인 지원하기

하나의 컴퓨터 호스트에 할당된 도메인 외에 또 다른 도메인을 지원하기 위해서는 Apache server의 설정파일인 httpd.conf를 수정함으로서 간단히 해결 되었다.

① httpd.conf 파일에서 주석으로 처리된
# NameVirtual Host *
부분을 찾아 #을 지움으로서 enable 시킨다.

② 그 아랫부분에 다음과 같이 삽입한다.
<VirtualHost *>

DocumentRoot "/Users/user_id/Sites/default_http_root_directory"
ServerName localhost

</VirtualHost>
<VirtualHost *>

DocumentRoot "/Users/user_id/Sites/new_domain_root_directory"
ServerName new_domain

</VirtualHost>

이미 사용중인 http 디렉토리가 /Users/.../default_http_root_directory이고 신규로 설치할 도메인이 new_domain이며, 이 new_domain의 루트 디렉토리를 /Users/.../new_domain_root_directory로 설정할 경우이다.

유동 IP를 고정 IP로 바꾸어 주는 DynDNS를 사용하고 있기에 DynDNS에서 새로운 host를 하나 생성하고, 이에 따른 Webhop을 생성하면 설정 작업은 끝이 난다.

위의 작업을 개념적 그림으로 표시하면 위와 같다. 원하는 만큼의 도메인을 하나의 Mac mini에 mapping 할 수 있지만, DynDNS가 무료계정의 경우 5개까지의 호스트(Webhop 포함)만 제공하기 때문에 두개 이상의 도메인을 제공하기는 불가능 하다.

댓글 지원하기

댓글 지원은 댓글을 달기 원하는 웹페이지에 다음의 두줄을 삽입하기만 하면 된다.

<div class="js-kit-comments" permalink=""></div>
<script src="http://js-kit.com/comments.js"></script>

두번째 줄은 </html> 바로 전에 넣어주고 첫번째 줄은 댓글이 나타나야 할 곳을 찾아서 넣어 주면 된다. 댓글에 들어가는 font, color 등도 사용자화 할 수 있는데, 바탕색 설정을 어떻게 변경하는지는 아직 알아내지 못했다.

js-kit은 사용하면 댓글이 사용자 웹에 저장하는 것이 아니라 js-kit가 운영하는 서버에 저장된다. 따라서 댓글 지우기 등은 반드시 js-kit 서버에 접속한 후에야 가능하다.

js-kit은 php나 다른 서버의 도움 없이 댓글 기능을 제공할 수 있다는 것만으로, 다른 단점들(한글문제 등)을 극복하고도 남는 것 같다.

곱게 자란 Mac mini가 어느새 점점 마루따가 되어 가는 듯 하지만 한편으론 그동안 Mac mini의 능력 중 얼마나 활용 했었던가... 라는 점에서 반성을 한다.

2008년 12월 22일 월요일

먼지를 털어내며: ① Shenhao HZX45

어쩌다 보니 대형 카메라 그것도 4x5만 다섯대가 되었다.
쉔하오 HZX45
린호프 테크니카 클래식
린호프 테크니카르단
에보니 U2
Sinar F2

이건 카메라샾도 아니고 그렇다고 다른 매니아처럼 주제를 가지고 collection 하는 것도 아니고 어쩌다 이리 되었을까... 생각해 보면 어떨땐 한심하기도 하고 어떨땐 나자신이 이해가 되기도 한다.

처음으로 접했던 대형은 Sinar F2다.
알고 지내던 형님께서 거의 떠맞기다시피 공짜에 가까운 금액으로 주신 일종의 선물. 사진을 업으로 지내시면서 항상 작업을 도맡아 했던 카메라다.
세월이 흐르면서 디지털 작업이 많아 지니, 작업의 주역은 어느듯 디지털 카메라가 차지하고 4x5는 퇴역한 장성 처럼 명예직만 유지하고 있었다.

쓸쓸하게 밀려난 4x5를 가끔 올때마다 눈독 들이던 나에게 불하하신 게다.
표준렌즈로 135mm를 장착하고, 광각 벨로우즈 게다가 연장레일까지 있었으니 초보에겐 더할 나위 없는 기계였다.

그러나 모노레일형 뷰카메라의 단점인 무게와 벌키함을 이기지 못하고, 서브 4x5를 다시 장만했다.
해외 리뷰에서 가격대비 성능으로는 당시 최고로 평가 받던 마데제 쉔하오. 필드 목제 카메라를 구입한 정당성은 여러 가지가 있었지만

① F2를 멋지게 수납할 방법이 별로 없었다.
알루미늄케이스 같은 벌키한 것을 싫어했기에 배낭형 가방을 찾으려 했지만, 수납을 하려면 front/back stand 를 다 분리하고 삼각대 연결 부분 뭉치를 빼내지 않으면 왠만한 가방엔 넣기가 버거웠다. 당시 차가 없다보니, 대중교통 + 도보로 움직여야 했는데 F2는 쉽지가 않았다. 게다가 80키로의 연약한 몸으로는 더더욱... (① 번이 가장 타당하지 않은 이유지만 가장 타당한 이유였다.)

② F2는 실내 정물 촬영용으로 활용하고, 주로 쉔하오를 활용하면 될 것 같았다.
이 말은 F2는 현역에서 좀 더 멀어졌다는 뜻과 동일하다.

③ 장식용으로는 철제보다 목제가 훨씬 더 어울릴 것 같았다.
(점점 이유가 구차해 지지만, 그게 무엇이던 간에 나의 행동을 합리화 시킬수만 있다면 그것은 정당화가 되는 정신적 공황 상태였다)

요즈음도 그렇지만, 국내에서 대형카메라 관련 제품이나 정보를 접하긴 쉽지 않았고 특히나 마데제 아닌가.
달리 구할 방법이 없어, 쉔하오를 제작하고 있던 중국에 직접 e-mail과 팩스로 연락하면서 구입했던 기억이 새롭다.

Fedex로 물건을 받던 날 흥분과 실망이 교차 되었다. 4x5 목재 카메라를 구했다는 흥분은 카메라 케이스를 보는 순간 실망감으로 바뀌었다.
사진으로 보던 카메라케이스의 질감은 그대로 이지만 만듦새는 초등학교 저학년 여학생을 상대로 파는 문구점의 화장품 케이스와 별다를 바 없었기 때문이다. 카메라 케이스는 망설임 없이 바로 쓰레기통으로 버려졌다.

쉔하오의 장점은 그리 비싸지 않은 가격에 괜찮은 만듦새. 그리고 대형에서 해 볼수 있는 왠만한 무브먼트는 다 실험해 볼 수 있다는 것이다.
누가 대형을 하려는데 카메라를 추천해 달라고 하면 내 마음속으론 쉔하오를 먼저 떠오른다.

비록 정교한 컨트롤이라던가, 포커싱을 위한 knob의 정밀함은 떨어지지만 그야 뭐 어떤가. 목재 카메라가 가지는 단점이자 재미인걸... 단지, knob가 플라스틱으로 되어있고 크기가 좀 작아 장갑을 낀 손으로 조작하긴 불편한 점도 있지만...
이후 다른 카메라를 구하게 되면서, 활용도도 떨어져 구입고려시의 ③번 목적용으로 남아 있다.

티크를 사용했고 스텐인레스로 구성되어 있고 컴팩트 하면서 가벼운 무게. 그러나 무브먼트는 어떤 카메라에도 뒤지지 않는...보이그랜더 Bessa R을 가난한 자를 위한 Leica라고들 하지만, Shen Hao를 좀 많이 가난한 자를 위한 Ebony라고 부르면 무리일까?

다만, 플라스틱으로 만들어진 knob와 와셔의 체결력에 대한 불만이 있어 knob 교체 작업을 하면 새 새명을 얻지 않을까?
야외촬영시 서브 카메라로 활용할 계획으로 별도의 Abelson Scope Works의 pin-hole Turret을 구입 했지만 아직 장착도 못한 상태로 1여년을 보내고 있다.

비가 그치면 오랜만에 사진을 찍으러 나가 볼까...?

2008년 12월 20일 토요일

맥에서 프로그램 아이콘 가져오기

애플 스크립트!

가끔 맥에서 프로그램 아이콘을 사용해야 될 경우가 있다.
별도의 프로그램들도 존재하겠지만 손쉽게 아이콘을 가져올 수 있는 방법이 있다.

① Finder에서 프로그램을 찾는다.

② 원클릭을 한 다음 프로그램을 복사한다 ( cmd-C )

③ 미리보기(Preview) 프로그램을 실행한다.

④ 파일 -> 클립보드에서 신규를 실행한다.

또는

tell application "Finder"
	tell application "System Events"
		keystroke "c" using command down
	end tell
end tell

tell application "Preview"
	activate
	tell application "System Events"
		keystroke "n" using command down
	end tell
end tell

Apple script는 The Map TIpper Blog에서 참조 한 것임

위의 AppleScript를 응용프로그램으로 저장한 후, Finder의 툴바에 등록시킨 후 사용한다.
툴바에 등록은 해당 프로그램을 Drag해서 원하는 위치에 가져다 두면 되는데, 이때 원하는 위치에 끌고 간 후 조금 기다려야 툴바에 등록할 수 있다.
이것은 일반 Drag & Drop과 구분하기 위해서 OSX가 약간의 시간 간격을 두기 때문이다.

Skitch! Skitch! Skitch!

작고, 이쁘고, 편하고, 쉽고

블로그를 처음 만들기 시작하면서 고민이 되는 것은 이미지와 스크린샷을 어떻하면 쉽게 편집해서 삽입할수 있을까 였다.
스크린샷은 맥에서 기본적으로 제공하는 유틸리티인 화면캡쳐를 사용하면 되지만 캡쳐된 이미지를 가공하는 것은 또 하나의 일거리인 셈이다.

소잡는 칼을 아무곳에나 휘두를 수 없듯, 포토샵을 사용하여 다듬기에는 아무래도 무겁고 번잡스런 것도 사실이다.
이런 고민을 한번에 해결해 준 프로그램이 있는데 맥의 Comics Life를 개발한 Plasq에서 배포하는 Skitch 이다. 예전에는 초대권을 발부받고 나서야 프로그램을 다운 받을 수 있었다고 하는데, 현재는 무료로 제한 없이 사용할 수 있다.

Skitch를 좋하하는 첫번째 이유는 이쁘고 앙징맞다는 점이다. 프로그램 아이콘에서 느껴지듯 마치 10대 소녀들이 좋아할 것 같은 인터페이스는 프로그램을 사용내내 마음을 설레이게까지 한다.
기능을 확장하여 유아용 드로잉 프로그램으로 만들어도 아주 좋을 것 같다.

두번째는 수정된 이미지를 아무곳으로나 드래그 할 수 있는 점이다.
요즘 블로깅 툴로 사용하는 MarsEdit의 경우 이미지를 import하기 위해서는 파일을 선택해서 가져오거나 혹은 드롭을 해서 사용해야 하는데, 클리보드에서 복사해오기 기능이 없다. 그렇다 보니 이미지를 올리기 위해서는 파일로 저장을 한 후 가져와야 되는 불편함이 있다.

그러나 Skitch를 쓰면 번잡함을 한번에 해결해 준다.

세번째는 히스토리 기능이다. 히스토리란 Skitch가 import 했던 예전의 이미지를 다시 불러오는 것인데 그림/skitch 디렉토리에 저장되어 있다. 캡쳐 했던 이미지의 경우도 저장되어 있기 때무에 다시 불러 사용해야 될때 편리하다.

Skitch 가 제공하는 기능 중 Frame snap이라는 재미있는 기능이 있다.
기존의 캡쳐랑은 약간 다른 인터페이스를 제공하는 Frame capture가 있는데, Skitch의 화면이 캡쳐 frame으로 바뀌면서

frame을 통해 보이는 화면을 capture해 주는 기능이다.
만약, 업로드 혹은 참조하는 이미지의 크기를 통일해서 사용하고자 할때 frame 기능을 사용하면 같은 크기의 캡쳐 화면을 얻을 수 있어 편리하다.

한가지 아쉬운 점은 이미지를 로칼 파일로 저장하는 기능이 없다는 것이다. 물론 Skitch로 파일로 저장은 되지만, jpg/png 파일로 저장할 수 없어 copy & paste 혹은 drop을 이용해 다른 이미지 프로그램의 힘을 빌려야만 한다.

이것은 Skitch가 단독 이미지 프로그램으로 개발된 것이 아니라, 웹을 통한 이미지 공유를 목적으로 만들어진 skitch.com을 위한 프로그램이기 때문이다.
Webpost를 통해 이미지를 skitch.com이나 .Mac으로 바로 upload가 되기 때문에 파일 저장은 이 방식으로 해결할 수도 있다.

ImageWell과 더불어 요즘 가장 자주 사용하는 이미지 프로그램이다.

2008년 12월 19일 금요일

MacJournal 5.1.2 줄바꿈 걱정 해결

줄바꿈문제를 해결하다!

MacJouranl 5.1.2 가 12월 13일날 발표 되었다.

이 버젼이 뜻 깊은 이유는 그동안 텍스트큐브 블로그를 사용하던 MacJournal 사용자들을 괴롭혀 왔던 줄바꿈 문제를 해결했기 때문이다.

처음 개발자 Dan과 메일을 주고 받을때, 그리 탐탁치 않게 생각하더니 나중엔 못이기는 척 Preference의 Hidden Pane에 넣어 주겠다고 했다.
( 줄바꿈은 MacJournal이 할 일이 아니고 블로그 서버가 처리하는 문제라고 가볍게 여겼다 )

5.1.2 버젼 출시에 따른 Softpedia의 review 기사에 따르면 줄바꿈 기능이 차후 버젼에서는 기본 설정화 된다고 한다.

2008년 12월 16일 화요일

설치형 Textcubed에서 MarsEdit 사용하기

What You See is What You’ve Done

맥용으로 사용할 수 있는 제한된 블로깅 툴 중 MarsEdit가 있다.
Daniel Jalkut가 개발한 프로그램으로 Daniel은 애플의 소프트웨어 엔지니어로 근무 했으며 지금은 Red Sweater Software를 설립했다.

다른 프로그램들(ecto, MacJournal)과는 프로그램의 목표가 확연히 다르다.

어슬픈 WYSWYG editor를 제공하기 보다는 단순한 에디팅 툴만을 제공함으로서 화려한 WYSWYG을 기대했던 사용자에게는 당혹감을 주기까지 한다. 그러나 찬찬히 살펴보면 단순한 editor지만 사용에 있어 얼마나 많은 자유를 주고 있는지 알게 되면 감탄하게 된다.

더 보러 가기...

2008년 12월 8일 월요일

Headless Mac mini

Headless mini...
Mac mini를 서버로 사용하기 위해서 해야 할 첫번째 일은 키보드/마우스/모니터를 제거 하는 일이다. 그렇지 않으면 거추장스러운 입/출력기 때문에 mini를 자유롭게 원하는 곳에 둘 수가 없다.

모니터가 없는(또는 없이 사용하는) 컴퓨터를 ‘headless’ comptuer라고 부르는 모양이다. 어찌 보면 다소 살벌한 용어이지만, 인터넷에서는 그렇게들 부르고 있다.
일단 키보드/마우스/모니터를 이용하여 mini를 기본세팅을 한 후, System Preference/Sharing/에서 Screen Sharing을 enable 시킨다.

만약 mini에 bluetooth가 있다면 (사용 중인 1세대 G4에는 bluetooth가 없음), 설정 창에서 “입력 장비가 ...” 항목을 비활성화 시킨다.

이 옵션이 활성화 시켜 두고 사용을 하게 되면 mini는 입출력 장치가 없기에 Bluetooth 입출력 장치 찾기를 시도한다. 실패 하면 다음과 같은 다이얼로그 박스가 화면 제일 앞부분에 나타나는데, 매번 부팅시 마다 나타난다. 이를 방지하기 위해서 위의 옵션을 비활성 시켜야 한다.

Mac mini는 기본적으로 headless booting을 지원하기 때문에 OSX로 부팅 하는데는 문제가 없다. 그러나 Bootcamp나 ubuntu의 경우 headless booting이 불가능 하기에 monitor가 필수적인데, 이렇게 되면 small form factor인 mini의 서버로서의 가치가 떨어지지 않겠는가?
가장 손쉽게 이 문제를 해결 할 수 있는 방법은 $19에 팔고 있는 mac용 DVI-to-VGA connector를 구입하는 것이다 이 connector를 연결하는 것만으로 모니터가 달려 있는 효과를 낼 수 있으며 bootcamp나 ubuntu에서 headless boot을 할 수가 있다고 한다.

Leopard에는 Screen Sharing 기능이 내장 되어 있어 별도의 VNC Server & Client를 설치하지 않아도 된다. Chicken of VCN의 경우 매끄러운 원격 화면 처리등이 좀 떨어지는 듯하기 때문에 왠만하면 내장된 프로그램을 사용하는 것 좋다.
Leopard에서 Screen Sharing을 실행 하는 방법은 여러가지가 있다.
가장 보편적인 방법은 파인더 > 공유 부분에 나타나는 호스트를 클릭해서 직접 연결하는 것이다.

Screen Sharing 프로그램은 별도의 실행 프로그램으로 /System/Library/CoreService/ScreenSharing.app로 저장이 되어 있다. 이 프로그램을 실행하면 다음과 같은 윈도가 실행 되는데, 여기서 호스트를 선택하고 연결을 누르면 된다. ScreenSharing.app 를 Dock에 등록을 시켜 두면 여러 호스트에 접속해야 하는 경우 편리하다.

사파리에서의 탐색창에 vnc://ip-address 를 치는 것 만으로 Screen Sharing을 실행할 수도 있으며, 혹은 응용프로그램/유틸리티에서 터미널을 실행 한 후, 커맨더 라인에서 다음과 같이 입력하여 실행할 수도 있다.

open vnc://ip-address

...
글을 작성하면서 틀어놓은 Yellow Submarine의 화면을 동시에...
mini는 책상 건너편 Panasonic ELITE 42“와 dvi-hdmi 케이블로 연결되어 있고, 작업대에 있는 Mac Pro에서 Screen Sharing으로 영화 선택 & TV 프로그램 조작을 한다.

2008년 11월 30일 일요일

Kuwata의 추억...

학교 다니면서 프로그래밍 아르바이트를 하는 학생이 있었다.

여러가지 아르바이트 중 그래도 재미로 치면야 프로그래밍 만한게 없었으니까

시제품을 만들어 데모를 해야 하는데,

그것도 국내가 아니라 외국에서 한다니 아르바이트생은 정말 열심히 했다.

회사에서 먹고 자면서,

연구실을 땡땡이 치면서까지 말이다.

시간은 흘러가고,

데모 날짜는 다가오고,

게다가 국민의 반이 움직인다는 추석까지…

아르바이트생은 추석을 지내려면 고향인 지방으로 가야했지만

눈에 뭐가 씌었는지 그것마저도 포기하고

프로그램을 했다.

그 당시 처음 들어본 이상한 노래.

일본노래라고는 고등학교때 우연찮게 듣곤 했던 Kinginagini (by Kondo Masahiko)

그리고 대학때 친구들이 구해온 Kohibitoyo (by Mayumi Itsuwa) 정도였는데…

일본노래이지만,

일본노래가 아닌듯,

팝송인듯 하지만,

그렇다고 팝송도 아닌듯…

그 구수한 목소리로

텅빈 91년의 밤을 같이 보내준...

Keisuke Kuwata by Keisuke Kuwata

Kuwata의 노래 いとしのエリ, 그리고 Ray Charles가 부르는 Ellie My Love.

저는 いとしのエリ가 더 좋더군요.

유복성

배우 유오성의 형제가 아니다.

한국 재즈의 초창기 시절 타악기로 유명하신 유복성.

아마 20여년 정도 늦게 태어났다면...

기실 유복성이 TV에 비쳐졌던 모습은 음악인로서라기 보다는 여러 종류의 타악기를 소개하고 그 신기한 소리를 재미삼아 들려줬던 프로들이 대부분이였던 것 같다.

아마도 유쾌한 청백전(변웅전씨가 사회를 봤던)이라던가 그 외 명절날 특집 프로에 가끔 게스트로 나와서 봉고 연주를 주로 했던...

짐작이지만 방송 연출자의 주목적은 연주가 아니라 봉고가 내는 신기한 소리에 주안점을 뒀던 것 같다.

그건 아마 유복성씨의 조금 특이한 외모와 예능의 끼가 음악적 부분 보다 더 시청자에게 어필할 것 같다는 판단에서 그러했으리라...

3여년전 대학로의 한 재즈카페에서 연주를 들을 수 있었다.

그곳에는 TV에서 보이던 예능인이 아니라, 연주가로서의 유복성이 있었다.

장현

장현이라는 가수가 있다.

낮은 저음으로 읇조리듯 맛깔나게 노래를 하던 가수.

어쩌면 주류 가수로 분류되기엔 너무 시간이 흘러버렸고

그렇다고 가요무대에는 어울리지 않고

흘러갔지만 그래도 잊혀지기엔 아까운 옛노래 정도로 치부되어

그나마 가끔 박성연, 김준 등과 함께 한국 토종 재즈 가수로 TV에서 보거나 그도 아니면 신중현 이야기에 언급되는 그런 가수였다.

언젠가 부터 술을 한잔 먹거나 해서 노래를 부르게 되면 불러보던 장현의 노래...

그가 보금자리를 찾아 시냇물 흘러가듯 떠났다는 기사가 났다.

나는 너를

시냇물 흘러서 가면

넓은 바닷물이 되듯이

세월이 흘러 익어간 사랑

가슴 속에 메워 있었네

그토록 믿어온 사랑

내 마음에 믿어온 사랑

지금은 모두 어리석은데

이제 너를 떠나간다네

저녁노을 나를 두고 가려마

어서 가려마 내 모습 감추게

밤하늘에 찾아오는

별들의 사랑이야기

들려줄 거야

세월이 흘러서 가면

내 사랑 찾아오겠지

모두 다 잊고 떠나가야지

보금 자리 찾아가야지

작사/작곡 신중현, 노래 장현

...

장현의 노래를 mp3로 사보려고 여기 저기 기웃거렸지만 살수가 없었다.

ms window를 쓰지 않는 환경에서는 웹페이 조차 접속할 수 없는 곳이 태반이다.

Mac 외장 스피커의 잡음

Mac에 외장 스피커를 달아 음악을 듣거나 혹은 가끔 영화를 본다.

그런데 가끔 외장 스피커에서 이상한 잡음이 들리는 경우가 있다. 처음에는 스피커가 문제일거라고 생각도 했고, 스피커랑 본체를 연결한 선의 접촉이 문제일 거라고 생각도 했었다.

그런데, 이제 거의 원인을 찾은 것 같다.

과학적 근거는 없으나, 경험치에 바탕을 두고 추측한 결과 그 범인은

iPhone

잡음이 나는 경우의 대부분은 Mac 본체 근처에 iPhone이 있거나 혹은 iPhone이 USB cable로 연결되어 있을때 였다.

혹, 외장 스피커에서 잡음이 들리는 경우 iPhone이 근처에 없는지 확인 해 봐야한다.

다른 핸드폰의 경우는 잘모르겠지만 GSM iPhone이 뭔가 문제를 일으키는 것 같다.

2008년 11월 27일 목요일

SLOrk 노트북 오케스트라

악기 대신 노트북을 하나씩 들고 연주를 하는 오케스트라가 있다.

노트북의 사운드 기능을 이용한 것이 아니라 Macbook의 tilt sensor와 trackpad만을 이용한다.

Standford Laptop Ochestra (SLOrk)

이 오케스트라는 ChucK(다운받기) 이라고 하는 사운드 생성 language를 개발한 스탠포드의 Prof. Ge Wang(홈페이지)이 이끌고 있다.

Chuck을 이용해 작곡을 한 뒤, 단원들을 tilt sensor를 이용한 Macbook의 앞/뒤, 좌/우 기울기 그리고 trackpad의 가속 감지 기능을 이용한 손가락 움직임 등으로 소리를 왜곡 시켜 아방가르드 음악을 연주한다.

더 자세히 보기...

...

소리가 참 아방가르 합니다만,

컴퓨터의 계산능력을 이용한 프로그램적인 활용이 아니라 컴퓨터의 하드웨어를 활용한 시도는 신선합니다.

다중 블로그 관리하기

집에 놀고 있던 Mac mini를 웹서버로 만들어 설치형 Textcube를 설치해서 블로그를 하나 만들었다.

그리고, 현재 베타싸이트인 텍스트큐브.컴에도 만들었다.

태생이 같은 시스템이라 그런지 서로 비슷해서 초보 블로그인 나도 두 시스템에 쉽게 적응이 되어간다.

그런데...

두개의 블로그에 같은 글을 올려보면서 느끼는 점은 글관리와 더불어 원격 블로그툴에 대한 답답함이다.

ecto와 MacJournal을 번갈아 사용해 보기도 하고 같이 사용해 보기도 하지만, 어느 것도 모든 것을 충족시켜주지 못한다.

게다가 ecto의 경우 가끔, 자주 잘 죽는다.

물론 MacJournal 또한 그렇다.

프로그램이 죽는 것은 지난 20여년 동안 한결 같이 겪은 것이기에 새삼스런 일도 아니지만

나를 화나게 하는 것은 제대로 된 동작을 못하는 것에 있다.

ecto에서 편집을 한 뒤 블로그에 올리면 가끔 첨부된 그림이 사라진다. ecto의 문제인지 블로그 시스템과의 궁합 문제인지 모르겠지만, 오늘도 벌써 세차례나 사라졌다.

ecto는 서버와 클라이언트간의 글에 대한 일종의 sync 기능을 해주는데, 이 sync 기능이 가끔 프로그램을 멈추게 한다.

또 다른 문제는 ecto에서 RTF로 문서를 작성한 뒤 textcube로 전송을 하면 줄바꿈의 간격이 가끔 엉망이 된다. 특히 그림이 첨부된 경우 있지도 않은 빈줄이 삽입되거나 또는 사라지기도 한다.

원격브로깅 툴에서 글을 작성하고 업로드 한 뒤, 블로그의 내장 에디터를 이용해 다시 손질하는 바보같은 짓을 계속해야 하는 건가...

지속적으로 툴에 대한 고민을 해야 겠다.

2008년 11월 25일 화요일

ecto vs Textcube

맥에서 많이 사용하는(사용한다고 들었다) blogging tool로 ecto가 있다. 최신 버젼은 3.0b55이고 유료($17.95)이며 다음에서 21일 기간제한 프로그램을 다운 받을 수 있다. 프로그램의 아이콘에 보이는 사진이 아마도 개발자의 딸(Yukaree 아니면 Kee)인 것처럼 보인다.

MacJournal로 서버형 텍스트큐브 사용에 도전했다 물먹고 ecto로 도전했다.

블로그와 연동을 위한 세팅은 계정편집 메뉴를 수행해서 필요한 정보들을 입력하는 것으로 완료된다.

접근주소는 http://blog_homepage/api/blogapi (시스템마다 다름 ),
API 타입은 Movable Type으로 설정 한다. 텍스트큐브에서 Metaweblog Type으로 설정하면 글의 업/다운로드는 문제가 없지만, 블로그 태그를 지원할 수가 없다.

API 타입을 Movable로 정의하면 편집창의 메뉴에 키워드 항목이 보인다. 이 키워드가 텍스트큐브의 태그로 전달 된다.

글 수정 후, 블로그로 가보면 해당글에 키워드인 echo, Textcube, 설정, 태그, Mac이 블로그의 태그로 설정된 것을 확인 할 수 있다.

만약 API를 MetaWeblog로 정의하면 아래와 같이 ecto 편집기 창에 키워드 항목이 아래 그림과 같이 사라지게 되며, 키워드 입력 기능이 해제되어 태그를 정의할 수 없다.

ecto 편집창에 있는 태그 메뉴는 텍스트큐브에서 사용하는 태그와는 연동이 되지 않고, 본문 중에 삽입되는 technorati tag 이다. 아래 예는 ecto에서 태그로 tag1, tag2를 설정한 경우이다(텍스트큐브의 태그가 Technorati와 연동되는지 확인할 수 없다).

이렇게 설정하고 나면 ecto를 통해 거의 불편없이 텍스트큐브.컴을 즐길 수 있다.

MacJournal vs 설치형 Textcube

MacJournal은 왠만한 맥 사용자라면 한번쯤 이름을 들어본 journaling의 강자다.

Journal이란게 사실 그동안은 잘 몰랐는데, 미국사람들은 어릴때 부터 journal writing을 엄청 강조한다. 별다른 내용이 없어도 그냥 자기 생각나는 것들을 끄적거리는게 journal이다. 일기랑 비슷한거 같기도 하지만 차이점은 잘 모르겠다.

메모광인 지인의 강력한 추천도 있고 MacJournal로 원격블로깅도 할 수 있다는 말에 평가판을 다운 받고 테스팅을 했다.

MacJournal의 알려진 문제점은 다음 두 가지 이다.

줄바꿈이 제대로 안된다
분류가 지원이 안된다

두 문제점은 설치형 텍스트큐브인 경우에는 의외로 쉬운 해결책이 있다.

줄바꿈 문제

작성한 글이 MacJournal에서는 정상적으로 보이지만 블로그에 올리고 나면 한줄로 붙어 나오는 문제인데 몇차례 삽질 끝에 의외로 쉽게 해결책을 찾았다.

텍스트큐브 관리자로 로그인 후, 플러그인 설치에서 Textile 플러그인 설치
설정-글작성에서 기본포맷터로 Textile 지정

외국의 맥 블로거들은 MacJouranl을 사용하면서도 줄바꿈에 대한 불만이 없었기에 잘 알려진 Wordpress blog에 블로그를 하나 만들고 시험해 보았는데, 역시 줄바꿈 문제 없이 publish 되었다.

줄바꿈이 제대로 이루어지지 않은 이유는 무엇일까? 그 이유는 다음과 같이 않을까 짐작한다.

펼쳐두기..

:: 위의 해결방법은 설치형 텍스트큐브에만 적용될 수 있고, 호스트형 텍스트큐브는 편집 플러그인 지원이 없기에 적용되지 않는다.

분류지원 문제

줄바꿈을 해결하고 나니 텍스트큐브에서 정의한 분류가 제대로 작동하지 않는다. 이 역시 간단한 설정 변경으로 해결된다.

MacJournal에서 블로그 설정시 인터페이스 타입을 Movable Type으로 설정

텍스트큐브의 Blog API 타입은 MetaWeblog로 알고 있었는데 MetaWeblog로 설정하게 되 MacJournal이 분류(category)가 제대로 설정되지 않는다. 대신 Movable Type으로 설정하면 아무런 문제없이 분류정보를 가져오고, 설정된 분류대로 업로드도 된다.

줄바꿈도 잘되고 분류도 잘 지원하니 MacJournal은 아무런 문제가 없는 것인가?

여러 곳의 블로그에서 활동하는 파워블로그가 아니다 보니 ecto/MarsEdit 처럼 여러 블로그에 글을 올리고, 관리하고 하는 기능이 필요하지는 않다.

그럼에도 불구하고 그냥 사용하기에는 아쉬운 부분들이 많이 있는데...

테이블

MacJournal에서 아무리 그럴싸하게 문서를 꾸며도 텍스트큐브로 전송하고 나면 포맷이 엉망이 되는 경우가 허다 하다.

테이블이 한 예인데, 테이블 설정을 해서 자료를 입력한 뒤 블로그로 전송하고 확인을 해 보면 테이블의 위치가 엉망이 되어 버린다.

텍스트큐브 내장 에디터도 테이블을 지원하지 않기 때문에 테이블을 제대로 만들려면 내장 에디터를 통해 html과 씨름하는 수 밖에 없다.

들여쓰기

워드프로세스 처럼 화려한 기능을 원하는 것은 아니다. 단지 block quota 같은 단순한 기능이 필요한 것이다.

MacJournal의 편집기능에 단락 들여쓰기 기능도 나름 포맷기능이 충분하지만 텍스트큐브로 전송되고 나면 이런 포맷은 적용이 되지 않고 plain text로 변해 버린다.

그림 위치

MacJournal은 기본적으로 그림 삽입을 지원한다. 그리고 이렇게 삽입된 그림은 텍스트큐브와도 연동이 잘된다. 단지 아쉬운 점은, 그림의 위치에 대한 다양한 지원이 없다는 것이다. 단순한 배치 이상을 기대하기는 어렵다.

위의 사소한(어쩌면 중요한) 문제에도 불구하고, journal 자체의 목적에 중점을 둔다면 MacJournal은 사용이 간단하고 작성된 글을 효율적으로 관리할 수 있어 매력적이다.

그러나, 블로깅을 위한 툴로 MacJournal만 사용하기에는 문서 포맷팅 문제가 많이 걸린다.

현재까지의 결론은 MacJournal은 평소에 생각나는 글들을 쓰고, 포맷팅이 많이 필요하지 않은 문서의 업로드를 위한 툴로 주로 사용하고 다양한 효과를 위한 다른 툴을 찾아야 한다는 것이다.

텍스트큐브 하루 사용

이제 블로그라는 걸 접해본지 일주일도 안되는 왕초보 입니다.

블로그 시스템에 관심이 생겨 요 며칠 삽질 중입니다.

:: 외부 에디터 MacJournal과의 문제

1. 맥 + MacJournal로 글을 올린 후, 텍스트큐브에서 태그 설정 -> 외부 프로그램에서 내용 수정 후 재업로드 하면 설정했던 태그들이 사라진다. *항상*이라고 이야기 할 수는 없는 것이 가끔~ 어떤 경우는 남아 있기도 합니다(패턴은 모르겠군요)

2. 1번과 같은 경우에, 텍스트큐브에서 글을 '비공개'로 설정한 후 외부에디터에서 수정/업로드 하면 글이 '공개'로 바뀐다.

3. MacJournal에서 api를 MetWeblog로 설정하면, 최초 글을 올릴시에는 분류’ 항목이 정상 작동하는데 수정판을 올리면 분류가 변하지 않는다.
물론 type을 Movable로 바꾸면 정상 작동 한다. (MacJournal의 문제인지 시스템의 문제인지 판단이 안선다)

4. MacJournal 사용시, 줄바꿈 문제가 발생한다.
줄바꿈 문제는 아마도 MacJournal에서 내용을 보낼때 HTML로 줄바꿈을 처리하지 않은 상태로 보내서 발생하는 것 같은데, Wordpress 같은 곳에서는 제대로 처리해 주는 걸로 봐서 Textcube에서도 동일하게 처리해야 되지 않을까 한다.

내용을 화면에 display 할떄, CR/LF를 검출해서 자동으로 p-tag를 붙여서 보여준다
사용자가 BlogAPI를 활성화 시킬때 ‘줄바꿈 강제적용” 옵션을 둔다.

위와 같이 해결할 수 있지 않을까?

설치형 텍스트큐브는 내장에디터의 타입을 바꾸는 걸로 해결이 가능한데, 텍스트큐브.컴은 그러한 기능이 없기에 해결책이 없다

MacJournal 사용자 입장에서 1번과 4번 때문에 다른 방법(다른 프로그램 혹은 다른 서비스)을 찾게 만드는 주요인인 것 같다.

:: 수정(창으로)

설치형 텍스트큐브에서 글 수정 윈도를 실행한 후, 텍스트큐브.컴의 글 수정 윈도를 실행하면 이전 수정윈도가 없어지고 텍스트큐브.컴의 윈도가 대치된다. 이건 거꾸로도 그렇다.

또한 내글을 보는 도중 수정(창으로)를 누르고, 다른 글을 보다 또 누르게 되면 이전 창은 없어진다.(물론 command-delete로 이전창으로 돌아가기는 가능하지만...)

아마 ‘글수정 윈도’의 클래스(?)가 동일해서 그런것 같다.

:: 초보의 기능 건의 사항

트랙백 주소 간단 복사 : 글의 트랙백 주소를 마우스 클릭만으로 복사가 되면 편할 것 같다. 물론 스킨으로 처리할 수도 있겠지만, 기본 기능이면 더 좋을듯...
트랙백을 보낼때, 보낼 트랙백의 주소 뿐만 아니라 트랙백을 받은 글의 주소도 같이 저장할 수 있으면 좋겠다. 초보라서 그런지, 내가 트랙백을 보낸 글을 찾아가는게 쉽지 않다.
기본 관리자 화면의 첫화면이 ‘센터’인데, ‘글’이 되어야 되지 않을까 싶다. 물론 ‘추천포스트’는 좋은 정보를 주는데 사용자에 따라 다르겠지만 ‘글’ 항목의 빈도가 더 높지 않을까? 결국, 관리자 화면 설정을 제공해야 해결되겠지....?
글쓰기 창에서 현재 사용중인 글꼴에 대한 정보가 하나도 없다. 글자체, 그리고 특히 글자크기!
플래쉬 갤러리를 전체화면으로 실행할때 배경색을 지정할 수 있으면 좋겠다. 지금은 그냥 흰색(아니면 스킨의 기본 배경색인지 모르겠다)으로 되어 있는데 설정에서 옵션으로 제공하면 더 좋지 않을까?
글쓰기에서 이미지 끌어넣기나 클립보드에서 붙여넣기가 지원되던가, 이미지 올리기 창에서라도 끌어넣기/붙여넣기가 되면 좋겠다. 화면 캡쳐해서 넣기가 좀 번거럽다.