페이지

2011년 6월 27일 월요일

웹페이지 기본 글꼴은 왜 아직도 굴림체인가?

Mozilla Bugzilla에 윈도용 Firefox의 기본 글꼴을 굴림체에서 맑은 고딕으로 바꾸자는 버그를 올렸지만, 받아들여지지 않았다. 가장 큰 이유는 윈도95사용자가 여전히 전체 사용자의 절반을 차지 한다는 것과  많은 웹사이트가 여전히 굴림 또는 바탕체를 사용하고 있다는 점이다.

그렇다면, 왜 굴림체를 바꿔야할까?

첫번째 이유는 이름답지 않다는 것이다. 가독성이 높다는 것도 중요하지만, 가독성도 높고 아름다운 글꼴 얼마든지 있다.  아래 Twitter 한글 페이지를 보면, 굴림체가 얼마나 웹페이지를 촌스럽게 만드는지 알 수 있다.

What font is beautiful? 
트위터 같은 경우, 웹페이지에 특정 글꼴을 지정하지 않았기 때문에, 기본 글꼴인 굴림체가 사용되었다. 만약 기본 글꼴을 맑은고딕으로 변경하면 아래 그림 같이 표시된다. 훨씬 아름답지 않은가?

두번째 이유는 굴림체가 일본 글꼴에 끼워 맞추어 개발되어 한글의 조형미를 반영하지 못한 부분이다. 
 
<그림출처> http://www.wikitree.co.kr/main/news_view.php?id=32747

이와 관련된 문제 제기는 오래전 부터 있어 왔다. 

역사적 감정으로 글꼴을 바꾸자는 이야기가 아니다. 굴림체가 한글의 아름다움을 충분히 반영하지 못한 부분을 지적하고 싶은 것이다. 한류로 인해 국내 웹사이트에 접근하는 외국인이 많을 것이다. 아마도 그들이 윈도를 사용한다면, 처음 접하는 글꼴이 바로 웹페이지 기본 글꼴인 굴림체일 것이다.

세번째, 이미 MS는 기본 글꼴을 맑은 고딕으로 변경했다. 윈도 비즈타 부터 기본 한글 글꼴은 맑은 고딕으로 변경했고, 최신 Office를 윈도XP에 설치하면 Office UI는 맑은 고딕을 사용한다. 굴림체가 윈도XP의 기본 글꼴임에도 불구하고 유독 Office만 맑은고딕을 사용한다. 심지어 편집할 때도 맑은 고딕을 사용한다.  그 만큼 맑은 고딕은 가독성이나 디자인 측면에서 검증 받은 글꼴이다.

 왜 웹페이지 기본 글꼴을 바꿀 수 없다는 것일까?

첫번째,  IE가 굴림체를 기본 글꼴로 사용하고 있고 동일한 사용자 경험을 제공해야 하므로..

맞는 말이다. 사용자에게 IE나 Firefox에서 동일한 사용자 경험을 제공하는 것은 중요하다. 그렇다면,  나쁜 사용자 경험도 똑같이 따라해야 할까?  개인적으로 윈도7을 사용하면서 유독 굴림체가 눈에 거슬리기 시작했다. 이미 사용자들은 맑은 고딕에 익숙해져서 굴림체가 촌스럽게 느껴지기 시작했고, 이제 웹페이지도 굴림체에서 벗어날 좋은 시기가 된 것이다.

두번째, 많은 웹사이트가 굴림체를 사용하고 있다.
맞다. 많은 웹사이트가 여전히 굴림체 또는 바탕체를 사용하고 있다. 주의 깊게 봐야할 것은 10~12포인트 정도에서만 사용할 뿐 그 이상 크기에서는 굴림체를 거의 사용하지 않고, 대부분 이미지로 대신하고 있다. 그 이유는 굴림체를 확대하면 정말 아름답지 않기 때문이다. 유독 한글 페이지 가운데 텍스트를 이미지로 대신한 사이트가 많은 이유가 바로 굴림체 때문일 것이다. 심지어 모든 내용을 이미지로 보여주는 경우도 많은데, 디자이너들도 역시 굴림이나 바탕체로는 아름다운 웹페이지 만들기가 어렵다는 것을 알기 때문이다.   앞서 트위터에 한국인 디자이너가 있다면 저렇게 굴림체를 크게 확대에서 절대 보여주지는 않았을 것이다. 이렇게, 텍스트르 이미지로 처리하면 많은 부작용이 생기는데, 우선 모바일에서 다운로드 하는데 시간과 비용이 들며, 검색엔진에서 검색이 되지 않는다.

