Phycical File Types

• EPD File : Formatted Text File (unicode supported)

• Schematic Symbol Library File : sqlite3 database file (unicode supported) , data format = Formatted Text , 추후 Oracle , MySql 같은 RDBMS 로도 확장 가능

• Schematic File : Formatted Text File (unicode supported)

• Configurations : Json or Ini (unicode supported)

Open Extension System

Extension System 은 프로그램의 확장성을 극대화 하는 기능으로 준비된다.

이는 메인 프로그램을 수정 , 배포 , 재 설치하지 않고 기능을 추가 또는 제거, 기능의 변경 등을 제공해 준다.

Extension 을 만들기 위해서는 다음 두 가지 방법을 사용할 수 있다. 두 방법 중 어느 하나로도 가능하며 둘을 결합해서 사용할 수도 있다.

• Shared DLL을 이용하는 방법

• Lua Script (추후 Python 도 추가할 예정임) 를 이용하는 방법

Rendering Pipeline

Rendering 이란 어떠한 준비된 데이터(vector or raster image) 들을 특정한 canvas 에 그려서 이미지화 하는 작업을 말한다.

데이터가 정적이고 이를 한번 렌더링 하면 사진과 같은 이미지가 되고, 데이터가 실시간으로 변하며 이를 실시간으로 렌더링 하면 동영상이 된다.

CAD 데이터를 rendering 하는데 있어서 renderer 를 선택할 수 있다.  renderer 는 정해진 규칙은 없으나 그 출력물의 용도에 맞춰서 renderer 를 만들게 된다.

실제 CAD 그리는 작업을 위해서 OpenGL 과 같은 graphic library 를 이용하여 renderer 를 구성한다. 이것을 사용하면 데이터가 화면에 보여지게 된다.

우리는 CAD 데이터를 PDF, PNG, SVG , PS 파일과 같은 다양한 파일 포멧으로 출력할 필요가 있다.

이러한 경우 우리는 해당 format 에 맞는 renderer 를 만들어 연결하면 된다.

CAD DATA -> Renderer -> Output Data -> 출력 또는 파일 저장, 또는 전송

데이터의 흐름은 위와 같고 이러한 흐름을 제어 하면서 처리 하는 구조가 Rendering Pipeline 이라 한다.

여기서 Renderer 만 다른것으로 교체하면 Output 이 다른 포멧으로 출력이 될 것이다.

우리는 다음과 같은 Renderer를 준비한다.

• OpenGL Renderer

• Image Renderer (PNG 등 다양한 포멧 지원)

• SVG Renderer

• PDF Renderer

• Postscript (PS) Renderer

EPD (ECAD Paper Document) and EPD EditFrame

• EPD File은 단독 파일에 저장된다.

• EPD File에 저장되는 내용들
  - CGE 정보
  - Graphic Items
  - HV Snap List

• CGE 정보가 저장되기 때문에 저장된 EPD를 다시 읽을 때 LookAt 정보 및 Zoom Factor 가  저장될 때를 유지한다. 즉 저장될 때 화면의 보여지는 상태를 다시 읽을 때 유지 된다.

• Schematic Editor 또는 PCB Editor에 사용할 수 있도록 한다. 이 경우 CGE 정보 및 HV Snap List 정보들은 무시 된다.

EPD Drawing Entity

• line segment

• circle

• arc (circular arc)

• rectangle

• image

• text

• curve (cubic bezier)

• pathline (polylgon)

• field

• ellipse

• elliptical arc

Window Form 과 EditFrame 의 분리

Window Form

• Window Form 이란 ms windows 에서 구현되는 window handle을 갖는 윈도우 리소스로 title bar , menu, toolbar 등 각종 window resource를 이용하여 구성된다. 이는 사용하는 OS 에서 제공되는 리소스를 이용하기 때문에 OS 종속적이다.

• 주고 menu, toolbar, widget, 각종 dialog 등을 구현한다.

• 우리는 일차적으로 ms windows 에서 구동하는 버전을 만든다.

• VCL Form을 이용하여 wndow form 을 구성한다.

• Window Form 은 SForm 과 PForm 을 준비한다.

• SForm 은 Schematic 관련, PForm 은 PCB 관련

EditFrame

• EditFrame 이란 CAD를 화면에 rendering 해주고 각종 그리기 기능등 여러가지 CAD 로서의 기능을 구현한 모듈이다.

