아두이노에 붙여보려고 캐릭터 LCD (CMBC016002E00)를 구입한지 한참 되었습니다.

1년을 훌쩍 넘겼고 얼마에 샀는지도 기억이 안나는.. 그 때는 데이타시트를 봐도 무슨 말인지 모르겠고 (지금도 마찬가지지만) 연결해야할 핀도 많고 이 물건의 호환성도 의심되고 해서 흥미를 잃고 버려두었지요.

근래 아두이노 홈페이지에서 LCD튜토리얼과 수아파파님의 CLCD 1/3 Hello LCD, 그리고 펩시맨님의 arduino에서 LCD 구동하기 2 를 보고나니 여러가지 우려가 사라지고 다시 시도해보고픈 마음이 생겼습니다.

드디어 애물단지처럼 굴러다니던 캐릭터 LCD를 아두이노에 붙여보았습니다.



데이타핀은 4핀만 연결해도 되었고 캐릭터 LCD의 호환성에는 전혀 문제가 없었습니다. 최신 버전의 sketch를 설치 했더니 캐릭터 LCD 라이브러리가 내장되어서 별도로 라이브러리를 설치하는 일도 없었습니다. 아두이노 LCD튜토리얼에 있는 샘플 소스들이 아무 변경없이도 잘 실행되었습니다.

앞서 해보신 분의 자료 덕분에 캐릭터 LCD를 쉽게 붙일 수 있었습니다.

여기에 펩시맨님이 하셨던 이더넷모듈을 덧붙이고 싶은데 가능할런지 모르겠습니다.



WRITTEN BY
tinysun

,

구글은 기념일 마다 로고를 재치있게 바꿔서 보여줍니다.

그동안 기념일 로고를 많이 보아왔지만 오늘 만큼 황당하게 바뀐 모습은 처음입니다.


한글날

WRITTEN BY
tinysun

,

WebKit - KHTML 분신의 귀환

IT 2009. 6. 20. 06:58

WebKit Inside

며칠 전 삼성전자는 JET 모바일폰을 발표했는데 Dolfin 브라우저를 사용한다고 소개되었습니다.  한 번에 5개 윈도까지 오픈할 수 있다고 합니다.  다른 현란한 기능도 많이 있고 멋진 휴대폰 같습니다.

Jet Image

Samsung Mobile Phone Jet


Samsung Mobile Phone Jet
( 삼성전자 Jet 소개 웹사이트에서 발췌함 )


지난 2월 PDA 와 스마트폰으로 유명한 Palm 에서는 Palm webOS 라는 리눅스 기반의 스마트폰 플랫폼을 발표했습니다.  이름에서 알 수 있듯이 웹 기술을 접목한 OS 인데 가볍고 빠르다는 평가를 받으며 업계에서 주목 받고 있습니다.  내장된 브라우저는  RTSP, H.263, H.264 비디오 포맷을 지원한다고 합니다.

File:Palm webOS Launcher.png

Parm 의 webOS


Google 은 작년에 Windows 용 웹브라우저인 크롬을 발표하였습니다.  크롬은 간결한 UI와 빠른 속도로 사용자들의 호응을 얻었습니다.  http://marketshare.hitslink.com/report.aspx?qprid=0  를 보면 현재 크롬은 MS의 인터넷익스플로러, Mozilla의 파이어폭스, Apple의 사파리 다음으로 4번째로 많이 사용되는 브라우저가 되었습니다.  최근에는 리눅스용 크로미엄이 쓸만해져서 저는 리눅스에서도 즐겨 사용하고 있습니다.


Google Chrome Screenshot    Google Chrome Icon

구글의 크롬 브라우저와 로고


Google 은 2007년말에 안드로이드 라는 모바일 플랫폼을 발표하면서 브라우징 기능을 기본 제공하고 있습니다.


안드로이드 에뮬레이터 화면


