혁신은 어디에 있는가? 경향(트렌드)란 무엇인가?


Steve Jobs의 비디오에서도 볼 수있듯이, Mac OS X에 더 이상 추가할 기능이 없는게 아니다. 문제는 애정이지.

MS에서 PC의 세상은 끝났다, 타블렛의 시대다 했는데, 정작 그 시점에 애플은 Mac OS X를 성공 시켰다. Windows PC들의 시장 장악력은 떨어져갔지만 상대적으로 Mac OS X의 시장 점유율은 올라고, 물론 여전히 윈도우즈가 판치는 세상이지만, 영향력에선 Windows를 압도했다.

그리고 오히려 나중에 태블렛 시장을 석권한 건(현재까지) 애플이다.

즉 문제는 애정이다.

아무리 모바일의 시대라고 해도, 누군가가 PC에 애정을 갖고 훌륭한 아이디어를 구현해 내면, 그리고 그게 매력적이면 다시 PC세상으로 되돌릴 수도 있다.

그런데 재미난 것은 세상은 경향을 따라 간다라며 지난 것은 마치 가치가 없어진듯 말한다.
대부분의 기업가와 개자들은 그렇게 말한다.

하지만 잊어선 안되는 것이 있다.

가치는 만드는 것이지 존재하는게 아니라는 것이다.

그걸 만드는 사람이 기존의 것에 가치가 없다고 생각할때 가치가 없어지는 것이지, 그 자체로 가치가 있고 없는게 아니다.

즉 이 말은 바꿔 말하면, 이미 구닥다리가 된 것에서 누군가 가치를 발견해 내면, 그것은 다시 한번 세상을 혁신으로 이끌게 될 거라는 것이다.

그래서 남이 가진 장점을 보는 것도 중요하지만, 자기가 잘할 수있는게 뭔지를 찾아내는 것이 더 중요한 것이다. 남이 하니 따라가지 말고…

폰트의 무슨 차이가 이런 문제를 일으킬까?


웹용 폰트로 자주 쓰던 나눈 폰트가 있다. 일반적으로 신문사 사이트를 이용하거나 그 어딜 가도 아무런 문제가 없는 폰트이다.
그런데, 최근에 iPhoto에서 사진을 flickr에 업로드하다 이상한 점을 발견했다.
Mozilla Firefox의 테스트 빌드인 Aurora에서 이렇게 보이는 것이다.

decomposed 형식으로 나타나는 앨범 타이틀 (나문 고딕 적용)

decomposed 형식으로 나타나는 앨범 타이틀 (나눈 고딕 적용)

위의 사진에서 “Glendale 소녀상”은 제대로 나타난다. 그것은 flickr 사이트에서 직접 내가 바꾼 것이다. 반면 decomposed로 나타나는 것은 iPhoto에서 event set의 이름을 정하고 올린 것이다. 다시 말하지만 저것은 나눈 고딕을 이용한 것이다.

자, 그럼 이제 웹 브라우저의 한글 폰트를 AppleGothic이나 AppleMyungjo로 바꾸어서 해보자.

Apple의 폰트로 웹 브라우저의 한글 폰트를 세팅했을 때

Apple의 폰트로 웹 브라우저의 한글 폰트를 세팅했을 때

자. 이때는 “Glendale 소녀상” 뿐 아니라 다른 것들도 제대로 “composed” 형식으로 나온다.

여기서 우리는 몇가지를 알 수가 있다. 즉 flickr에서 직접 바꾼 것은 아마도 애초에 decomposed로 저장되는 것 같다. 반면 iPhoto는 OS 자체가 그렇듯이 저장은 decomposed로 하고 보여 줄 때, composed로 하는 것으로 보인다. 대부분의 OS에서 유니코드 처리를 이렇게 한다.

그런데.. 이상한 거 첫번째…
왜 다른 사이트에선 나눈 고딕으로 해도 잘 보이는데,  flickr만 이럴까? 사실 글을 어떻게 올리냐는 상관없다. 폰트를 정해주는게 아니고, 인코딩이 문제가 되는 것이기 때문에.

둘째, 도대체 나눈 폰트의 뭐가 잘못되어 있길래, 어디서는 decomposed로 그려지며, 어디선 composed로 그려지는가?

아마도 flickr의 스크립트가 폰트의 어떤 정보를 이용해서 글자를 overlay시켜 주는 것 같다. 그런데 HTML에서 저렇게까지 선택적으로 보여주던가?
HTML에선 폰트의 그런 것까지 조절할 능력이.. HTML 5에서 뭐가 바뀌었나? 아니 flickr가 HTML 5를 쓰기나 하나?

어쨌거나, 두 측의 잘못이 있다. 첫째는 flickr, 두번째는 나눈 폰트를 만든 쪽(네이버)이다. 또 하나는 Aurora의 Gecko 렌더링 엔진이다. 아마 진짜 문제는 Gecko와 폰트 쪽에 있을 거 같다.

분명 저 스크립트는 폰트의 어떤 면이 HTML/JavaScript의 코딩에 의해 decomposed쪽으로 결정을 내는 것 같다. 그렇다면.. 폰트를 만든 측이 폰트의 기능 (여러가지 비트들이 있는 것으로 안다. 폰트의 특성을 부여하는 )을 제대로 사용해서 만들지 않았음을 의미한다. 혹은 Gecko 엔진이 그 폰트의 뭔가를 이용해서 decomposed로 결정을 내리는지도 모르겠다.

또한, 재미난 것이 폰트 자체의 예쁘고 밉고를 떠나, 애플 폰트의 렌더링이 더 미려하다는 것이다. 즉 획의 코너나 끝의 처리가 애플 폰트가 더 부드럽게 되어 있다. (이것은 폰트가 애플 것이 더 예쁘단 소리는 아니다. 전체적인 모양이 있기 때문에, 아무리 미려하게 렌더링을 해도 전체 모양이 안 예쁘면, 아무리 렌더링 품질이 좋아도 그다지 예뻐 보이진 않는다)

신기하다.