글꼴을 사용자의 취향이라고 생각하기에는 잘못된 기본 글꼴이 주는 피해가 이처럼 큰 것을 알 수 있다. 윈도 플랫폼에서 이제 더 이상 굴림체를 고집할 필요는 없다고 생각한다. 이미 윈도 비즈타 부터, 맑은 고딕이라는 좋은 글꼴이 시스템 폰트로 사용되기 시작했다. 이제 웹페이지도 윈도 사용자를 위해 기본 글꼴에 맑은 고딕을 추가해야 하고, 브라우저도 맑은 고딕을 기본 글꼴을 지정해야 한다. 좀 더 아름다운 한글의 모습을 보고 싶다면, 먼저 변해야 한다.

2011년 6월 5일 일요일

WebKit의 웹표준 구현 현황


지난 달에 제 6차  W3C  HTML5 KIG Meeting에 처음으로 참석하게 되었다.  이 모임은 국내HTML5 표준화에 관심을 갖는 분들이 모여 HTML5 표준화 현황을 나누고 논의하는 자리이다.  이번 모임에서는 HTML5 Web App, Device API, Navigation Timing Spec에 대한 소개가 진행되었는데실제 WebKit에서 어떻게 지원되고 있는지  간단하게 정리해보았다.


Custom scheme and content handlers

브라우저에서 사용하는 Protocol이나 mimetype을 임의로 등록하여 특정 URL에서 처리하도록 하는 기능이다, http://, ftp://와 같은 Protocol을 브라우저에 임의로 등록할  수고 있고이를Protocol로 요청이 들어오면 특정 URL이 처리할 수 있도록 한다아래와 같은 인터페이스를 지원하고 있고, 실제 Spec은 여기서 확인할 수 있다.
window.navigator.registerProtocalHandler(scheme, url, title)
window.navigator.registerContentHandler(mineType, url, title)
) navigator.registerContentHandler('application/x-soup', 'soup?url=%s', 'SoupWeb'')

위 Feature는 WebKit에 구현되어 있지만아래와 같이  Build할 때, enable해야 사용할 수 있다하지만아직은 Chromium에서만 지원하는 듯 보인다.
WebKit/Tools/Scripts/build-webkit --register-protocol-handler
실제 구현은 된 초기patch는 여기서 확인 가능하다. 최근이미 사용 중인 protocol에 blacklist 를 각 브라우저 개발 업체로 부터 수집하였고이에 대한 처리가 WebKit에 반영되었다.

AddSearchProvider

Search Box에 검색 엔진을 등록하는 기능인데이 역할을 UI에서 할지 Engine에서 해야할지 아직 논란이 있다이미 IE와 Firefox에서 지원하고 있지만, WebKit Community내에서는 합의가 필요한 상태다.
지원하는 interface 는 다음과 같다
window.external.AddSearchProvider()window.external.IsSearchProviderInstalled()
whatwg에 다음과 같이 제안이 이루어졌고,
WebKit에도 오래전에 버그로 등록은 되어 있지만현재로서는 구현 계획이 없다.
그러면, 브라우저에서는 어떻게 사용하는지 살펴보자.
Google에서 WebKit에 반영하도록 노력한다고 하니진행 과정을 지켜봐야겠다.
 

HTML Media Capture

Device API Spec은 특히 Mobile분야에서 관심이 많은데, Web App과 Native App간의 경계를 허무는 작업이라고도 할 수 있다그 중에서 HTML Media Capture Spec은 User Agent에서 devicemicrophone과 camera에 접근하도록 한다현재 WebKit에는 버그만 등록된 상태이다.


Navigation Timing

지금까지 웹 성능을 측정하는 일은 브라우저 개발자만이 가능한 일이였다. 브라우저 개발자도 HTTP 모듈까지 소스코드로 접근해야만 어느 정도 측정이 가능했었는데, 이를 웹 개발자도 가능하도록 Navigation Timing이라는 Spec이 표준화 중에 있으며, 이미 Chromium은 지원하고 있고, 데모 페이지에서 테스트할 수 있다. 이를 통해 Page를 요청하여 로딩하는 전 과정에서 얼마나 시간이 걸리는지 단계별로 Profiling 할 수 있게 된다. 현재, GTK+ portQT port에서 이를 구현하고 있다.

앞으로 매달 열리는 HTML5 KIG Meeting에서 논의된 웹표준 내용을 가운데, WebKit에서 얼마만큼 구현하고 있는 소개할 예정이다.


참고