• OpenGL 을 그래픽 엔진으로 사용하며 OpenGL Frame에 의하여 화면에 rendering 된다.

• 순수 C/C++ code 및 OpenGL API를 이용하기 때문에 컴파일러의 구성에 의하여 다양한 OS 에 작동하는 build를 수행할 수 있다.

• OS 리소스를 사용하지 않기 때문에 OS 독립적이다.

• OpenGL Frame 을 기반으로 그 하위 Frame 들을 구성한다.

• EPDEditFrame , SCHLibFrame , SCHFrame 과 같은...

Window Form 과 Edit Frame은 완벽히 분리되어 build 되고 프로그램 실행 시 능동적으로 연결되어 작동한다.

이렇게 두 모듈을 구분하는 이유는 OS 종속인 Form 부분을 바꾸면 해당 OS에서 작동 가능하도록 하기 위함에 있다.

이러한 이유로 Frame 은 리눅스 데스크톱 또는 OSX 의 Form 을 구현하여 연동 가능하다.

Colouring System for ECAD

ECAD 는 각종 Graphical Geometry 성분들을 화면에 표현 해 줘야 한다. Schematic 부분과 PCB 부분의 색상에 대한 전략은 조금 다르다.

PCB 의 경우 (PCB 뿐만이 아니라 Layer 의 정책을 사용하는 툴인 경우) 해당 layer 에 정해진 색상으로 표시 되어야 한다.

그러나 Schematic 부분에 대한 색상 처리 전략은 다음과 같이 여러가지 방식을 중 하나를 선택할 수 있다.

• entity 종류 분류에 대한 색상 설정

• 각 entity 에 대한 개별적 색상 설정

위 두 가지는 모두 장점과 단점이 있다.

entity 종류별 분류 색상 설정은 장점으로는 일괄적으로 색상을 지정하고 변경할 수 있다는 것이고 이것이 단점이 될 수도 있다. 즉 개별적으로 색상을 지정하고자 한다면 지원 불가능 하다.

이에 반해 각 entity 마다 색상을 지정할 수 있는 방식을 사용할 수 있다. 그러나 이 경우에는 색상 표현에 있어서 매우 자유도가 높으나 일괄적인 색상 변경에 애로 사항이 발생한다.

그러므로 우리는 이 두가지를 모두 실현 가능하고 사용자가 원하는 방향으로 자유도를 높이는 방식을 선택해야 한다.

Named Colouring System

우리는 named colouring system 이라는 방식을 선택하였다.

이는 사용자가 원하면 entity 별로 색상을 지정할 수도 있고, 설정된 named color를 이용하여 colouring 할 수도 있다.

물론 named color 역시 사용자가 원하는 이름으로 추가하고 등록할 수 있으며 변경할 수 있도록 할 것이다.

Colour Space

BGRA (Blue, Green Red, Alpha) color space 를 사용한다.

SVG Icon

프로그램을 구성하는 UI 중 하나가 menu 및 toolbar button 들이다.

여기에는 menu를 구성하는 caption text 가 있으며 이는 string 처리 문제에 의한 Unicode 지원 여부가 있으며 이는 앞서 언급한 내용으로 정리한다.

다음으로 생각해야 할 것이 image icon 의 구성이다.

icon은 menu에 표시 될 수도 있고 또한 toolbar 를 구성하는 button 의 이미지로 구성하게 된다.

기존에는 bitmap 또는 png, ico 파일을 이용하여 button image를 구성하였다.

그러나 이러한 raster image를 사용할 경우 button size의 변경에 대한 확대 또는 축소에 의한 image의 변형이 나타나고 있다는 점이 단점이 되었다.

컴퓨터 해상도의 증가 및 픽셀 분해 능력이 향상되면서 이 문제는 더 크게 된다.

우리는 이를 극복하기 위하여 raster image가 아닌 기초부터 vector graphic 인 svg 형식을 지원하여 이러한 문제를 해결하고자 한다.

GPU Acceleration and Shader Programming

다음 내용은 GPU 가속에 대한 AI 의 대답이다.

GPU 가속(GPU Acceleration)은 그래픽 처리 장치(GPU)를 사용하여 컴퓨팅 작업의 처리 속도를 높이는 기술입니다. 전통적으로 CPU만을 사용하는 것보다 데이터를 병렬로 처리할 수 있어, 그래픽 렌더링, 비디오 편집, 과학 계산, 머신러닝 등과 같은 작업에서 더 빠른 성능을 제공합니다. GPU 가속은 특히 대규모 데이터 집합을 다루거나 복잡한 계산이 필요한 작업에서 효과적입니다. 

