http://w3labs.kr/?p=980
미래웹기술연구소 홈페이지로 글을 옮겼습니다.

GStreamer는 리눅스에서 사용되는 Open Source Multimedia Framework으로 GObject기반으로 구현되어 있다.  리눅스 데스크탑에서 대다수의 Multimedia Application은 GStreamer를 사용하어, 많은 개발자와 사용자를 확보하고 있다. 
GStreamer Conference 2011는 작년에 이어 두번째 열리는 행사이며, 전세계 GStreamer 개발자가 모여, 발표도 하고 정보도 공유하는 자리이다. 올해는 체코 프라하에서 10/24~25 열린다. 발표될 주제는 다음과 같다.

• GStreamer 1.0
• DLNA support
• Cross platform development with GStreamer
• Telepathy VOIP and videoconferencing
• GStreamer and Android
• GStreamer and MeeGo
• GStreamer, Webkit and HTML5
• Case studies on GStreamer product deployment

참고로, 7/11까지 발표 신청을 받고 있다.

이번에 새로 출시한 Noikia N9에 WebKit2 기반의 QtWebKit이 탑재되었다. Apple 보다 한 발 빠르게 WebKit2 모델을 적용한 것이다. 내년에 Apple에서 먼저 WebKit2를 적용한 Safari를 출시할 것으로 예상했는데, Nokia가 덕분에 좀 더 빠르게 움직일 듯 보인다. 어쨌든, Nokia가 최초로 Mobile용 브라우저에 Multiple Process Model를 도입한 것이다.

Nokia는  Qt5에서 마지막으로  WebKit1 API를 update하고, 더 이상 개발을 하지 않는다고 한다. 앞으로, iPhone에 WebKit2가 적용되면 Native Application과 Web Application간의 경쟁이 더욱 뜨거워 질 것 같다.

Desktop Summit 2011이 한달 앞으로 다가왔다. 2009년에 이어 다시 참석하게 되어 무척 설랜다. Desktop Summit은 2년에 한번씩(홀수년) GNOME과 KDE Community에 함께 하는 오픈소스 컨퍼런스(Open Source Conference)이다. 참고로, 짝수년에는 각자 GUADEC과 Akademy라는 행사를 별도로 진행한다.

올해는 아래와 같은 일정으로 독일 베를린에서 열린다.
August 6-12, 2011 in Berlin at the Humboldt University.

Linux Desktop 기술을 주제로 많은 발표가 이루어지므로, 최근기술 Trend를 이해하고 직접 maintainer를 만날 수 있는 좋은 기회이다.

올해 프로그램은 다음과 같으며, 수 많은 Session과 BOF가 준비되어 있다. :-)
https://desktopsummit.org/program

이번에 Collabora에서는 WebKit과 GStreamer 등에 대해 발표를 한다.
https://desktopsummit.org/program/sessions/gstreamer-10
https://desktopsummit.org/program/sessions/webkit-clutter-port-present-and-future-webkitgtk-status-and-roadmap-webkit2

GStreamer과 WebKit에 대한 개발 진행 상황과 향후 계획을 소개할 예정이다. 특히, 현재 참여 중인 webkit-clutter에 대하여 처음 소개하는 자리여서 기대가 크다.

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

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

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


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

두번째 이유는 굴림체가 일본 글꼴에 끼워 맞추어 개발되어 한글의 조형미를 반영하지 못한 부분이다. 

<그림출처> http://www.wikitree.co.kr/main/news_view.php?id=32747

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

• 굴림체. 과거, 현재 그리고 미래 
• 아직도 굴림체 쓰시나요?
• 굴림체는 일본서체, 사용하지 말자 
• 한글폰트 굴림체가 일본서체???? 
  
   

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

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

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

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

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

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

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

지난 달에 제 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에 다음과 같이 제안이 이루어졌고,

[whatwg] Proposal for IsSearchProviderInstalled / AddSearchProvider

WebKit에도 오래전에 버그로 등록은 되어 있지만, 현재로서는 구현 계획이 없다.

그러면, 브라우저에서는 어떻게 사용하는지 살펴보자.

• Firefox에서 AddSearchProvider 사용하기

• IE에서 AddSearchProvider 사용하기

• Chromium에서 지원

Google에서 WebKit에 반영하도록 노력한다고 하니, 진행 과정을 지켜봐야겠다.
 

HTML Media Capture

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

Navigation Timing

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

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

참고

• 이재환님 Web Application APIs 발표 자료
  

