공간정보시스템 / 3차원 시각화 / 딥러닝 기반 기술 연구소 @지오서비스(GEOSERVICE)
관악구 신림8동.. 전철역에서 10분 걸어 이곳 6층. 꼭대기 층이고 하나뿐이 창문과 이 창문의 잘못된 방향으로 여름엔 사우나가 따로 없는 이곳을 내 임시 거처로 마련한지… 이제 1년하고도 6개월이나 되었다. 이제 몇달 후면 본래의 주인에게 이곳을 넘기고 다른 곳으로 옮긴다는 생각이 문득 들어… 창밖의 야경을 기록으로 남긴다.
운치가 한껏 느껴지지 못하는 야경이지만 가끔 답답한 마음을 달래려 창문을 열면 늘 나를 마지해주는 풍경이다. 폼 잡고서 담배 한대 물고서 하얀 연기 속의 고독과 상념에 빠져야 삶의 멋일진데…. 아쉽게도 나는 담배의 맛을 모른다…
GDI+에서 graphics의 MeasureString 함수를 통해 출력된 문자열의 폭을 구해보면 기대했던 폭 보다 다소 넓게 구해진다. MeasureString 보다 훨씬 정확한 폭을 구하는 방법에 대한 코드이다.
static public int MeasureDisplayStringWidth(Graphics graphics,
string text, Font font)
{
System.Drawing.StringFormat format =
new System.Drawing.StringFormat();
System.Drawing.RectangleF rect =
new System.Drawing.RectangleF(0, 0, 1000, 1000);
System.Drawing.CharacterRange[] ranges = {
new System.Drawing.CharacterRange0,text.Length)
};
System.Drawing.Region[] regions = new System.Drawing.Region[1];
format.SetMeasurableCharacterRanges(ranges);
regions = graphics.MeasureCharacterRanges(text, font, rect, format);
rect = regions[0].GetBounds(graphics);
return (int)(rect.Right + 1.0f);
}
참고로, 이 방법을 알기 전에는 필자는 String에 대한 Path를 만든 후, 즉 GraphicsPath를 만들고 GetBounds 매서드를 통해 크기를 얻었다. 하지만 이 방법은 MeasureString에 비해 정확하기는 하지만 역시 다소 부정확하다. 하지만 여전이 실제 프로젝트 적용에 대해서는 Path를 이용한 방법을 사용하고 있다.
GDI+는 정말 사용하기 편하다고는 말 못해도.. -_-; 사용하면 할 수록 기능면에서는 무척 뛰어난 라이브러리로 생각된다. 하지만 가끔씩 이해하기 힘든 시츄레숀…를 만들곤 해서 날 당황하게 한다. 그래도 그때 그때 잘해결해 나갔는데.. 이번 문제는 해결의 시발점도 찾지 못하것다. 해결 방법을 검색해 볼레도.. 도통 검색 키워드를 뭐로해야할지도 모르겠고… 결국 해결하지 못한 이 문제로 인해 꽤나 많은 시간(대략 5~6시간)을 낭비…
문제는 GDI+를 이용해 문자를 그리는 것으로 그냥 DrawString을 이용해 그리는 것과 GraphicPath를 이용해 문자의 Path를 만든후 그 Path를 그려주는, 두 가지 방법에 대한 결과를 비교한 것이다. “안녕하세요”라는 문자가 보이는데, 노란색은 DrawString을 이용해 그린 것이고, 검정색 외곽선은 Path를 이용해 그린것이다.
똑같은 위치, 폰트, 크기, 정렬, 스타일, 크기단위로 지정해 주었음에도 Path가 문자의 폭이 조금 더 넓게 나온다. 높이는 문제가 없다. 유독 폭만 틀리다.
음…. 이 글을 작성하면서 떠오르는 것이.. 바로 “높이는 문제가 없으나, 폭만 다르다”라는 것에 힌트를 얻을 수 있겠다는 생각이 든다…….
문득 생각이 난 검색어로 “GDI+ drawString GraphicsPath”로 검색해 본 결과 동일한 문제에 대한 Q/A가 있었고 drawString과 GraphicsPath에 대한 속도 테스트 데모를 찾을 수 있었다. 먼저 몇개 Q/A의 경우 drawString과 Path를 이용한 렌더링 방법이 다르다는 점을 들어 다를 수밖에 없다라는 답변이다. 하나의 예로 문자의 경우와 그 외의 그래픽 요소에 대한 렌더링 퀄러티에 대한 옵션 지정이 다르다는 점이다. 개인적으로 볼때 그럴듯하지만 확실하지 않은 답변인데다가 근본적인 해결책을 제시하지 못하는 답변이라 도움이 되지 못했다. 속도 테스트 데모의 경우 실행을 해보니 처음 나타난 drawString과 Path를 이용한 문자열의 크기가 똑 같아 보였으나 폰트를 늘려보니 역시 Path를 이용한 문자열 출력이 drawString보다 더 길게 나왔다. 즉, 동일한 문제점이었다.
유추되는 한가지 원인을 말해보면, 앞서 언급했던 바와 같이 높이는 같으나 폭만 다르다는 점이다. “자간”이 문제가 아닌가 싶다. 즉, drawString의 경우 동일 폰트의 각각의 문자들 마다 다르게 지정되어져 있는 자간값이 고려되어져 화면상에 그리는 반면, Path의 경우 자간이 고려되지 않고 동일한 자간의 값으로 문자들에 대한 Path가 만들어지고 이렇게 만들어진 Path가 그려지게 되기때문이 아닌가 싶다.
여튼, 결국 해결 방법을 찾지 못하고 덮는다.