지금의 Graphic Card 장치에는 GPU 가 있으며 이는 PC의 CPU 격에 해당한다. 그러나 GPU는 core 수가 매우 많은 병렬 처리 가능한 장치이다.

또한 Graphic Card 장치는 자신이 직접 사용하는 메모리 장치를 스스로 갖고 있다.

우리는 이러한 GPU 와 GPU가 직접 접근하는 Memory에 데이터를 저장하고 이를 처리하는 것을 GPU 가속을 사용한다고 말한다.

그냥 그래픽 카드가 비싸고 좋은 것이면 무조건 그래픽 가속이 되는 것이 아니다. 프로그램적으로 그렇게 하도록 코딩을 해 줘야 한다.

그러면 이러한 GPU 가속을 사용하면 왜 처리 속도가 빠를까? 그 원리를 이해하지 않아도 별 상관은 없지만 여기서 간략하게 설명하여 이해를 돕고자 한다.

이러한 이유로 우리는 GPU 가속을 하도록 프로그래밍을 하고 근본적으로 Shader 를 사용하기 위하여 Shader Programming 을 수행하는 것이기도 하다.

만약 화면 특정 위치에 중심 c(x,y) 와 반지름 r 인 원을 하나 그린다고 생각해 보자.

원의 정의부터 생각해 봐야 된다. 원이란 중심점으로 부터 거리가 반지름 r 인 위치의 모든 점의 집합  이다. 여기서 2차원 좌표계를 상정한다. 그러나 3차원으로 가도 그 정의는 바뀌지 않는다.

그러면 원 하나에 무수히 많은 점들이 존재를 할 것이며 이는 화면의 해상도, 반지름 R 의 크기에 따라서 점의 갯수는 달라질 수 있고 사실 수학적으로는 무한대의 갯수가 되지만, 어쨌든 매우 많은 점이 계산되어 질 수 있다.

만약 1000개의 점이 하나의 원을 구성한다고 하면 일반적으로 이 점들의 위치를 계산하기 위하여 CPU 가 처리해야 하면 1000번의 CPU 계산 시간을 할당 해야 한다. 물론 이를 thread 로 처리해도 된다. 그러면 좀더 빨라질 것이다. 그러나 어쨌든 CPU가 이 일을 해야 한다.

또한 계산된 점의 위치도 CPU가 자신의 관할하에 있는 메모리에 준비해서 보관해두고 이러한 계산이 다 종료 되면 이 점 데이터를 이용해서 화면에 점을 찍든 점과 점을 잇는 선을 그리든 하여 화면에 원하는 크기의 원을 그릴 수 있게 된다. 물론 직접 이를 코딩하지 않고 Graphic Card Driver 가 해주는 또는 GDI 같은 OS의 기본적인 그래픽 라이브러리가 해주는 방법도 있다.  어쨌든 이러한 일들은 어느 레벨에 코드가 있든 CPU가 처리 하게 된다.

이러한 방식이 오래전의 고전적인 그래픽 프로그래밍 이었다.

이제 생각을 바꾸어 GPU를 활용하는 것을 생각해 보자.

CPU는 더 이상 원의 공식에 의한 계산을 수행하지 않는다. 그냥 GPU 에게 원의 중심과 반지름을 알려주고 GPU에게 원을 그리라고 던져 준다.

그러면 GPU 가 원을 그냥 그릴까???

사실 그렇지 못하다. GPU는 그렇게 뛰어나게 계산적이고 고차원적인 process가 아니다. 매우 단순한 기능을 수행하며 단지 각각의 명령을 처리하는 코어 수가 매우 많다는 것이 특징이다. 또한 이러한 core들은 병렬로 처리된다.

GPU자체는 원을 그릴 능력이 없다.

GPU가 하는일은 x,y 에 점을 찍어야 하는데 어떤 색으로 찍을까요?  하고 물어보면 여기에 색상 값을 제공해주면 그 값에 해당하는 색으로 점을 찍는다.

이게 끝이다.. GPU가 하는 일은.

그러면 우리는 앞서 말했 듯이 GPU가 (x,y) 위치의 색상을 물어 올때 색상값을 제공하도록 하는 코드를 작성해주면 된다.

