Hacker News 의견

• 최근에 Iosevka(발음은 Joseph)로 바꾼 이유가 바로 이런 간결함 때문임
  Iosevka GitHub 링크
  재미있는 점은 이 폰트의 소스코드를 실제로 읽을 수 있을 정도로 구조가 명확하다는 것임

  • Iosevka는 정말 아름다운 폰트임. Myna의 압축된 형태(condensed look) 도 사실 Iosevka에서 영감을 받았음
    이전 버전인 Hera는 Source Code Pro를 커스터마이징한 비압축 버전이었음
  • Iosevka는 자체적으로 커스텀 빌드를 지원해서 다양한 글리프 변형과 리거처 선택이 가능함. 꽤 놀라운 수준임
  • Iosevka가 Joseph의 변형이라는 걸 이제야 알게 됨. 수년간 써왔는데 발음조차 몰랐음. README에 있었는데도 말임
  • Pragmasevka도 한 번 써볼 만함. Iosevka에서 넘어왔는데 가독성이 조금 더 좋게 느껴짐
  • 나는 Iosevka Orw를 사용 중임. 표준 Iosevka와 일반 monospace의 중간 정도 폭이라 이상적임

• 솔직히 말하면 “symbol-heavy 언어를 위한 폰트”라는 설명이 잘 이해되지 않음. 기호들이 평범해 보임. 혹시 간격이 조금 넓은 걸까?

  • GitHub 페이지의 첫 번째 포커스 항목이 “Near-Perfect Alignment”임. 즉, ->, >>=, :: 같은 다문자 기호들이 완벽히 정렬된다는 뜻임
  • 디자이너임. 여기서 말한 symbol-heavy 언어는 Perl이나 Haskell처럼 기호 사용이 많은 언어를 의미함. 나는 리거처를 쓰지 않으면서도 정렬이 깔끔한 폰트를 만들고 싶었음
  • 디자인 차이를 설명할 때는 실제 비교 예시가 필요함. 비교 이미지가 없으니 혼란스러울 수밖에 없음

• 폰트가 꽤 예쁨. 다만 샘플에서 emdash(—) 문자가 빠져 있는 것 같음. Markdown을 자주 쓰는데, 많은 프로그래밍 폰트가 이 문자를 잘못 표현함
  스크린샷이 다른 폰트들보다 훨씬 평가에 도움이 됨

  • 맞음, em-dash는 단순한 문자 이상임. 좋은 글쓰기의 핵심 요소라고 생각함 (농담 반 진담 반)
  • 피드백 고마움. 이 폰트에서는 en-dash를 넓게 만들어서 em-dash와 구분이 어려움. 나는 em-dash를 거의 안 써서 구분 필요성을 느끼지 못했음
    그래도 요청이 있다면 개선을 검토하겠음

• 많은 폰트와 마찬가지로 이 폰트도 수직 화살표(↑↓) 정렬이 어색함
  ^ 문자는 원래 타자기 시절 circumflex 악센트를 위한 것이었음. 그래서 높이가 비대칭임. caret의 하단이 v와 대칭되면 좋겠다고 생각함

  • 나는 caret을 위아래 화살표로 쓰는 걸 본 적이 없음. 대칭이 꼭 필요하다고는 생각하지 않음
  • caret을 수직 화살표로 쓰는 건 비현실적임. 두 줄에 걸쳐 입력해야 하니까. 실제로 이런 걸 쓰는 언어가 있는지도 궁금함
  • 혹시 줄을 넘는 리거처를 만들려는 건가? 그냥 Unicode의 ↑를 쓰는 게 낫지 않음?
  • 디자이너임. 이런 조합은 감지하기 어렵고, caret은 본래 연산자 기호라서 프로그램적 의미를 깨뜨리면 안 됨. v와 비교하는 건 불공평함
  • caret의 역사적 이유는 중요하지 않음. 지금은 모두 그 모양에 익숙함. 이런 특수한 케이스를 위해 폰트를 바꾸면 오히려 혼란을 줌
    폰트는 예상 가능한 형태를 유지해야 함

• “->가 화살표처럼 안 보인다”는 불만에 대해, 진짜 해결책은 ←→ 같은 실제 화살표를 쓰는 것임. 언젠가 언어들이 더 나은 타이포그래피 품질을 지원하길 바람

  • 디자이너임. 우아함과 일관성을 동시에 얻는 건 불가능함. 우리는 리거처 없이도 ASCII 기반 코드가 보기 좋게 보이도록 노력 중임
  • 리거처는 존재함

• JuliaMono는 Julia 언어의 전체 Unicode 지원을 위해 설계된 폰트임

  • 링크 고마움. 글리프가 매우 풍부해 보임. 폰트 한계를 넘기 위해 JuliaMono2, 3, 4 같은 fallback 체계를 쓰는 것도 흥미로움
  • 디자이너임. 나는 주로 ASCII 범위에서 작업하지만, Myna에 JuliaMono를 보조 폰트로 설정하면 Unicode 커버리지를 확장할 수 있음

• 폰트가 예쁘긴 한데, 상단의 “Lorem” 글자 간격이 너무 벌어져 보여서 커닝(kern) 이 어색하게 느껴짐. 개인적으로는 신경 쓰임

  • 디자이너임. 매일 쓰다 보니 결함에 둔감해졌음. 그래도 지적은 타당함. 다음 버전에서 커닝 수정을 고려하겠음. 구체적인 예시가 있다면 이슈로 남겨주길 바람

• 리거처(ligature) 는 개발자들 사이에서 꽤 논쟁적인 주제임
  어떤 사람은 코드가 더 아름답고 읽기 쉬워진다고 하고, 어떤 사람은 “기호를 숨기는 건 불필요하거나 부정직하다”고 봄
  또 어떤 사람은 “언어가 Unicode를 제대로 지원했다면 리거처가 필요 없었을 것”이라 말함
  결국 이 프로젝트는 세 진영 모두를 동시에 자극했지만, 그래서 더 흥미로움. GitHub에서 별을 눌렀음

  • 대부분의 에디터에서 리거처는 옵션으로 켜고 끌 수 있음. 그래서 누구도 배제되지 않음

• 기호들이 소문자 옆에서 너무 높게 배치된 것 같음. 괄호 정렬에 맞추려다 생긴 문제로 보임. 균형감이 조금 아쉬움

  • 디자이너임. 일반 폰트는 텍스트 중심이라 전통적인 정렬을 따르지만, 코드는 텍스트가 아님
    전통을 깨면 오히려 가독성이 좋아짐. 하이픈은 >와 정렬되어 화살표 형태를 이루도록 설계했음

• 이미 Myna UI라는 아이콘 폰트가 존재함. 혼동될 수 있을 듯함

  • 디자이너임. 알려줘서 고마움. 그래도 큰 혼란은 없을 것 같음