브라우저 점유율 3위인 Apple 의 사파리 브라우저와 4위인 Google 의 크롬은 동일한 layout 엔진을 사용하고 있습니다.  Apple 은 사파리 브라우저를 Mac OS X 뿐 아니라 Windows 용으로도 출시하더니 아이폰과 아이팟터치 에도 기본 제공하고 있습니다.

    

애플의 사파리 브라우저와 로고


이렇듯 데스크 탑과 모바일 기기에 돌아가는 브라우저를 여러 거대 업체에서 만들었습니다.  독립 브라우저로 발표하기도 하고 플랫폼에 끼워 조용히 내놓기도 합니다.  
그런데 방금 소개한 브라우저들은 공통점이 있습니다.  layout 엔진, 렌더링 엔진 또는 웹 콘텐츠 엔진으로 불리며 오픈소스프로젝트로 개발되고 있는  WebKit 입니다. ( http://www.webkit.org  )

WebKit 은 브라우저 기능 개발자들에게 인기가 많습니다.   Adobe 의 RIA 런타임환경인 AIR 에서도 WebKit 엔진을 사용합니다.  리눅스에서 많이 쓰이는 GNOME  브라우저인 Epiphany는 Gecko 엔진에서 WebKit 엔진으로 교체할 것이라고 합니다.  KDE 의 Konqueror 브라우저의 최근 버전은 KHTML 엔진을 기본 제공하면서도 WebKit 엔진을 옵션 형식으로 추가 지원하고 있습니다.  

이제는 WebKit 엔진 사용이 더 이상 뉴스거리가 되지 않는 모양입니다.  삼성의 JET 모바일 폰은 WebKit 3.2 엔진을 적용했는데 여러 다른 현란한 기능들에 비해 웹 컨텐츠 엔진이 특별히 주목받지는 않고 있습니다.  저는 오늘 WebKit 을 조금 자세히 알아보려 합니다.


Compatibility

브라우저 수가 많아졌는데도 웹 페이지의 호환성 문제는 그렇게 커지지 않았습니다.  오히려 10년전의 IE 대 넷스케이프의 투톱 시대보다도 layout 호환성 문제는 좋아 진 듯 합니다.

첫째, IE 를 제외한 대부분의 브라우저 들은 오래전 부터 표준을 준수하는 것을 특징으로 내세우고 있었습니다.  이런 추세에 de facto 표준인 IE 도 최신 버전 부터는 웹 표준 규격을 상당히 준수 하고 있습니다.  웹 표준 측정도구인 ACID 테스트 점수는 브라우저 엔진 개발시 성능지표로 이용되고 있는 듯 합니다.  브라우저 엔진들의 acid 점수 경쟁을 볼 수 있습니다. ( http://en.wikipedia.org/wiki/Acid3 )

그리고, 브라우저는 많아도 호환성을 좌우하는 주목할 만한 layout 엔진은 4개 정도 입니다.   IE엔진(Trident), 파이어폭스엔진(Gecko), 사파리엔진(WebKit), 오페라엔진(Presto) 입니다.  웹 표준 준수율로 보면 IE엔진을 제외한 나머지 엔진들의 호환성 차이는 거의 없는 편입니다.

이제는 레이아웃 호환성 문제 보다는 어떤 엔진 또는 기능을 채용해서 성능을 얼마나 개선 했는지를 내세우는 것이 추세 같습니다.  물론 우리나라에서는 Active X 호환성 문제가 큰 이슈겠지요.

호환성을 뜻하는 그림은 아니지만...


WebKit Origins

- KHTML

애플은 리눅스 KDE 의 KHTML 브라우저 엔진을 사파리 개발을 위해 Mac 에 포팅했습니다.  따라서 WebKit 은 KHTML 엔진의 분신(fork)이라고 할 수 있습니다.

KHTML 은 KDE 프로젝트로 개발된 HTML layout 엔진으로 역시 오픈소스 입니다.  앞에 잠시 언급했던 Konqueror 브라우저의 엔진이기도 합니다.  khtmlw 또는 KDE HTML Widget 이라고 불리는 엔진에 리팩토링과 유니코드 지원등을 하면서 1998년 11월에 나왔는데 처음 버전은 W3C DOM 이나 scripting 등도 지원되지 않았습니다.

한편, 1998년 3월 넷스케이프는 브라우저의 소스를 오픈 하였습니다.  1999년 KHTML 프로젝트는 선택의 기로에 섰습니다.  이대로 개발을 계속할 지 아니면 오픈소스인 모질라 코드를 사용할 지 결정하고 최우선 순위로 scripting 지원을 추가해야 했습니다.  

David Garrick in Hamlet, I, 4
햄릿

- To Be or Not To Be

당시의 모질라 코드는 한 때 TOP 이었던 넷스케이프의 소스였습니다.  그리고 새로운 오픈 소스 브라우저를 처음 부터 만드는 것은 결코 만만한 프로젝트가 아닙니다. 

그 당시에 저는 모질라 코드에 거는 기대가 컸었습니다.  따라서 제가 KHTML 의 향방을 결정해야 했다면 기존의 코드를 버리고 모질라 코드를 활용하고 모질라 진영과 힘을 보태서 함께 더 좋은 것을 만들어 공유하자고 했을 겁니다.  만약에 그렇게 되었다면 지금의 WebKit 은 전혀 다른 모습이 되어있겠죠.

이 때 라스 크롤( Lars Knoll ) 이라는 개발자의 공헌에 의해 프로젝트의 향방이 결정됩니다.  라스 크롤은 내부적으로 표준 W3C DOM 을 사용하도록 변경하느라 완전히 다시 작성된 KHTML 라이브러리를 1999년 8월에 공개하였습니다.  곧이어 10월에 해리포텐( Harri Porten )의 KJS 통합으로 scripting 도 지원하게 되었습니다.

이로써 WebKit 이 될 새로운 KHTML 이 나타났습니다.

출처: 종의 기원 (wikipeida)



WebKit Borns

애플의 매킨토시에서는 넷스케이프나 MS 익스플로러가 기본으로 제공되었습니다.  매킨토시 운영체제를 만들어 제공하면서도 브라우저는 만들지 안았던 것이죠. Mac OS X 를 만들고서도 웹 브라우저는 IE 5.0 맥 버전을 번들로 넣었습니다.  2003년 1월 드디어 사파리라는 웹브라우저를 KHTML 를 기반으로 만들었다고 발표합니다.

애플은 WebKit 의 소스를 오픈했습니다.  WebCore 와 JavaScriptCore 로 분류되는데 이것은 KHTML 과 KJS 를 Mac OS 에 맞게 개발한 후 맥 스타일의 이름을 붙인 것입니다.  애플에서 1년간 개발하여 개선된 KHTML 소스는 여러 이유로 KHTML 오리지널에 merge 되지 못하고 WebKit 으로 불리는 별도의 소스 버전을 가지게 됩니다.

그러니까 WebKit 은 KHTML 의 클론으로 시작했습니다.


WebKit Grows

노키아는 WebKit 을 사용하여 S60 휴대폰을 위한 웹브라우저를 만들었습니다.  iPhone OS 에 채택되어 iPhone, iPod Touch 의 브라우저에 사용되고 Windows 용 사파리에도 사용됩니다.  구글에 의해 안드로이드 플랫폼에서도 사용되며 삼성의 휴대폰에도 들어갔습니다.

Mac 에 포팅되었던 WebKit 은 이제 다양한 플랫폼에서 응용되고 있습니다.  그러면서도 JavaScriptCore 는 더 성능 좋은 것으로 대체되고 있습니다.  애플의 SquirrelFish 와 구글의 V8 이 그렇습니다.  웹 표준 호환성, 성능, 멀티플랫폼 이 대표적 특징이 되어가고 있습니다.  KDE 의 KHTML 로는 이루지 못한 것입니다.

     사진출처: mighty mouse (wikipedia)


WebKit Returns Home

WebKit 의 모태는 KHTML 과 같이 리눅스의 KDE 의 Konqueror 브라우저 입니다.  WebKit 은 이제 GTK+ 에 포팅되어 리눅스에서 돌릴 수 있으며  chromium 리눅스 버전을 통해서도 WebKit 을 돌려 볼 수 있습니다.  WebKit 은 모태인 KDE 의 Konqueror 에서도 돌아갑니다.  다른 브라우저에 들어가면 스포트라이트를 받는 WebKit 이지만 Konqueror 브라우저에서는 조상이자 사촌격인 현재의 KHTML 을 밀어내지 못하고 옵션기능으로 옆에 존재할 뿐입니다.

    

KDE 의 Konqueror 브라우저와 로고



The Motion Picture

스타트렉의 첫 번째 영화판인 THE MOTION PICTURE 가 생각납니다.  업그레이드 되어 지구의 능력을 뛰어 넘는, 지구를 위협하는 미지의 물체인 VGER 와 KDE 의 WebKit 을 비교하곤 합니다.  스포일러가 될까봐 이만 생략합니다.


The Motion Picture
( 영화에서 모션픽쳐는 미지의 움직이는 물체를 뜻합니다. )


WebKit 은 10년전 한 사람의 코딩 기여로 시작하여 커뮤니티와 기업(애플)의 공헌을거쳐 태어났습니다.  여러 플랫폼에 포팅되어가면서 발전하여 현재는 다양한 운용체제와 디바이스에서 동작되고 있으며 IE 를 위협하는 브라우저군의 한 축을 이루고 있습니다.  다시금 리눅스에서 돌아가도록 포팅되는 WebKit 을 보면 태어나서 성장하고 이리 저리 돌아다니는 생명체 같다는 느낌을 줍니다.


감사합니다.


( 게제된 사진의 출처는  http://en.wikipedia.org/  입니다. )


WRITTEN BY
tinysun

,
이번에 변환한 위키백과 사전에는 기억해야할 의미가 있습니다.

그것은 드디어 10만 항목을 넘긴 점 입니다.  10만 항목을 넘겼다는 것은 표시되는 숫자가 5자리에서 6자리로 바뀌는 것외에 또 다른 중요한 의미가 있습니다.

영문 위키백과 ( http://en.wikipedia.org )와 한국어 위키백과 ( http://ko.wikipedia.org ) 뿐 아니라 다른 언어로 된 위키백과도 모두 초기화면이 있습니다.  그리고 그 초기화면에는 각 국의 위키백과를 항목수에 따라 분류하고 있습니다.  분류는 보통 25만이상, 10만 이상 등으로 나누는데 드디어 한국어 위키백과가 10만 이상 그룹에 들어간 것입니다.



그 동안 5만그룹 또는 4만그룹에 들어 있었는데 그 그룹의 다른 국가명을 살펴보면 우리나라가 그와 같은 등급이라는 것이 믿기지 않고 억울할 정도였습니다.

우리나라는 위키백과 말고도 궁금증을 해소할 수 있는 포탈의 백과사전이나 커뮤니티, 지X인 같은 대안 매체들이 있어서 다른 나라에 비해 상대적으로 위키백과의 발전이 더디지 않았나 생각해 봅니다.  따라서 위키백과 항목수가 국가 정보화 능력을 반영한다거나 인터넷 문화 성숙도와 관계가 있다고 생각하지 않습니다.  하지만 기왕이면 다른 나라의 위키백과에 크게 뒤쳐지지 않았으면 합니다.  굳이 랭킹으로 따진다면 현재 26위 정도 입니다.

이런 의미있는 버전을 빌드하면서 지난 달에 비해 좀 더 특별하게 개선하거나 보완하지 못한 점이 아쉽습니다.  그리고 한국어 위키백과가 어서 빨리 25만 그룹에도 들어가게 되길 바랍니다.



WRITTEN BY
tinysun

,
위키백과 사이트에 가보니 문서 수가 10만개를 넘었습니다.
축하할 만한 일입니다.



WRITTEN BY
tinysun

,
5월판 mdx 를 빌드하여 투피 에 포스팅 한 지 벌써 보름이 넘었는데 이제 노트를 남김니다. 요새는 wikipedia 백업 사이트의 진행속도를 가늠하지 못하겠습니다.   얼마전 까지만 해도 막 에러가 나서 언제 다음 번 백업이 될까 걱정되었는데 요새는 5일 주기로 백업이 반복되기도 합니다.  

사실 mdx 파일을 만든 5월 6일 이후 5/11, 5/16 에 wikipedia download 사이트에서 백업이 있었습니다.  2일 내로 또 한번 백업 될 것 같군요.  이대로 라면 2달에 1번 릴리즈 하던 것을 1달에 2번 릴리즈 할 수 도 있겠습니다.  릴리즈도 2009년 5월 6일판  이런 식으로 써야겠지요.

참, 앞의 덧글의 강기윤님 께서  wpko_filter.exe 파일을 원하셔서 여기에 첨부합니다.
아이팟을 위해 위키백과를 wedict 과 stardict 포맷으로 변환하여 올린 사이트를 찾았습니다.  (eu81273 님의 블로그)  위키백과의 xml 파일을 바꾸는 코드를 직접 작성하신 것 같아  대단하다는 생각이 듭니다. 한 편, 제가 사용한 방법을 응용하여 stardict 용을 만들어 그 분 것과 비교해보면 어떨지 궁금 합니다.

WRITTEN BY
tinysun

,
http://download.wikipedia.org/backup-index.html  을 처리하는 서버가 1달반 가량 이상했었다.  전세계 wikipedia 의 백업이 되다 말다 하더니 결국 2월에는 MDict 데이터 파일을만들지 못했다.  하마터면 3월도 넘길 뻔 했다.  backup-index 페이지를 모니터링 하다가 덤프가 되자 마자 다운받아서 MDict 데이터 파일을 만들었다.  늘 그랬듯이 투피 에 올렸다.

3월판은 지난 번 판에 비해 표제어 수가 늘면서 파일수가 5개에서 6개로 늘었다.  파일용량이 압축해도 100M를 훌쩍 넘기는데다 투피에 업로드 제한이 있어 5 개 이내로는 맞출 수 가 없었다.   또, 달라진 것은 별거 아니지만 압축 파일명을 위키백과200903.7z 에서 위키백과_v9.03.7z  이런 식으로 바꿨다.  그 밖의 것은 1월판과 동일하다.

백과사전을 주머니에 넣고 다니면서 언제 어디서나 무엇이든 검색하는 것이 아주 편하고 유용하다.  표제어 수가 계속 늘고 있어 최신 판도 계속 만드는데, 투피에서 다운로드한 분들의 호응이 너무 좋아서 의무감 마저 생긴다.

현재 표제어 수가 93,000 여개이다.  두어달 후면 10만건을 넘길 것으로 보인다.  꾸준히 증가하고 있는 것이 고맙고 어찌보면 신통하다.


WRITTEN BY
tinysun

,

2007년 연말정산안내의 의료비 공제액 계산법이다.  표현만 조금 다를 뿐 내용은 2008년 것과 똑같다.

의료비 공제는 지출대상을 아래와 같이 두 그룹으로 나누어 각각의 공제액을 계산한 후 두 그룹의 공제액을 합한다

 

대상자

                        공제액

그룹 1

본인경로우대자장애자

한도 없이 전액 소득공제가 된다.

다만그룹 2.를 위해 지출한 의료비가 연간 급여의 3%에 미달하는 경우 그 미달금액은 공제액에서 차감한다.

그룹 2

그룹1. 을 제외한

기본공제대상자

연간 급여의 3%를 초과하는 금액에 대하여500만원을 한도로 하여 공제한다




아래는 2006년 연말정산안내의 의료비 공제액 계산법이다.  좀 성의없어 보이기도 하고 단순해서 쉬워보이기도 한다.   앞의 2008년도 계산 방법과는 차이가 크다.  차례대로 읽어가면서 계산하면 되고 빼기의 빼기도 없어서 쉬워 보인다.

2. 의료비 공제액의 계산
 일반적인 경우 ( 500만원 한도 )
공제대상의료비 = 의료비총액 - (총급여액×3%)
 공제대상 의료비가 500만원을 초과하는 경우
공제대상 의료비 = ①과 ②중 적은 금액 + 500만원
① 한도초과금액 = 의료비총액 - (총급여액×3%) - 500만원
② 본인, 장애인, 경로우대자를 위한 의료비 합계액



하지만 여기도 혼동의 여지가 있다.  이 계산법은 '일반적인 경우'  와  '공제대상 의료비...' 의 두 가지 경우로 분류를 하는데 분류의 기준인 '공제대상 의료비' 가 문제다.  공제액 계산 목적이 바로 '공제대상 의료비' 의 산출인데  계산을 위해 분류하는 기준에 그 값을 사용한다. 계산을 이제 하려는데 어떻게 계산 결과가 500만원이 초과되는지 미달되는지 알 수 있는가?  물론 대부분의 사람은 첫 번째 분류에서 계산한 공제대상의료비의 500만원 초과 여부를 의미하는 것이라고 눈치 채겠지만 혼동의 여지는 있다. 

어쨌든 해가 바뀌면서 상세설명은 늘어난 반면 산출 절차는 점점 복잡해지고 있다.  그러면 2006년과 , 2007, 2008년도의 의료비 공제액 관련 규정이 바뀐 것일까?  산출절차만 다를 뿐 결과 금액은 항상 동일할까?  규정이 바뀌었는지 여부는 몰라도 같은 계산 결과가 나온다는 사실은 다음과 같이 수학공식화 하고 비교함으로써 알 수 있었다.


2006년도 계산법
val2006 = min((Vt-P)^, 500) + min((Vt-P-500)^, Vi)

2008년도 계산법
val2008 = (Vi - (P-Vd)^)^  +  min((Vd-P)^, 500)

여기서 각 변수와 기호 정의는 다음과 같다.
val2006, val2008 = 2006년도, 2008년도 계산법에 의한 의료비 공제액,
Vt = 의료비총액,
P = 총급여액x3%,
Vi = 본인, 장애인, 경로우대자를 위한 의료비 합계액,
Vd = 그룹1을 제외한 기본공제대상자의 의료비 합계액,
min( x, y ) 는  x, y 중 작은 수를 의미한다.
( )^  기호는 다음과 같이 정의한다.
          x >= 0  일때는 (x)^ = x,  x < 0 일때는 (x)^ = 0.
          ( (x)^ = max( x, 0 ) 로 생각해도 된다. )

계산절차에서는 명시되지 않았지만 빼기를 한 후 0 보다 작으면 0원으로 처리하기 때문에 ()^ 가 필요하다.

정의에서 Vt = Vi + Vd  이고, 모든 변수값은 0 이상이다.

Vt 의 값을 P, P+500, P+500+Vi  의 특이점으로 구분하는 네개의 interval 로 나누어 수식을 비교한다.  각 경우에 대해 val2006 과 val2008 이 동일하게 다음과 같이 됨을 알 수 있다.
i) Vt <= P 인 경우,  0
ii) P < Vt <= P + 500 인 경우,  Vt - P
iii) P + 500  <  Vt  <=  P + 500 + Vi  인 경우,  Vt - P
iv) P + 500 + Vi < Vt  인 경우,  500 + Vi
  즉, 항상 val2006 = val2008 이다.