지난 4월 24,25일 미국 Apple본사가 위치한 Cupertino에서 열린 WebKit Contributors meeting 2011에 참석했습니다. 본 행사는 WebKit Contributor가 한 자리에 모여, 당면한 문제와 앞으로 계획 등을 논의하는 자리입니다. 올해가 두번째 열렸으며, unconference형식으로 진행되는 행사입니다. 지난 1년간 함께 WebKit을 개발해온 사람들이 함께 모이는 축제라고도 할 수 있겠지요. 이번 모임에서 어떤 논의가 있었는지 간단하게 소개하도록 하겠습니다.

WebKit은 모바일 브라우저 엔진 뿐만 아니라 Mobile Platform으로도 사용되고 있기 때문에 Apple과 Google뿐만 아니라, Nokia, RIM, Samsung, Motorola, Ericsson, Sony, Igalia, Sencha 에서도 참석하였고, 저도 Collabora를 대표해서 참석하였습니다.  지난 WebKitGtk+ Hackfest 참석 멤버들도 다시 만나서 반가웠고, 제 Patch를 review해주던 Reviewer도 실제로 만나니 더 반가웠습니다. 오픈소스 프로젝트에 참여하는 맛이 이런게 아닌가 싶었습니다. 

진행된 Session과 내용은 대부분 인터넷에 공개가 되어 있어서, 어떤 논의가 오고갔는지 확인할 수 있습니다.  무엇보다도 관심은 WebKit2였습니다. 작년에 Apple이 소개한 WebKit2는 그 동안 Qt와 Gtk+ Port팀도 활발하게 작업을 진행하고 있습니다. 사실, WebKit2는 WebCore를 제외한 API영역과 Web Process와 UI Process를 새로 개발하기 때문에 그리 간단한 일은 아닙니다. 이날도 많은 Issue가 쏟아져나왔는데, 몇 가지를 소개하면 다음과 같습니다.

• C API사용이 최선인가? 이미 Qt는 C++ API를 사용하고 있습니다.
• plugin을 별도 process로 실행하기. 곧 Apple이 소스를 공개한다고 합니다.
•  WebKit1과 WebKit2와 중복 code를 어떻게 줄일까요?
• DRT를 다시 작성하는일, WebKitGtk+의 경우 WebKit1용 DRT도 아직 완벽하지 않습니다.
• theaded model 지원하기. mobile device에서 각 page마다 web process를 실행하는 것은 다소 부담스러운 일입니다.
• web process와 ui process과 통신하는 부분이 너무 platform 의존적으로 개발되어 있어, 뭔가 추상화 모델이 필요합니다.
• Mac에서 구현한 접근성 기능을 다른 port에서는 따라하기가 쉽지 않다고 합니다.
  

WebKit Party Poster

어제(4/9) GNOME3 Korea Launch Party가 잘 끝났네요. 베일(?)에 가려져있던 한국 그놈 커뮤니티 분들을 직접 만나게 되어 무척 즐거웠고, 좋은 발표도 이어져, 3시간 동안 알차게 시간을 보낸 것 같습니다.

그놈 플랫폼은 우분투에서 기본으로 사용하기 때문에 정말 많은 사용자가 국내에도 있지만, 정작 우분투는 알고 그놈이 무엇인지 모르는 분들이 많은 것 같습니다. 설명하지면, 우분투는 대표적인 리눅스 배포본 중의 하나이고, 그놈은 우분투에서 사용하는 데스크탑 환경과 기반이 되는 플랫폼 그리고 응용 애플리케이션이라고 말할 수 있습니다. 주요한 특징은 GTK+라는 Widget Toolkit으로 애플리케이션을 개발하고 GObject 사용합니다.

한국 그놈 커뮤니티에서 그 동안 (아마 10년 넘게), 한글화 및 한글 지원 작업을 진행해오고 있습니다. 국가에서 상이라도 줘야할 것 같은데, 조용하게 활동하는 분들이라서, 그 동안의 기여가 제대로 알려지지 못한 것 같습니다.

그 동안 진행해왔던 일들을 소개하면, (제가 모두 아는 것은 아지만)

• 그놈 플랫폼, 애플리케이션, 홈페이지의 한글화 작업
• Pango 한글 지원
• 한글 폰트 지원
• 한글 맞춤법 사전 개발

등등 입니다.

현재 이슈 사항으로는 (창우님의 발표 내용을 더듬어)

• 나눔글꼴 이슈 (fork 고려)
• GNOME Accessibility에서 Screen Reader 한글 지원
• Telepathy Nate-on Connection Manager (리눅스용 Nate-on이 더이상 업데이트 안되고 있다고 하네요)
• Banshee 한국음원사이트 관련 Plug-in 개발

등이 있습니다.