물어오는 (x,y) 가 원을 구성하는 점이면 원하는 색상을 내주고, 그렇지 않으면 점 찍는 것을 discard 시키면 된다.

그러면 원이 그려진다.

이러한 작업을 구성하는 것이 Shader Programming 이 하는것이고, 이는 shader compiler에 의하여 compile되고 GPU에 전달된다.

OpenGL 에서는 GLSL 이라는 Shader Language를 이용하여 Shader 프로그래밍을 하며 OpenGL에서 제공하는 compiler로 컴파일해서 GPU에 code를 loading 하여 이를 사용하는 것이다.

이러한 Shader Programming 기술의 능력에 따라 화면 처리 속도 및 그리고자 하는 그림의 요소가 다양해 질 수 있다.

Antialiasing 같은 고급 기술도 바로 shader program에 의하여 구현되는 것이기도 하다.

Formatter , Lexer and Parser

Formatter

특정 구조화된 메모리(class 또는 struct 메모리) 데이터를 text 형식으로 가독성 있게 만들어 준다.

Lexer

Formatter 로 만든 text 형식의 데이터에서 정해진 규칙의 token 을 인식하여 뽑아주는 기능을 수행한다.

Parser

Lexer 가 추출해주는 token 들을 조합하여 의미를 해석해서 원래의 구조화된 메모리 또는 class를 만들어 준다.

이들은 모두 데이터의 파일로의 저장(특히 text 파일, 앞서 언급한 내용에 의하여 encoding 처리기가 들어간다) 및 읽기 기능에 사용되는 기초 기술이 된다.

여기서 우리는 Formatter를 Altium 용, PADS 용을 만들어 적용하면 각각의 툴에 맞는 데이터가 저장되고, 또한 Lexer and Parser를 각 툴에 대해 만들어 주면 해당 파일들을 읽을 수 있게 되는 것이다.

또한 압축 가능한 formatter를 작성하면 데이터를 압축해서 저장하고 읽고 할 수 있도록  할 수도 있게 되는 것이다.

이 모든 모듈은 가장 상위에 정의된 abstract class에 기인하여 상속 받아 만들어 낼 수 있다.(단 C/C++ code 작성을 해야 한다. 사실은 프로그래머 능력만 된다면 Python, Lua 같은 Script 언어를 사용하는 것도 가능하다)

아래에 내용은 이러한 formatter에 의하여 저장된 파일의 내용을 보여 주는 예이다.

Unicode 적용 snapshot

다음 그림은 Unicode 문자열 처리에 의한 메뉴 및 파일 이름 처리에 Unicode 및 UTF-8 과 같은 Encoding 처리를 수행 하고 있다는 것을 보여주고 있다.

이런 처리가 이루어 지지 않을경우 나타나는 현상

• 한글이 깨져서 보여요

• 한글 폴더, 파일을 인식 못해요

• 한글 데이터를 읽고 쓰지 못해요 

• 기타 등등...오류 발생..

Unicode And UTF8 Encoding

(여기서의 설명에 있는 한글 체계는 완성형 한글 코드에 기반합니다)

컴퓨터 프로그래밍을 할 때 우리는 각종 문자열을 사용하고 표현한다. 문자열을 GUI 에 출력하거나 파일로 저장하거나 또는 도면에 표시하거나 할때가 있다.

문자열의 출력은 컴퓨터 시스템이 선택한 OS 가 지원하는 지원 언어에 의존한다. 

일반적으로 문자열은 컴퓨터 메모리의 byte 단위로 저장된다. 이는 문자 한자에 대하여 메모리의 얼마 만큼의 크기를 할당 하느냐 하는 문제에도 연결된다.

우리가 잘 알고 있은 ASCII code 에 의한다면 문자 한자는 메모리 1 byte를 차지한다.

그러므로 할당된 메모리의 크기를 알면 문자의 길이(글자 수) 를 알 수 있다. 그러나 이러한 문제는 다국어 지원에 들어가는 순간 문제를 발생 시킨다.

ASCII code 에 의하여 1 byte 의 크기로 문자를 나타낸다면 결국 1byte 의 최대 크기인 255 , 즉 0 부터 255 가지의 (총 256 개의 문자) 만 나타낼 수 있다.