더 간단하게 표현되는 수식이 없을까?

쉽게 찾을 수 있다.   의료비공제액 = min((Vt-P)^, 500+Vi).


계산절차를 만들어 보자.

공제대상의료비 = 의료비총액 - (총급여액×3%)
한도액 = 500만원 + 본인, 경로우대자, 장애자를 위한 의료비 합계액
위의 공제대상의료비가 한도액을 초과하는 경우
공제대상의료비 = 한도액

계산결과는 같은데 이러면 더 단순하고 좋지 않았을까?


내 연말정산을 계산해보니 올해의 (Vt-P)^ 가 0 이어서 의료비공제를 한 푼도 받지 못한다.  여태 이걸 왜 한거지?


WRITTEN BY
tinysun

,
연말정산 시즌이다.   1월에 자료를 회사에 제출하고 3월 급여 지급할 때 정산한다고 한다.  년초인 1월에 하는 연말정산을 해나가다가 의료비 공제액 계산에서 그 복잡한 산출법을 보고야 말았다.

2008년 귀속 연말정산 관련하여 국세청에 안내된 공식이다.
얼핏보면 친절하고 상세하고 엄밀하게 표현되어 있다는 첫 인상을 받는다.
글씨가 많은데다 계산 방법을 2가지로 구분하여 합하는 것을 표로 정리한 것이 친절하고 상세해 보인다.   그리고, ①,②,가,나 등으로 참조하여 기술하는 것이 엄밀하게 표현되어 있는 것 처럼 보인다.

