편집기에서 [enter]를 누르면 <p> 태그가 들어가고, 문단으로 생각하고 한 줄을 비웁니다.
글줄만 바꾸려면 [shift-enter]를 누르면 <BR> 태그가 들어가므로 용도에 맞게 나누어 쓸 수 있습니다.
수식를 문서내에 삽입하시려면 에디터를 툴바에서 [소스]를 눌러 HTML로 입력할 수 있게 바꾸신 후 <pre> </pre> tag를 사용하셔서 <pre> 여러 줄의 수식 </pre>처럼 입력하시면 좋습니다.
Dennis
Github에 이슈를 올려서 Dr. Ken Lunde 씨하고 몇 차례 메일을 주고 받았는데요,
https://github쩜com/googlei18n/noto-cjk/issues/111
문제의 증상은 예를 들어 숫자 1, 2라고 하면 각각 코드가 U+0031, U+0032인데 PDF 변환 과정에서 U+10F357, U+10F358로 코드가 바뀌었다고 합니다(Plane 16 PUA code points에 있는 코드라고 하는데 이건 뭔지 잘 모르겠습니다 ^^- 검색해 보니 사용자 정의 영역이네요). 이분 테스트로는 증상은 일러스트레이터에서만 발생했고 (이분이 TeX을 잘 아시지는 않는 듯... 쿨럭) 인디자인에서는 발생하지 않았다고 하네요. 그리고 Noto Sans CJK는 물론이고 어도비 버전의 Source Han Serif/Sans K에서도 발생하지 않았다고 합니다. 일단 이 분은 글꼴이 아닌 일러스트레이터의 버그로 보고 이쪽에다 이슈를 제출하겠다고 합니다.
(그렇다면 일러스트레이터와 XeTeX이 같은 PDF 변환 엔진을...?????)
아무튼 이게 Lunde 박사의 말처럼 일러스트레이터의 버그가 맞다면 결국 XeTeX에도 같은 버그가 있다는 뜻으로도 해석할 수 있겠네요. 전혀 다른 곳에서 만드는 전혀 다른 프로그램 둘이 똑같은 버그가 있다는 게 좀 믿어지지는 않습니다만...
Github에 이슈를 올려서 Dr. Ken Lunde 씨하고 몇 차례 메일을 주고 받았는데요,
https://github쩜com/googlei18n/noto-cjk/issues/111
문제의 증상은 예를 들어 숫자 1, 2라고 하면 각각 코드가 U+0031, U+0032인데 PDF 변환 과정에서 U+10F357, U+10F358로 코드가 바뀌었다고 합니다(Plane 16 PUA code points에 있는 코드라고 하는데 이건 뭔지 잘 모르겠습니다 ^^- 검색해 보니 사용자 정의 영역이네요). 이분 테스트로는 증상은 일러스트레이터에서만 발생했고 (이분이 TeX을 잘 아시지는 않는 듯... 쿨럭) 인디자인에서는 발생하지 않았다고 하네요. 그리고 Noto Sans CJK는 물론이고 어도비 버전의 Source Han Serif/Sans K에서도 발생하지 않았다고 합니다. 일단 이 분은 글꼴이 아닌 일러스트레이터의 버그로 보고 이쪽에다 이슈를 제출하겠다고 합니다.
(그렇다면 일러스트레이터와 XeTeX이 같은 PDF 변환 엔진을...?????)
아무튼 이게 Lunde 박사의 말처럼 일러스트레이터의 버그가 맞다면 결국 XeTeX에도 같은 버그가 있다는 뜻으로도 해석할 수 있겠네요. 전혀 다른 곳에서 만드는 전혀 다른 프로그램 둘이 똑같은 버그가 있다는 게 좀 믿어지지는 않습니다만...