그러나 한글 또는 일본어, 특히 중국어 등은 256개의 문자만 있는 것이 아니다. 그러므로 우리는 2bytes 를 문자 한자에 제공하기로 했다. 이를 multi-byte character code 라고 하기도 한다.

여기서 우리는 왜 multi-byte 라고 명명하는지 알아야 이 문제를 알아 볼 수가 있다.

"abcde"

위의 문자열은 과연 몇 자 인가? 따옴표는 제외하고,  메모리는 5 byte를 차지한다(원래는 6 byte로 뒤에 문자열 끝을 나타내는 1byte가 추가되 지만 여기에서는 직관적으로 설명할 것이다)

누가 봐도 5자 문자열이다. 또한 이를 보관하기 위하여 5bytes 의 메모리를 할당한다.

다음 문자열을 보자.

"abcde가나다"

과연 몇자 인가? 우리의 관념에 의하면 영문자 5자에 한글 문자 3자 이다. 총 8자 이다. 

그러면 이를 컴퓨터 메모리에 연결해서 생각해보자. 메모리는 얼마나 차지할까?  

영문자 5 bytes 에 한글 문자는 한글자당 2byte를 사용하기 때문에 6 bytes  즉 11 bytes 를 할당해야 한다. 그러나 이러한 할당을 한다면 CPU는 문자 처리에 있어서 매우 과한 부하를 느낄 것이다.  문자들을 처리할 때 마다 해당 문자가 영문자인지 한글 문자 또는 일본, 중국 문자 인지를 구분해서 따로 처리해야 하기 때문이다. 이는 매우 비 합리적이고 비 효율적 이 되는 처리 방식이다.

그래서 우리는 무조건 한 글자에 (영문, 한글, 일어,한자 가릴 것 없이) 2 bytes 를 할당 하도록 하고 있다.

이게 우리가 지금 사용중인 OS에서 선택한 문자열 처리 방식이다. 그렇다고 1 byte 문자 방식을 사용하지 못하는 것은 아니다.

C/C++ 언어로 예를 든다면 

1 byte 문자열에 대해서는 char 이라는 예약어를 사용한다. 여기에 반해 2 bytes 문자에 대해서는 wchar_t 라는 예약어를 사용한다.

이렇게 char 은 ASCII 코드를 표현하고 wchar_t 는 2 bytes 할당에 다국어 처리를 수행하도록 하고 있다.

그렇다고 char 로 지정해서 한글 또는 일본어를 저장하지 못하는 것은 아니다.

즉 1 byte 단위로 메모리를 할당 하지만 코드 테이블을 제공하여 2byes 문자도 억지로 넣어서 사용할 수 있다. 그러나 매우 비효율 적이고 또한 각 언어마다 code table이 있어야 한다. 이런 경우, 한글을 표현하는 문자열이 일본어 윈도우로 바꾸면 한글이 안나오고 이상한 일본어가 나올 수 있다.

이를 극복하기 위하여 wchar_t 를 기본으로 사용하게 된다.

이를 이제 Unicode 라고 명명하게 된다. 즉 Unicode는 multi-byte 로 한 문자를 표시함에 있어서 각 문자에 대한 code를 규정한 것이다. 지구상의 모든 문자에 대하여 서로 다른 코드를 부여하는 방식이다. 그러므로 한글 윈도우에서은 "가" 라는 코드가 일본어 윈도우에서도 역시 "가" 라는 코드가 된다.

이제 UTF-8 을 이야기해 보자.

우리가 잘못 이해하는 부분이 UTF-8 과 Unicode 를 혼동하는 경우가 많다는 것이다. 

이것 하나만 기억하면 된다.

• Unicode 는 각각의 문자에 코드를 할당한 code table 이다.

• UTF-8 은 encoding 방식들 중 하나 이다. (사실 인코딩 방식은 여러가지가 있다. UTF-7도 있고  , UTF-16도 있고...)

그러면 Encoding 은 무엇인가?

Encoding은 데이터 전송(송신 과 수신) 에 관여 한다. 즉 Encoding 이 있으면 그에 맞는 Decoding 이 있다.

컴퓨터 프로그램에서 데이터를 encoding 하는 경우는 크게 두 가지 이다. (사실 모두 다 데이터 전송이라는 하나의 방식이긴 하지만 여기서는 프로그램적 관점에서 두 가지로 나누어 생각해 본다.)

• 파일(특히 text file) 로 저장

• 네트워크 통신을 통한 데이터 전송/수신 (특히 SQL Database 같은 장치)