그런데 막상 나의 케이스를 적용하여 계산하려고 들여다 보다 한 순간 잠시 무한루프에 빠져 버린다.   ① 의 내용을 읽다가  '다만, ... ' 이라는 문구에서 ② 를 쳐다보게 만든다.  ② 에서는 어떤가?  첫 칸부터 ① 을 제외하란다.  이 때 나는 ① 의 공제대상 의료비를  보고 거기에 있는 '다만 ..' 문구와 ② 를 또 쳐다본다.

지금 생각해 보건대   ['①' 을 제외한 ... ]  대신  ['①' 의 대상자를 제외한 ... ] 으로 했으면 조금 나았을까 싶다.

하지만 이것은 시작이었다.  그 문제의 '다만, ... ' 문구는 표현상으론 짧고 단순하지만 계산상으로는 그렇지 않다.   ① 의 공제대상 의료비를 계산하기 위해 ①의 의료비 지출액을 사용한다.  그런데 난데없이 다만 이라는 단서로 ②의 의료비 지출액을  들척인다.  그것도 '의료비금액' 으로 표기하여 혼동을 주면서 총급여액x3% 의 미달여부를 따진다.   이제 의료비공제액 계산법의 하일라이트가 나온다.  미달하는 금액을 차감한 금액!

미달 금액의 차감은  빼기의 빼기다.  떼간 세금 줄여서 환급받는 것도 결국 빼기의 빼기가 아닌가?  연말정산의 철학인가보다.

