Open Web 짝사랑. iOS Programming.
Apple의 Preview를 가지고 PDF로 된 문서를 열면 귀찮지만 꼭 해야 하는 일이 하나 있다. 창 크기를 늘리고 글자 크기를 보기 편하게 확대하는 것. 그런데, 문제는 이렇게 설정해 두었던 창 크기와 글자 크기는 Preview를 다시 열면 까맣게 잊어버려서 또 다시 창을 늘리고 연거푸 Command와 +키를 눌러줘야 했다.
하지만, 이제 PDFView를 설치하고 더 이상 필요없는 Command-+는 잊으란다.
아직 초기 버전이지만 PDF 문서를 보는 데는 불편함이 전혀 없다. 물론 이놈의 최대 무기이자 동시에 Preview에서는 가장 아쉬웠던 기능으로서, PDF 파일을 열면 무조건 창 크기를 최대치로 잡고서 창 크기에 맞게 글자를 확대해서 보여준다.
GNU Lesser General Public License (LGPL)로 무료로 공개 배포되고 있으며, 당분간 Preview의 자리는 PDFView에게 내어주게 생겼다.
예쁜 아이콘들과 바탕 화면 그림들 그리고 맥의 아쿠아 인터페이스를 대체하는 여러 테마들을 모아놓은 InterfaceLIFT는 내가 자주 방문하는 곳인데, 마침 이 곳에 새로 올라오는 주제별 작품들을 Dashboard에서 바로 확인할 수 있도록 하는 InterfaceLIFT.com Widget이 Apple의 Dashboard Widget들의 소개 페이지에 등록되어 있다.
그런데, 쓰면서 한 가지 아쉬운 것이 있다면, 이왕에 편하자고 쓰는 거면 창에서 보여주는 아이콘들과 배경 화면 그리고 테마들 간의 선택을 뒤쪽 설정판까지 가서 설정해 줄 필요없이, 그냥 앞의 보여지는 창에서 바로 선택해서 볼 수 있다면 더 편하지 않을까?
목마른 사람이 우물을 판다고 (물론 제작자의 동의 없이), 뒤쪽에 있는 선택 메뉴를 앞쪽 판에도 추가하고, 덩달아서 메뉴 선택시 이미 선택되어져 있는 항목에 ✓를 올바로 표시해 주지 못 하던 벌레까지 잡게 되었다. 8)
이것도 물론 소스 코드가 완전히 공개되어 있는 widget의 개발 환경이 가지고 있는 장점 덕분에 가능한 일이다.
아무튼, 광적으로 widget들을 수집하는 습관 때문에 이미 Dashboard 화면에는 꽉 들어찬 모두 20개나 되는 widget들로 인해 더 이상의 자투리 공간마저 없는 실정이다. 이리저리 widget들의 자리를 바꾸어 주면서 남은 공간을 확보해 보려는 노력도 더 이상은 소용없을 지경이라서, 어쩌면 widget 수집광들의 필수도구라 할 만한 요놈을 설치해야 할 날이 올지도… 😛
이미 Apple의 Photo Booth에는 여러가지 특수 효과들을 적용해서 사진을 찍을 수 있다는 것은 널리 알려진 사실이다.
그런데, Quartz Composer 기술을 이용한 다양한 특수 효과들을 지원하는 또 하나의 재미있는 어플리케이션이 있다. 바로 Funny Photographer.
위에 보여지는 Edge work 말고도, 모두 24 가지의 특수 효과들을 적용할 수 있으며, Quartz Composer를 다룰 줄 안다면, 자기만의 효과를 구현할 수도 있다.
iSight 혹은 지원하는 Webcam만 있다면, 또 하나의 재미난 특수 효과 놀이를 즐길 수 있다. 😆
Firefox가 가지고 있는 여러 장점들 중에는 확장성을 빼놓을 수 없을 것이다. 수 많은 기능들로 무장한 확장자들(Extensions)은 웹 항해와 탐험을 훨씬 수월하게 해준다.
하지만, 너무나 다양한 선택의 폭은 오히려 자신에게 필요하고 쓸모있는 것을 고르는데 부지런함을 요한다. 그래서, 이렇게 다양한 확장자들 중에서 자신이 원하는 것을 고르는데 도움을 주고자 공개된 Firefox 확장자들의 소개 문서도 있다.
아래는 나의 Firefox에 설치되어 있는 확장자들.
제목은 말 그대로, 정확한 적용 시점은 아직 알려지지 않았으나, 차기 버전의 WebKit의 변화에 대비하기 위한 Dashboard Widget 개발자들이 취해야 할 조치사항이다.
Surfin’ Safari의 Blog에 올려진 글에 의하면, 차기에 발표될 WebKit에서는 그 동안 HTML과의 호환성을 이유로 여러 요소들에 사용되었던 XML 형태로 된 단독 꼬리표 닫침 용법(예를 들어, <script src="myscript.js" />)들을 실제로 꼬리표가 적절하게 닫힌 것처럼 인식하게 하는 기능이 제거될 것이며, 따라서 이러한 꼼수(hack)들을 수정하지 않으면 해당 widget들의 스크립트는 코드가 실행되지 못하게 되면서 제대도 작동하지 않을 것이라고 경고하고 있다.
그래서, 차기 버전의 WebKit에서도 자신의 widget들이 제대로 작동되게 하려면, 단독 꼬리표 닫침 용법을 사용했던 <script>와 <canvas>의 경우 또 하나의 닫침 꼬리표를 추가해주어야 한다.
,
개인적으로, 앞에 공백 하나를 더한 단독 꼬리표 닫침 용법이 단지 HTML과의 호환성을 위한 하나의 hack이였다는 사실을 미쳐 눈치채지 못했다.
결국, Doctype!을 지정하였더라도 xhtml 문서를 application/xhtml+xml 혹은 text/xml MIME 형태로 서버에서 전달하지 않는 한은, 일반 html 문서일 수밖에 없다. 그렇다고, 웹 문서를 진정한 xhtml 형태로만 전달할 수는 없는 이유는 썩을 놈의 Microsoft Internet Explorer가 진정한 XHTML 문서를 전혀 다룰줄 몰라서 단지 문서 통채를 내려받기 때문이다.
이러한 상황에서, 굳이 xml 형태의 문서가 필요하지 않는 경우, XHTML을 가장한 HTML을 작성할 것이 아니라, 아직은 HTML4 형태의 문서로도 충분할 것이라고 말을 끝맺고 있다.
모든 웹 브라우져들이 아직 XHTML을 제대로 처리하지 못하는 과도기적 상황에서 웹 개발자들에게는 XHTML로의 완전한 이주는 험란한 일이겠지만, 과거에만 머물러 있을 수도 없는 노릇이다. 그래서, 정작 중요한 것은 단지 표준에 맞는 마크업(markup) 뿐만이 아니라, HTML4 시절에는 더딜 수밖에 없었던 내용으로부터의 표현과 동작의 완전한 분리, 웹 접근성 그리고 의미론적 마크업이 XHTML로 전진해야 하는 이유일 것이다.
위 내용과 관련해서 추가 참고가 될 만한 글들: