Myna - 기호 중심 프로그래밍 언어를 위해 설계된 모노스페이스 폰트

 (github.com/sayyadirfanali)
2P by GN⁺ | ★ favorite | 댓글 2개
  • 프로그래밍 언어에서 자주 쓰이는 기호를 알파벳과 동등하게 다루는 모노스페이스 폰트로, 코드 편집기의 시각적 조화를 목표로 함
  • ASCII 기호 중심 설계를 통해 ->, ::, =~ 등 다문자 기호의 정렬을 개선하고, 균형 잡힌 굵기와 명확한 구분을 제공
  • 언어별 가독성을 고려해 Perl, Haskell, C 등에서 기호와 연산자의 형태를 명확히 표현
  • 현재는 단일 굵기와 비리거처 형태로 제공되며, Linux의 fontconfig·pango 환경에서 합성 볼드 지원
  • SIL Open Font License 1.1로 배포되어 자유로운 사용과 수정이 가능

Myna 개요

  • Myna는 기호를 1급 글리프로 다루는 모노스페이스 폰트로, 프로그래밍 언어에서 기호의 시각적 일관성을 높이는 데 초점을 둠
    • ->, $, @, % 등의 기호가 기존 폰트에서 어색하게 보이는 문제를 해결
    • ASCII의 단순함을 유지하면서 Ligature의 미적 효과를 모방

주요 특징

  • Symbol-First Design: 프로그래밍 언어 전반에 걸쳐 사용되는 ASCII 기호를 중심으로 설계
  • 정렬 정확도: ->, >>=, :: 등 다중 문자 기호의 정렬 정확도를 높여 코드 가독성 향상
  • 균형 잡힌 두께(Weight): 기호와 문자 간의 대비가 조화롭게 유지
  • 미니멀한 형태: 따옴표와 쉼표 등은 기하학적 형태로 단순화
  • 명확한 구분성: 1, l, I, |, 0, O, o 등 혼동되는 문자의 구별 강화
  • 언어 인식형 디자인: Perl의 Sigil, Haskell의 연산자, C의 기호 표현을 각각 명확히 표시

개발 배경 및 현황

  • 기존 모노스페이스 폰트의 세부 글리프에 만족하지 못해 직접 제작된 서체
  • 개발자 본인이 전문 및 개인 프로젝트에서 장기간 사용한 후 공개
  • 현재는 단일 두께, 비-Ligature 버전으로 제공되며, 향후 수요에 따라 확장 가능
    • Linux 환경에서 fontconfig 및 pango를 통한 합성 볼드 지원
  • SIL Open Font License 1.1 적용
  • 초기 버전은 Hera(Source Code Pro 기반 커스터마이즈)에서 출발
  • Fira Mono, Inconsolata, Plex Mono, Office Code Pro, Anonymous Pro 등 다양한 폰트의 장점을 참고하여 발전함

향후 계획

  • 터미널 및 에디터 전반에서의 범용 사용을 목표
  • 비ASCII 글리프(기하학·수학 기호 등) 일부 포함
  • 커뮤니티 피드백에 따라 글리프 확장 및 기능 추가 예정

함께 보면 좋은 글 β

bobross0   [-]

젯브레인 폰트 쓰는데 흥미롭네요

답변달기
GN⁺   [-]
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라는 아이콘 폰트가 존재함. 혼동될 수 있을 듯함

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