1
글꼴로 작업하는 코드를 작성해야합니다. 내가 시작하게하는 주제에 대한 좋은 소개가 있는가?글꼴에 대한 좋은 소개는 어디서 찾을 수 있습니까?
A
답변
4
What every developer should know about fonts에 대한 소개가 있습니다.
나는 여기에 게시물을 복사했지만 포스트는 많은 부분이 특정 글꼴에 의존적이어서 사진을 써서 위 링크를 강력히 추천합니다.
원래 글꼴을 사용하는 것이 매우 간단하다고 생각했습니다. 그러나 Windward Reports (XML 및 SQL보고 시스템)에서 중요한 글꼴 인 글꼴 처리가 마무리되었습니다. 양식에 한 줄의 텍스트를 배치하는 것보다 훨씬 많은 일을한다면 세부 사항이 중요합니다.
글꼴 & 글리프 그래서 글꼴이 무엇입니까? 근본적으로 글꼴은 일련의 글리프입니다. 문자 A와 같은 문자로 생각하는 것은 글리프입니다. 글꼴은 그 글꼴의 모든 글자에 대한 글립 문자 세트입니다. Helvetica 글꼴을 사용하면 모든 문자 모양이 한 방향으로 보입니다. Times Roman 글꼴을 얻으면 다른 글꼴을 보게됩니다. 각각은 해당 글꼴의 글리프 세트입니다.
이제 코드 페이지의 개념을 소개해야합니다. 코드 페이지는 문자 번호에서 특정 글리프 (glyph) 로의 매핑입니다. 프로그램은 원래 각 문자를 바이트로 저장했습니다. 그런 다음 아시아 문자 세트의 경우 DBCS 시스템이있었습니다 (일부 문자는 1 바이트, 일부는 2). 오늘날 프로그램은 주로 유니 코드를 사용하지만 웹 페이지는 최대 4 바이트가 될 수있는 멀티 바이트 시퀀스 인 UTF-8 경향이 있습니다.
왜 인코딩을 불러 오나요? 각 글꼴에는 문자 번호 178이 글꼴에서 사용하는 코드 페이지에 따라 매우 다른 문자 모양을 반환 할 수있는 인코딩이 있기 때문입니다. 대부분의 글꼴 파일은 유니 코드를 사용하므로 거기에 표준이 있지만 많은 프로그램은 특정 코드 페이지를 사용하며이 페이지는 글꼴에 매핑됩니다. 이것은 ABC를 표시 할 때 글꼴이 Wingdings이므로 을 얻을 때 발생합니다. 요점은 사용하는 인코딩이 일치하거나 사용하는 글꼴의 인코딩에 매핑되는지 확인해야한다는 것입니다.
그리고 더욱 복잡해집니다. 값이 0xE000 - 0xF8FF 인 문자는 정의되지 않습니다. 각 글꼴은 원하는 모든 것을 만들 수 있습니다 (한 가지 용도는 Klingon 스크립트를 추가하는 것입니다). 따라서이 범위의 값을 가진 문자는 정의에 따라 해당 글꼴을 표시하는 데 사용하는 글꼴 파일과 연결됩니다. 이것이 대부분의 기호 유형 글꼴이 작동하는 방법입니다.
여러분이 유니 코드를 사용하고 있으므로 글꼴 파일이 유니 코드를 사용하고 문자열을 전달하면 문자열에 아무 것도 표시되지 않습니다. 무슨 일이야? 음, 글꼴 파일에 주어진 문자에 대한 글리프가 있어야한다는 요구 사항은 없습니다. 기호 글꼴에는 ABC가 없습니다. 유럽과 미국에서 사용되는 대부분의 글꼴에는 중국어, 일본어 또는 한국어 글리프가 없습니다. 글꼴에없는 글리프를 사용하는 것은 오류가 아니지만 공백이 아니라 아무 것도 표시하지 않습니다 (예 : 0 포인트 너비).
코드 페이지에 존재하지 않는 글리프를 표시하려는 경우 이전 코드 페이지 중 하나를 사용하는 경우에도 유사한 문제가 발생할 수 있습니다. 이 경우 최소한 다른 코드 페이지에 매핑해야합니다 (Word가이 경우를 처리하는 방법입니다).
글꼴 패밀리 글꼴은 여러 가지 다른 클래스로 분류됩니다. 먼저 비례 대 모노 스페이스 글꼴이 있습니다. 고정 폭 글꼴에서는 모든 문자가 정확히 같은 너비입니다. 그리고 모든 소문자는 모두 대문자와 같은 높이로 일관되게 나타납니다. 고정 폭 글꼴은 읽는 것이 훨씬 어렵 기 때문에되도록 많이 피하십시오. 아시아 글꼴은 중국어 한자가 모두 동일한 폭과 높이를 갖기 때문에 고정 폭 글꼴을 사용하므로 거의 비례하지 않습니다. 한편, 히브리어와 아랍어는 거의 비례해야합니다.
다음으로 뇌졸중이 끝날 때 세리프가 될 수있는 서체가 있습니다. 마지막에 아무 것도 얻지 못하는 산 세리프 (sans serif), 정상 이상으로 장식하는 장식물, 무엇이든 가질 수있는 상징물입니다. 글리프에 매핑 된 문자 코드의 ASCII 번호와 일치하는 바코드를 포함한 임의의 문자입니다. 그리고 이것은 서유럽 알파벳 일뿐입니다.
Fontmetrics 이제 글꼴을 측정하고 글꼴의 대부분 (전부는 아님)이 글리프를 측정합니다. 글꼴에 사용되는 표준 측정은 요점이며 요점은 컴퓨터 세계에서 72 포인트 == 1 인치였습니다. 포인트의 20 분의 1을 나타내는 twip도 볼 수 있습니다. 따라서 1440 twips == 1 인치입니다. 이제 우리는 EMU를 914400 EMU == 1 인치 (여기) 더 있습니다. 점으로 작업하는 경우 부동 소수점 변수를 사용해야합니다. 트윕은 일반적으로 정수로 확인되며 EMU는 분명히 있습니다.
그런 다음 글꼴 크기가옵니다. 이것은 완전히 임의의 숫자입니다. 실제 CRT 모니터의 대각선 크기와 비슷하다고 생각하십시오. 실제 크기가 예상 한 값과 비슷하지만 결코 그 수가 아닙니다. 포인트 크기는 렌더링 된 글리프의 크기를 결정하지만 페이지에 특정 측정 값이 없습니다.
이제 재미있는 부분이 시작됩니다. fontmetrics. 첫째, 모든 것이 기준선에서 측정되어야합니다. 글꼴의 다른 부분에서 작업해도 작동하지 않습니다. 중요한 문제가 발생할 것입니다. 그래서 거기서 시작하십시오. 기준선 위로 가장 높은 그려진 부분은 기준선에서 측정 된 상승도와 기준선 아래의 가장 낮은 그려진 부분이 강하다는 것입니다.
두 줄의 텍스트 사이에 간격이 있습니다. 글꼴 디자이너가 해당 글꼴의 적절한 간격을 결정할 때 글꼴 설정입니다. 이것은 다른 방식으로 반환 될 수 있습니다. Windows는이 값을 기준선에서 기준선으로 반환하는 다음 줄 위에 놓는 간격을 고려합니다. Java는 다음 줄보다 먼저 줄 아래의 간격으로이 값을보고이 값만 반환합니다. 이 선행은 유사한 단일 간격 텍스트 행 사이에 놓는 간격입니다. 간격이 단일 간격보다 큰 경우이 값에 추가합니다.
일반적으로 표시되는 문자열의 글리프 문자열이 아닌 글꼴 높이를 얻으려고합니다. 왜? 왜냐하면 라인이 "우리가 wrox"라면, 오름차순이나 디 센더없이 라인은 단락의 다른 라인에 더 가깝게 배치 될 것이고 그것은 이상하게 보일 것입니다. 또한 텍스트가 더 큰 경우 큰 상승/하강/선행 값을 사용해야하므로 글꼴 및 포인트 크기를 모두 확인해야합니다. 그러나 전체 단락이 아니라 큰 텍스트가있는 줄만 사용해야합니다. 다시 말하지만,이 모든 것은 혼합 된 글꼴/크기를 처리 할 수있는 유일한 방법 인 기준선으로부터 측정됩니다.
높이는 약간의 작업이 필요하지만 꽤 간단하지만 너비는 매우 흥미 롭습니다. 흥미로운 것은 모든 것을 올바르게해야한다는 것입니다. 근본적으로 고정 폭 글꼴을 제외하고는 각 글립의 너비를 합하면 함께 렌더링되는 모든 글립의 너비와 같지 않습니다. 꽤 많이. 왜? 두 가지 이유 :
• 커닝은 문자가 인접 문자에 따라 배치되는 위치입니다. AB가 왜 겹치는 동안 AB는 별개의 존재로 남아 있습니다. • 라틴어 알파벳의 일부 문자 조합은 æ로 변하고 æ로 바뀌고 독일어로는 ß가됩니다. • 히브리어 및 아랍어 글리프는 단어의 시작, 중간 또는 끝에 있는지 여부에 따라 동일한 문자에 대해 다릅니다. 그리고 아랍어의 경우 특히 끝에서 사용되는 글리프는 중간의 글리프보다 넓어지는 경향이 있습니다. 따라서 ص의 너비는 문자열에있는 위치에 따라 다릅니다. ◦ 양방향 글꼴에는 아래에 나열된 추가 문제가 있습니다. • 인도 (인도)와 같은 복잡한 스크립트는 여러 문자로 구성된 위치에서 글리프를 변경합니다. 따라서 3 자 문자열은 1 ~ 3 글리프 너비의 문자 일 수 있습니다. 문자열의 길이를 얻기 위해 실행중인 플랫폼에서 제공하는 fontmetrics API에 완전한 형식의 완전한 문자열을 제공해야합니다. 문자열은 길이를 결정하기 위해 메모리로 렌더링되기 때문에 값 비싼 호출이지만 정확한 대체 방법은 없습니다. 그리고 렌더링 할 때와 똑같이 측정을 사용해야합니다. 이들이 일치하지 않을 때마다, 우리는 인간의 눈으로 그들을 만들 수있는만큼 큰 차이를 발견했습니다. 이것에 대한 코드를 테스트하는 가장 좋은 방법은 오른쪽 정렬 된 텍스트를 보는 것입니다. 일반적으로 렌더링 할 때 문자열의 왼쪽 끝의 기준 위치를 가져와야하므로 길이를 잘못 계산하면 표시됩니다.
양방향 텍스트 마지막으로 양방향 텍스트 (아랍어 & 히브리어) 문제가 있습니다. 양방향 텍스트는 오른쪽에서 왼쪽으로 이동하지만 숫자와 라틴어 단어는 왼쪽에서 오른쪽으로 이동합니다. 그래서 오른쪽에서 왼쪽으로 읽은 다음 라틴어 텍스트의 번호 나 순서에 따라 가장 왼쪽 지점으로 건너 뛰고 왼쪽에서 오른쪽으로 읽은 다음 이전 히브리어/아랍어를 완성한 곳으로 이동 한 다음 라틴어/숫자 부분을 선택하고 오른쪽에서 왼쪽으로 돌아갑니다.
이러한 스위치를 수행해야하는시기에 많은 연구가 수행되었습니다. 방향이 강한 문자, 방향이 약한 문자 및 방향이없는 문자가 있습니다. 이 규칙을 올바르게 시행 할기도가 없습니다. 없음. 그러나 모든 것이 사라지지 않습니다. Java와 Windows를 포함한 거의 모든 플랫폼에는 읽기 순서대로 문자 스트링을 제공하는 API가 있으며 규칙에 따라 올바르게 렌더링됩니다. 또한 캐럿 1 문자를 앞으로 또는 뒤로 이동하려는 경우 각 문자의 위치와 이동할 문자를 알려주는 API도 있습니다.
텍스트에 관계없이 모든 글꼴 렌더링 및 캐럿 이동에이 API를 사용할 수 있으며 복잡한 스크립트에서도 잘 작동합니다. Bi-di 또는 복잡한 스크립트를 목표로하지 않는 경우이 작업을 시작하는 것이 약간의 어려움이 있습니다. 그러나 결국에는 거기에있게 될 것이므로 사용을 시작하는 것이 가장 좋습니다. 따라서 다시 작성하지 않아도됩니다. 암호. 날 믿어, 너는 정말로 정말로 재구성하는 것을 원하지 않는다 (나는 한 번 - 어야만했다!).
경고 Linux 또는 다른 운영 체제로 Windows 글꼴을 복사하지 마십시오. fontmetrics는 꺼져 있고 텍스트는 보입니다. 나는 트루 타입이 이식성이 있어야한다는 것을 모르지만 실제로 자바가 어디에서나 디버그를 작성하는 것처럼 폰트는 어디서나 한 번 디자인을 조정하는 경향이있다. 해당 플랫폼에 맞게 글꼴을 최적화 한 공급 업체의 글꼴을 가져옵니다.
+1. 좋은 대답! –