예를 들어 한글 문자를 ascii 파일로 특정 encoding 하지 않고 저장 할 수 있다. 그러나 이를 읽을 때 해당 문자가 어떤 문자에서 저장된 것인지 알기가 힘들다. 간혹 notepad 로 텍스트 파일을 읽으면 문자가 깨질 경우를 볼 수 있다. 바로 이런 경우이다.

그렇다고 2byte 체계로 저장하여 문제를 해결할 수가 없다. 그 이유는 메모리는 그렇다 쳐도, 파일 이나 통신에 사용할 데이터는 데이터 크기를 줄여야 한다.

영문자도 무조건 2byte 로 보내면 손해 아닌가?

그래서 우리는 Encoding을 수행하여 처리한다.

즉 UTF-8 과 같은 Encoding / Decoding 은 데이터의 저장, 전송에 관여하는 기술임을 알기 바란다.

즉 하나의 프로그램이 다국어를 지원한다 는 말은 

결론 : Unicode 문자열 처리(GUI 와 관련) 와 함께 UTF-8 과 같은 Encoding 처리(데이터를 파일로 저장하고 읽는 것 같은) 문제도 해결해 줘야 한다는 것이다.

Graphic Access Library (GAL)

• 기본적인 Vector Geometry Graphics 또는 Image 출력과 같은 Raster Graphic(Texture) 를 Canvas에 출력하는 기능을 제공한다.

• Vector 또는 Bitmap Font String을 출력하는 기능을 제공한다.

• 복잡한 (기본 요소를 복합적으로 하여 구성된) 구조를 출력하도록 구성한다.

• Stroke Entity 와 Filled Entity 를 제공한다.

• 2D 또는 3D entity를 제공한다.

• Alpha Channel 지원 Coloring 시스템을 제공한다.

• Cached Layer, Non Cached Layer, 그리고 Overlay Layer를 지원하여 다수의 데이터 출력 성능을 향상 시킨다.

• GLSL Shader를 사용한다.

• Vector Font (Open Type Font, OTF) 와 Bitmap Font를 제공한다.

• OpenGL DIRECT Drawing을 제공한다.

기본 Drawing Entity

• Segment (Single Line)

• Chained Line (Poly Line)

• Polygon

• Circle

• Arc (Circular Arc)

• Rectangle

• Text (Multi Line 가능)

• Text Box (Multi Lined Text Box)

• Curve (Bezier)

• Mark Overlay

• Control Point

• Cursor

• 기타등등...

GUI and Graphic Access Library (GAL)

CAD Tool의 구성에 있어서, UI 관점에서 크게 두 부분으로 나눌 수 있다.

• GUI

• Graphic Access Library (GAL)

우리는 이제 이 두 부분을 만드는데 있어서 코드의 유지 보수 및 높은 코드 이식성을 위하여 두 부분으로 구분하여 독립적으로 작성한다.

GUI

GUI 는 원하는 운영체제에 있어서 (가령 MS 윈도우 같은),  윈도우를 구성하는 각종 윈도우 리소스 들을 이용하여 작성 된다.

이는 다분히 OS 종속성이 강하다.

우선적으로 , 우리는 MS Windows를 목표로 한다.

여기에 우리는 VCL 을 GUI 엔진으로 사용한다. wxWidget , Qt 와 같은 cross platform GUI library들이 있기는 하지만 모든 플렛폼을 대상으로 한다면 좋은 선택이 될 수 있다. 그러나 우리는 MS WIndows를 하나의 대상으로 정하여 진행할 것이다.

그 후 다른 플렛폼 으로의 포팅이 가능할 것이다.

우리가 VCL을 우선 선택한 것은 높은 가성비와 풍부한 Visual Component 들이 있기 때문이다. Cross platform 에서 구현이 힘든 부분도 쉽게 지원 가능하기 때문에 여기에 많은 시간을 투자 하지 않고 프로그램을 작성하기 위하여 높은 가성비의 VCL을 선택한다.

즉 GUI 부분에는 집중을 위한 선택을 할 것이다.

Graphic Access Library (GAL)

이는 Window Canvas System 에 어떠한 그래픽 라이브러리를 사용할 것인가에 대한 결정이다.

(결론 : OpenGL 을 사용한다)

CAD 는 일반적으로 2D 또는 3D 를 지원한다.

