Ygdrasil

The term 'terminal' in gnuplot means a medium on which it draws graphs. If your gnuplot gives error message like :

shawn.deltabellun:~$ gnuplot

    G N U P L O T
    Version 4.2 patchlevel 4
    last modified Sep 2008
    System: Darwin 10.3.0

    Copyright (C) 1986 - 1993, 1998, 2004, 2007, 2008
    Thomas Williams, Colin Kelley and many others

    Type `help` to access the on-line reference manual.
    The gnuplot FAQ is available from http://www.gnuplot.info/faq/

    Send bug reports and suggestions to <http://sourceforge.net/projects/gnuplot>


Terminal type set to 'unknown'
gnuplot>

It means that it could not find available terminal on your system. BTW, you can check the list of terminals by typing "set terminal" or "help terminal".

Once you got this message, you should doubt whether your installation went wrong, especially when you are installing gnuplot by COMPILING it.

My environment :
    OS: OSX 10.6.3
    X : XQuartz 2.5.0 (http://xquartz.macosforge.org/trac/wiki)
    gnuplot : 4.2.4

The configure script of gnuplot 4.2.4 can't seem to locate X11 library. I had to give the location of X11 library to the configure script as following :

./configure --with-readline=/usr/local/lib --x-libraries=/usr/X11/lib/ --x-includes=/usr/X11/include/ CFLAGS=-I/usr/local/include LDFLAGS='-L/usr/local/lib -L/usr/X11/lib'

If the configure script recognizes your X11 libraries, it should give these messages while configuring :

...
checking for PDF_get_majorversion in -lpdf... no
checking for multi-byte support in x11... checking for XmbDrawString in -lX11... yes
checking for g++... g++
...
  Standalone terminals: yes (always builtin)
    (aed512, aed767, aifm, bitgraph, cgm, corel, dumb, dxf, eepic, emf, emtex,
    epslatex, epson_180dpi, epson_60dpi, epson_lx800, fig, gpic, hp2623A,
    hp2648, hp500c, hpdj, hpgl, hpljii, hppj, imagen, kc_tek40xx, km_tek40xx,
    latex, metafont, metapost, mif, pbm, postscript, pslatex, nec_cp6, okidata,
    pcl5, pstex, pstricks, qms, regis, selanar, svg, starc, tandy_60dpi,
    tek40xx, tek410x, texdraw, tgif, tkcanvas, tpic, vttek)
  x11/xlib terminal: yes (with mouse support)
    (with multi-byte fonts)
    (with binary polygon protocol (EXPERIMENTAL))
  jpeg terminal: no (requires libgd with jpeg support)
  gif terminal: no (requires libgd with gif support)
...

After you have compiled with configure options shown above, you would read "Terminal type set to 'x11'" when you start gnuplot.

BTW, It was just fine with OSX 10.5. No "no Xlib" problem. It may be the problem of OSX or XQuartz 2.5 (released Mar. 29, 2010)

good luck.

/Applications/MacVim.app/Contents/Resources/vim 아래의 gvimrc 를 보면, colorscheme 을 MacVim 으로 바꾸어 버리는 부분이 있다. 여기를 주석처리하면 OK!

MacVim colorscheme 정말 촌스럽고 싫다 -_-;;

애플 유저들 사이에서 흔히들 "회색 콩의 저주"라고 불리우는 마이티 마우스의 트랙볼 문제가 있다.

트랙볼에 때가 끼어서 스크롤을 할 수 없는 상황인데, 트랙볼을 빼 내어서 청소할 수 있는 방법이 없기 때문에 결국 사용하던 마우스를 버리고, 새 마우스를 살 수 밖에 없는, 무서운 저주인 것이다.

사무실에서 사용하던 내 마우스도, 잡기 전 항상 손을 정갈하게 하고서 사용하도록 주의를 기울이고, 주기적으로 물티슈로 목욕도 시켜 드려 왔건만, 근 2 년 만에 회복할 수 없는 상태에 이르러 버렸다. 아무리 A4지에 문대고, 물티슈로 꼼꼼하게 닦아 주어도 살아날 생각을 하지 않으신다. 그래서 http://www.applematters.com/index.php/gallery/category/C4/ 이 사이트의 사진을 보고 마이티마우스를 분해해서 청소하기로 마음먹었다.

아주 힘들(!)었지만, 15분 가량의 분해 및 조립 작업 끝에, 아주 새 것처럼 산뜻한 트랙볼 스크롤감을 회복할 수 있었다.

아쉽게도 사진을 찍지 못했지만, 이번주 내로 사진을 찍어서 분해시, 그리고 조립시 주의점을 자세히 설명해 보려고 한다.

아~~~ 산뜻해!!

그러나 이것도 잠시... 위,아래,오른쪽 스크롤은 잘 되는데 이번에는 왼쪽 스크롤이 안된다. 필시 4개의 롤러 중 하나가 운명을 달리한 듯 하다. 롤러에 보면 볼과의 마찰력을 증가시키기 위해서 엷게 고무 같은 것이 발려 있는 것을 볼 수 있는데, 거기에 오공본드로 본드질을 좀 해서 보충시킨 후 다시 해 봐야 겠다.

----

보충재를 칠할 경우, 균일하지 않는 스크롤감으로 인해 오히려 더 불편했다.

저주받은 회색콩이 되는 이유는 아래에서 보겠지만, 내부의 해머(?)의 손잡이에 발라져 있는 패드(?)가 닳아서인 것으로 추정되며, 본드 등으로 보충해 봤자 허사다. 닳은 해머를 잘 쓰지 않는 쪽의 생생한 해머와 바꾸어 줌으로서 자주 쓰는 스크롤이나마 잘 되게끔 할 수 밖에 없다.

----

이제, 분해법을 사진과 함께 알아보자.

1. 고무 링을 분리하는 것이 위에서 언급한 사이트의 첫 단계였는데, 분해 해 보니 회색의 고무 링은 분리할 필요가 없을 듯 하다. 아무튼, 분해해 버렸으니 사진은 싣는다. 그림처럼 넓직한 쇳조각을 과감히 틈새에 찔러 넣은 후 조심해서 들어 올리면 쉽게 분해된다. 일자 드라이버를 이용하는 것도 괜찮은 선택이다.

아래 사진과 같이 도구를 회전시켜서 고무링을 들어 올리면 보다 쉽고 안전하게 분해 가능하다.

2. 이번에는 흰색 프라스틱 링을 분해할 차례인데, 이녀석은 접착제로 마우스 상판에 고정되어 있기 때문에 분해하는 데에 힘이 좀 든다. 게다가 프라스틱 재질이라 두동강 날 위험도 있으므로 과감하면서도 섬세하게 작업을 해야 한다.

우선, 양 사이드 부분을 들어올리고 난 후, 긴쪽의 머리와 꼬리를 들어올리면 대개 무난하게 두동강 나는 일 없이 분리가 가능하다. 위에서 언급한 사이트에 가면 비극적으로 두동강난 프라스틱 링의 사진을 볼 수 있으니 한번 확인한 후 경각심을 가진 상태에서 작업하도록 하자.

두 개의 링을 모두 분리한 모습이다 :

이번에는 마우스 바닥의 뚜껑을 열 차례이다. 아래 사진에서 보듯이 지렛대를 이용해서 들어올리면 '탈칵'하는 경쾌한 소리와 함께 마우스가 입을 벌리게 된다.

아래는 입을 벌린 사진 :

위 사진에 적어 두었듯이, 마우스의 내부에 힌지가 있어서 위 사진에 표시한 부분을 축으로 입을 벌리게 된다.

그래서 상판을 분리할 때, 힌지가 부서지지 않도록 아래 사진에서 화살표로 표시해 둔 부분을 손가락으로 살짝 누르면서 상판을 들어 내면 가볍게 분리가 된다. 주의할 것은, 상판과 하판이 FPCB로 연결되어 있기 때문에 상판을 떼었다고 좋아하면서 급하게 상판을 멀리 떼어내어 버리면 마우스를 버려야 하는 사태가 발생할 수 있다는 것이다.

이제, 상/하판을 서로 완전히 분리하기 위해서 하판에 꽂혀 있는 FPCB를 소켓(?)에서 분리해 낼 차례인데, 나중에 조립할 때를 생각해서 네임펜이나 매직 등으로 좌/우를 미리 표시해 두는 센스를 발휘해 보자. 아래 사진을 참조한다 :

아, 그리고 FPCB는 무식하게 힘으로 빼도 되지만, 아래 사진에서 보듯이 소켓(?)을 살짝 들어올리면 헐렁하게 빠지기 때문에 무리해서 힘으로 빼지 말자. 물론, 조립할 때에도 소켓의 입이 벌어진 상태에서 FPCB를 집어 넣고, 입을 닫으면 부드러운 FPCB에 손상을 가하지 않고 삽입이 가능하다.

FPCB 가 두 개가 있는데 모두 같은 요령으로 분리.

아래 사진은 입을 완전히 벌린 소켓(?).

상/하판 분리가 끝나고, 문제의 근원인 저주받은 회색콩이 누워 있는 곳이 드러났다 :

작은 드라이버를 이용해서 나사못을 풀고 나면 아래 사진과 같이 회색콩을 볼 수 있게 된다. 정말 정밀하게 되어 있는데, 이걸 틀림없이 사람이 조립할 텐데, 이렇게 정교한 구조로 되어 있어서 생산 능률이 과연 얼마나 될까 하는 생각이 든다. 그래서 이놈의 마우스가 그렇게 비싼 건가 하는 생각도 해 본다.

사진에 보이는 검정색 롤러는 자석이라서, 철제 드라이버를 이용하면 손쉽게 다룰 수 있게 되어 있다.

아마도 트랙볼(회색 공)을 돌리면 자석으로 된 롤러가 돌고, 거기 따라서 전류가 발생해서, 입력을 감지하는 원리인 듯 하다.

이제, 회색콩과 롤러들을 제 자리에 위치시켜서 고정하고 있는 흰색 캡을 분리할 차례이다. 그냥 아무 생각 없이 캡을 들어 내면 콩 아래에 존재하는 스프링때문에 콩이 날아가 버릴 수 있기 때문에, 손가락으로 흰색 캡을 눌러준 상태에서 캡을 들어 올려야 한다. 아래 사진처럼 드라이버를 이용해서 윗쪽으로 살짝 들어올리면 가볍게 틱 소리가 나면서 분리된다 :

흰색 캡을 들어낸 후의 모습. 위의 사진(두개 위의 사진)에서는 롤러의 검정 자석이 벽에 있는 쇳조각에 붙어 있지 않지만, 캡을 들어낸 아래의 사진에서는 캡이 분리된 이후라 벽에 있는 쇳조각에 가서 찰싹 달라붙어 있는 것을 볼 수 있다.

앞서도 이야기했듯이 검정색 롤러는 자석이라 철제의 드라이버에 아래 사진처럼 착 달라붙는다. 롤러들을 하나씩 들어 내서 조심스레 때를 닦아 주자. 회색콩도 정갈하게 닦아 주자.

위 사진의 롤러 중 하나에는 내가 공작용 본드로 패드에 보강을 했는데,.... 소용 없는 짓이었다. 정말 균일한 두께로 보강할 자신이 있는 사람이 아니면 보강하지 않도록 한다.

이제, 청소가 끝났으면, 마우스를 조립할 차례이다. 조립은 분해의 역순. 따로 설명할 필요는 없겠지만, 주의해야 할 사항이 있으니 그것만 설명하고 마치도록 하겠다. 아래 사진에서 보다시피 흰색 캡에는 방향이 있다. 그래서 어느 방향으로 캡을 씌워야 할지는 쉽게 알 수 있다 :

문제는 캡을 씌울 때 각각의 롤러를 제자리에 잘 넣어야 한다는 것인데, 캡을 자세히 보면 아래 사진처럼 되어 있다 :

위 사진에서 화살표로 표시한 부분이 캡을 다시 씌우면서 망가지기 쉬운 부분이므로 극도로 조심해서 캡을 씌워야 한다.

캡을 씌운 다음 잘 씌워졌는지, 위의 화살표로 표시한 다리들이 구부러지지 않았는지 반드시 확인해야 한다. 저 다리중 하나가 제자리에 들어가지 않고 부서지거나 구부러지면, 콩을 굴릴 수 없거나 굴려도 롤러가 돌아가지 않아서 마우스를 버릴 수 밖에 없게 될 것이다. 아래 사진에서 보듯이 흰색 캡의 다리 사이의 공간에 롤러의 손잡이 부분이 정확하게 들어가 있어야 한다.

중요 부분을 좀 더 확대해서 보도록 하자 :

반드시 롤러 네개가 모두 위 사진처럼 제대로 자리잡아 들어갔는지 확인하도록 한다.

이렇게 해서 트랙볼 집(?)의 조립이 끝났으면, 아래 그림처럼 트랙볼 집의 FPCB만 마우스 하판에 끼운 후 마우스를 맥에 물려서 스크롤이 잘 되는지 확인한다. 만약 원하는 방향의 스크롤이 안되면, 다시 분해한 후, 롤러를 스크롤이 잘되는 쪽의 롤러와 교체한 후 조립하고, 스크롤을 확인해 보면 되겠다.

참고로, 트랙볼을 돌렸을 때 손가락이 움직이는 방향에 있는 롤라가 돌아가게끔 되어 있다. 즉, 힘을 받는 쪽 롤러가 돌아가는 것인데, 예를 들어, 손가락을 윗쪽으로 해서 볼을 돌리면, 윗쪽 방향의 롤러가 돌아간다.

원하는 방향의 스크롤이 고쳐졌다면, 이제 남은 것은 조립 뿐.

조립은 분해의 역순이므로 나머지는 알아서 하시면 되겠다.

첫돌이 될 때 쯤이면 대부분의 아기들은 첫 걸음을 떼고, 아장아장 걷기 시작한다. 그 과정에서 얼마나  넘어지고 구르는지.

흔히들 모차르트의 음악에는 고뇌의 흔적과 영혼의 깊이가 부족하다고 한다. 그가 천재였기 때문에, 음악을 만들기 위해 고민하고, 괴로워하지 않아서. 창작의 고통은 겪어보질 않아서. 저기 높은 곳에 계신 누군가가 그의 머리 속에 넣어 준 음악을 단지 꺼내기만 해서. 그래서일까?

인생을 살면서 주변의 누군가를 지켜 볼 때, 제 3 자인 내가 보기에는 너무나도 뻔한 것이고, 모두가 행복할 수 있는 답이 있음에도 불구하고, 그 답이 너무나 분명해서 당사자만 제외한 모두가 알고 있는 것임에도, 꾸역꾸역 그 답을 따르지 않고 이리저리 둘러가는 사람이있다. 결국엔 정답처럼 할 것인데도. 먼 길, 험난할 길 둘러 가면서 주변 사람, 자신 모두 상처를 주고, 받고 하면서 답을 낸다. 빙빙 돌아서 힘들게 가고 있을 때에는 정답이 보이지 않는 걸까?

만약, 이리저리 둘러 가지 않고 곧장 원하는 답안에 이르렀다면, 과연 그같은 행복한 상태가 가치있음을 뼈저리게 느끼고 감사해 할 수 있을까? 그 행복의 가치를 알 수 있을까?

사람과 사람의 관계, 그리고 인생은 너무나 복잡해서 '이거다'라고 정답을 낼 수 있는 문제는 하나도 없다. 그래도 정답은 있는 법이다. 답이 있는데도 불구하고 당사자에게는 잘 보이지 않는다. 설사 답을 알고 있다 해도 어쩔 수 없는 경우도 있다.

소설 영웅문에서 양과는 "천하에 뜻대로 되지 않는 일이 항상 열에서 일고여덟이로다"라고 말했다고 한다. 또한 제갈량은 "모사재인이요, 성사재천이라 (謀事在人 成事在天)"고 하지 않았던가.

각설하고, 2006년에 제작한 드라마인데, 정말 잘 만든 드라마이다. 물론, 중간에 답답하고 짜증나고 괴로워서 더 보다간 내가 이상하게 될 것 같다고 생각했던 구간도 있지만, 그걸 제외하고서 본다면. 출연 배우들의 연기도, 시나리오도, 음악도, 센스가 철철 넘치는 대사도 훌륭하다. 아직 보지 않은 사람이 있다면, 꼭 한번 DVD구해서 시청해 보기 바란다.

드라마가 중반으로 달리면서 등장인물들의 감정에 몰입하게 되는 바람에 생활까지 바닥으로 침잠해 버릴 수 있으니 일단 각오는 하고 보시는게 좋다. 인생이려니 생각하고.

다음과 같은 소스코드가 있다.

hdr.h :

#ifndef __HDR_H__ #define LOOP_CNT 100 #endif /* __HDR_H__ */

main.c :

#include <stdio.h> #include "hdr.h" int main(void) { int i, sum = 0; for (i = 0; i < LOOP_CNT; i++) sum += i; (void)printf("sum = %d\n", sum); return 0; }

1 - 100 까지의 합을 구해서 출력하는 단순한 프로그램이다. Makefile 을 조금 복잡하게 만든다면 분명 아래처럼 만들텐데 :

이처럼 Makefile 을 만든 후, make 를 하게 되면 물론, 컴파일이 성공적으로 이루어진다 :

~/work/ex$ make clean
rm -f *.o *.d core sum
~/work/ex$ make all
gcc -Wall -o main.o -c main.c
gcc -o sum main.o
~/work/ex$ ./sum
sum = 5050
~/work/ex$

당연하겠지만, main.c 를 약간 수정한 후 make 를 하면 main.c 를 다시 컴파일한다.

그렇지만, hdr.h 에 있는 LOOP_CNT 상수를 수정한 후 make 를 하면? 다음과 같이 나온다 :

~/work/ex$ sed 's/100/200/g' hdr.h > a.h; mv a.h hdr.h
~/work/ex$ cat hdr.h
#ifndef __HDR_H__

#define LOOP_CNT 200

#endif /* __HDR_H__ */
~/work/ex$ make
make: Nothing to be done for `all'.

main.c 를 다시 컴파일해야 함에도 불구하고, 컴파일을 해 주지 않는다! hdr.h 를 바꾸면 알아서 hdr.h 에 dependent 한 소스파일을 찾아서 다시 컴파일을 하도록 만들 수 없을까?

gcc 에는 -M 이라는 옵션이 존재한다. dependency 를 체크해서 이것을 Makefile 형태로 출력해 주는 옵션이다. 자세한 것은 gnu의 manual페이지를 참고하면 알 수 있다 : http://gcc.gnu.org/onlinedocs/gcc-4.4.3/gcc/Preprocessor-Options.html#Preprocessor-Options

이것을 이용해서 아래와 같이 Makefile 을 수정하면, 헤더가 바뀌어도 알아서 그 헤더에 dependent 한 소스도 컴파일을 하도록 할 수 있다 :

.PHONY: clean OBJECTS = $(patsubst %.c,%.o,$(wildcard *.c)) CC = gcc LD = gcc CFLAGS += -Wall # Default target all: sum sum : $(OBJECTS) $(CC) -o $@ $^ $(OBJECTS) : %.o : %.c $(CC) $(CFLAGS) -o $@ -c $< # Generating dependency files %.d : %.c @$(CC) -MM $< > $@ # Include dependency file to have gcc recompile necessary sources -include $(patsubst %.c,%.d,$(wildcard *.c)) clean: rm -f *.o *.d core sum

gnu make 의 manual 페이지에도 위와 같은 내용이 나온다 : http://www.gnu.org/software/make/manual/make.html#Automatic-Prerequisites

Makefile 에서 include 앞에 '-'를 붙인 것은, 에러가 나도 무시하라는 뜻이다. gnu make 는 두 개의 phase 를 가지고 Makefile 을 해석하는데, 첫번째 phase 에서 include 를 하려고 .d 파일을 찾으면 아직 .d 파일을 만드는 타겟이 실행되기 전이므로 .d 파일을 찾을 수 없다는 에러가 발생하는데, 보기 좋지 않다. 그래서 '-' 를 앞에 붙여서 에러를 무시하도록 한다. 두번째 phase 에 진입해서는 .d 파일이 만들어진 이후이므로 문제 없음.

어떻게 해서 이것이 가능한지 궁금하신 분들은 .d 파일의 내용을 보시면 된다. 간단하니 설명은 생략하고 넘어가겠다.

systam call 이나 library call 을 거의 쓰지 않기 때문에 (사실, wrapper 만 호출해 왔다) 코딩을 하면서 manpage 를 참조할 일이 거의 없었다. ctags 만 있으면 wrapper 의 소스를 바로 볼 수 있기 때문에 소스 코드 외에 다른 문서가 필요 없었다.

그러나 최근 wrapper 를 쓰지 않고 프로그램을 만드는 연습을 하자니 매번 터미널에서 manpage 를 찾아 보는 게 너무나 번거롭게 느껴졌다.

그래서, k 로 매핑해 놓았던 K 의 매핑을 없애고, 대신, man | col -b 를 쓸까 했는데, 만족할 만한 결과가 나오지 않았다.

"틀림없이 누군가가 만들어 둔 script 가 존재할 거야" 라는 생각으로 vim.org 를 검색했는데, 아니나 다를까, 있었다.

http://www.vim.org/scripts/script.php?script_id=489

위 링크에서 .vba 파일을 받은 후, 받은 파일을 .vim 디렉토리로 옮긴다. 물론 .gz 압축을 풀어 주어야 함은 두말하면 잔소리.

그리고, vim 으로 .vba 파일을 open 한 후, 아래의 커맨드를 입력하면, vimball 로 묶여 있는 내용이 풀리게 된다 :

:so %

설치는 이것으로 끗.

사용방법은, manpage 를 보고자 하는 함수에 커서를 위치시키고, manpage section number 를 입력한 후, K 를 누르면 된다.

manpage section number 를 누르지 않으면, 터미널에서 그냥 man <function name> 을 한 것과 같은 결과가 나온다. 아래의 그림에 예시된 바와 같다 :

1. K 를 누르기 전의 화면

2. K 만 입력했을 때의 manpage

3. 2K 를 입력했을 때의 manpage

크나큰 문제점 한가지!! 그리고 해결방법!!

문제는, 내가 코딩할 때 vsplit 을 해서 두 개의 윈도우를 사용한다는 것이다. 아래 그림처럼 사용하되, 각각 80컬럼씩 맞춰 놓고 쓴다.

그런데, vim 이 외부의 프로그램, 이를테면 man 과 같은 것을 호출할 때에는 terminal width 가 vim 윈도우의 크기로 설정되는 모양인 듯 하다. 그래서 man 을 해 보면 아래의 그림과 같이 매우 불편한 상황이 연출된다 :

:set nowrap

을 사용할 수도 없는 것이, 그렇게 하면, formtting 이 완전히 깨져서 안하느니만 못하게 된다.

해결 방법으로 두 가지를 생각해 볼 수 있겠다 :

1. :wincmd K 를 사용해서 man page 의 내용을 윈도우 전체의 폭을 활용해서 위로 올려 버리는 것.
   그러나 이 방법은 자연스럽지 않다.
   
2. man man 을 해 보면, man 이 $MANWIDTH 라는 환경변수를 사용한다는 것을 확인할 수 있다. 물론, linux 에서만 가능한 방법이지만, 어차피 HPUX 나 Solaris, AIX 의 man page 는 80컬럼에 맞춰져서 나오므로 문제될 것이 없다.
   

위 두 가지 방법 중 2번 방법이 나아 보이며, 실제 결과도 더 나았다.

그러면, 2 번 방법을 어떻게 적용하는가?

아래의 diff 를 ${HOME}/.vim/autoload/manpageview.vim 에 적용시키면 된다. 아래의 diff 에는 1번 방법과 2번 방법이 모두 나오는데, 주석처리된 부분은 1번 방법. 주석처리되지 않은 방법은 2번 방법이니, 취향에 따라 선택해서 사용하면 된다 :

shawn.mdw:~/env/vim$ svn diff
Index: autoload/manpageview.vim
===================================================================
--- autoload/manpageview.vim    (revision 155)
+++ autoload/manpageview.vim    (working copy)
@@ -389,6 +389,7 @@
 "   call Decho("hsplit mode")
    if &ft != manpageview_syntax
     wincmd s
+    "wincmd K
     enew!
     wincmd _
     3wincmd -
@@ -399,6 +400,7 @@
 "   call Decho("hsplit= mode")
    if &ft != manpageview_syntax
     wincmd s
+    "wincmd K
    endif
    enew!
   elseif g:manpageview_winopen == "vsplit"
@@ -522,6 +524,7 @@
     " ---------------------------
     " use manpage_lookup function {{{4
     " ---------------------------
+    let $MANWIDTH=winwidth(0)
        if exists("g:manpageview_lookup_{ext}")
 "     call Decho("lookup: exe call ".g:manpageview_lookup_{ext}."(".manpagebook.",".manpagetopic.")")
      exe "call ".fnameescape(g:manpageview_lookup_{ext}."(".manpagebook.",".manpagetopic.")")

그럼, 2 번 방법을 적용시킨 후의 스크린샷을 보자. 깔끔하게 원하는 형식으로 출력되었다.

2010년 1분기 방영. 현재 아직 완결되지 않은 상태로 방영중.

원작 만화는 7권 발행. (미완)

회가 거듭됨에 따라 "이거 정말 재미있군!" 이라는 감탄사를 유발하는 애니메이션이다.

다만, 오락성이 매우 짙기 때문에 "무엇인가"를 기대하고 보지는 말 것.

뭐든지 사각사각하며 종이에 적고 싶은 생각을 불러일으킨다.

이런저런 고가의 고급 만년필들도 많겠지만, 처음 구입한 LAMY에 만족하며 10년은 써 보도록 하자... 이... 잊어버리면 할 수 없이 또 사야 하겠지만... ( '-')