복잡한 규정 때문에 계산법도 이렇게 복잡해 진 것이라고 생각했었다.  다음에는 2006년도와 2007년도 연말정산의 의료비 공제액 계산표를 보겠다.


WRITTEN BY
tinysun

,
http://download.wikipedia.org 에서는 세계 각국 버전의 wikipedia 가 차례대로 순환하며 dump 되고 있다.    한국어 위키백과 dump 가 1바퀴 순환하는데에 지난 11월과 12월사이는 1달이 조금 넘었는데 이번에는 23일 밖에 안걸렸다.  그 사이 dump 서버가 빨라진 것일까?

요사이 kowiki 의 dump 순서가 다가 오는 것을 지켜보고 있다가 아침에 dump 가 된 것을 보자마자 download 하여 잽싸게 MDict 로 변환하였다.   http://todaysppc.com 에 올리기 까지 2시간 남짓 걸렸다.  이렇게 해서 지난 1월 3일 이후 보름여 만에 또 한 무더기의 데이타파일들을 업로드했다.

그런데, About 페이지의 머리글을 2008년 12월 이라고 넣어 버리는 실수를 해버렸다.  어차피 백과사전 본문이 중요한 거니까... 냅 두기로 했다.  다음에는 잘하지 뭐.  다음 dump 는 2월 중순이 될 듯 한데 그 때는 표제어 수가 90,000 을 넘길 것으로 예상된다.


WRITTEN BY
tinysun

,