우리는 여기에 Graphic Engine 의 선택에 있어서 다음 중 하나 또는 다수를 선택할 수 있다. 

• GDI :  MS Windows, 지원 중단됨, 거론할 여지가 없으나, printer 에 출력을 직접 하기 위해서 선택해야 하지만, 우리는 다른 방법을 찾을 것이다. 성능은 최하, 그래픽 가속과는 무관하다.

• OpenGL : 거의 모든 OS 에서 구현됨. 가장 이식성이 좋다. 3D 기본이다. GLSL Shader 지원으로 높은 성능 제공, 그래픽 가속 지원, 코딩이 쉽다.

• Direct2D  : MS Windows , 2D 지원, 다양하고 정밀한 Font Library, 및 2D Vector Graphic 제공, 사용이 간편하나 Shader를 지원하지 않는다.대량의 데이터를 처리하기 위해서는 특별한 기법을 사용해야 한다. 코딩이 쉽다.

• Direct3D : MS WIndows, 3D 지원 (사실 Direct2D는 Direct3D 의 2D 부분만 을 분리해서 따로 제공하는 것이긴 하다). HLSL Shader 지원 (GLSL 과 비슷하다) , 높은 성능, 그래픽 가속 지원 , 윈도우즈에서만 제공하기 때문에 이식성은 낮다.  성능은 좋으나 코딩이 어렵다.

• Vulkan : 거의 모든 OS에서 지원 하려고 함. OpenGL의 Direct3D 버전, 성능은 좋으나 코딩이 어렵다. GLSL Shader 지원.

• Cairo, Skia, bgfx 등과 같은 각종 기타 Graphic 라이브러리들. 특별한 경우 사용할 것이다. 이미지 파일을 생성 할 때 등등.

HV Snap Line Systems

HV Snap Line System 은 2차원 직각 좌표계를 사용하는 각 문서에 Horzontal 또는 Vertical Snap Line을 관리하는 기능이다.

좌표계 에서 Snapping 을 수행하는 것은 기본적으로 도면에 적용된 Grid System에 의하여 작동한다.

이러한 기본적인 Grid System에서 제공하는 것은 X,Y 축을 대상으로 특정 간격의 메트릭스 형식으로 구성되며 커서 를 실시간으로 추적하여 위치 시키는 기능에 한정한다.

그러나 특별한 경우(가령 PCB의 특정 위치에 drill hole을 배치하고 싶을 때 같은) 특정한 위치 (horz 또는 vert 방향) 에 커서 를 지정하고 싶을 때가 있다.

우리는 이룰 위하여 HV Snap Line System 을 사용할 수 있도록 제공할 것이다.

• 특정 위치에 HV Snap Line 입력

• 특정 위치의 HV Snap Line 제거

• 해당 위치의 좌표 문자로 표시

• 모든 HV Snap Lines 를 제거

• 각 도면에 저장

• HV Snap Line 숨기기 / 보이기

• HV Snap Line의 작동 On/Off   -> 숨기면 작동하지 않는다.

Edit Frame

CSIEDA NEW Engine 에서는 CAD Drawing 을 수행하는 Edit Frame 들이 있다.

• EPD Edit Frame

• SCHLib Edit Frame

• 기타... (작성중)

Snapping System

CSIEDA NEW Engine 에서는 다양한 snapping system 기능을 제공한다.

• Grid Snapping

• Selected Object Control Point Snapping

• Horizontal / Vertical Custom Snapping

• Named Temporary Snapping

• Drawing Geometry Temporary Snapping

CSIEDA 는 크게 3가지 모듈로 개발된다.

• 1. Docking UI

• 2. CADFRAME - ECad Engine

• 3. Script Engine - Lua and etc...

기록 전에 수행한 일

이 문서를 만들기 전에 수행한 일을 대략적으로 적는다.

Docking UI (VCL,MS-Build)

• Menu/Toolbar System

• Document Docking System

• Widget Docking System

• Skin System

• Lua Engine 

CADFRAME (gcc,cmake)

• Basic abstract class 

• Basic geometry class 

• Basic Frame class

• OpenGL Frame class

• Shader for EDA

• Selection and Drawing procedure

• Named drawing procedure

• RGBA Color 

• Named Color 

• Action Event

• Coroutine for Event Processing

• Event and Event Processing

• Lua Scripting Engine

SCRIPT ENGINE (Lua)

• std library

• frame

• geometry library

• UI

기타등등 ...