노무현 대통령 배너
BLOG main image
왕미친놈의 왕미친세상입니다. 미친 소리는 써도 되지만, 근거 없는 소리는 쓰면 안 됩니다.


AcroEdit는 가끔 옛한글이 포함된 문서를 사용자의 동의 없이 수정하는 버그를 갖고 있습니다. 오래전에 발견했지만 줄곧 다른 버그 리포팅에 밀려 있던 벌레를 다시 발견했습니다. 나중에 올려야지 하다 보니 깜빡 잊고 있었죠.

  • 참고 : 이 문서는 많은 그림을 포함하고 있어서 읽어오는 데 오래 걸릴 수도 있습니다. 느긋하게 기다려 주십시오.

벌레의 유형

불러온 파일의 원형을 유지하지 못하게 만드는 벌레입니다. 이 벌레는 추가적인 다른 벌레를 발생시키고 있습니다.

아크로에디트에서 편집한 뒤에 뭉개진 글자 - ᄒᆞᆫ

아크로에디트에서 편집한 뒤에 뭉개진 글자 - ᄒᆞᆫ

개발자의 답변

2010년 2월 22일 버그 리포팅을 한 상태입니다.

벌레의 발견

옛한글을 텍스트 편집기에서 시험하다가 발견했습니다.(옛한글과 텍스트 편집기 참고) 그런데 그때 올리지 않았더니 오랫동안 기억 속에 묻혀 버렸습니다.

이 벌레는 파일 내용을 제멋대로 바꾸어서 사람을 화딱지 나게 만드는 벌레입니다. 크게 두 경우가 있습니다. 한 경우는 클립보드로 붙이기, 다른 한 경우는 파일을 불러왔다가 저장하기입니다.

클립보드에서 붙이기

예제 코드는 다음 문장입니다.

[code html] <span class="jamocomposed_block" style="font-family: '돋움 옛한글','Dotum Old Hangul','바탕 옛한글','Batang Old Hangul','궁서 옛한글','Gungsuh Old Hangul','굴림 옛한글','NewGulim Old Hangul','은 자모 바탕 확장','Un Jamo Batang Ex','UnJamoBatangEx','은 자모 바탕','Un Jamo Batang','UnJamoBatang','은 바탕','Un Batang','UnBatang',Code2002,Code2001,Code2000,serif; font-size: 105%;">ᄒᆞᆫ말ᄊᆞ미 듀ᇰ귁에 달아 문ᄍᆞᆼ와로 서르 ᄉᆞᄆᆞᆺ디 아니ᄒᆞᆯᄊᆡ</span> [/code]

위 내용을 텍스트 파일로 저장하면 536바이트가 됩니다. 이 htm 파일은 utf-8로 인코딩되어 있습니다.

시험용 파일 Test-1.htm : 536바이트

시험용 파일 Test-1.htm : 536바이트

위 파일을 메모장에서 열면 아래와 같습니다.

메모장에서 본 내용

메모장에서 본 내용

이상태에서 그대로 복사하여 티스토리에 편집창의 HTML 모드에서 붙여넣기를 하였습니다. 테스트 블로그에 있는 문서입니다.

옛한글이 잘 나타난 화면

옛한글이 잘 나타난 화면

그냥 Test-1.htm 파일을 파이어폭스에서 보면 다음과 같습니다.

잘 보이는 옛한글

잘 보이는 옛한글

위 그림에서 보이는 내용을 소스 보기 하면 다음과 같습니다.

소스 보기 : Test-1.htm

소스 보기 : Test-1.htm

위 소스 보기 화면에서 내용을 복사하여 아크로에디트에 붙여넣기를 하였습니다.

처참하게 깨져 버린 옛한글

처참하게 깨져 버린 옛한글

참고로 저 상태에서 utf-8로 저장하면 491바이트가 됩니다.

시험용 파일 Test-2.htm : 491바이트

시험용 파일 Test-2.htm : 491바이트

원인은 알 수 없지만 용량이 줄어 버렸습니다. 물론 파일 내용도 바뀌었습니다.

메모장에서 본 내용 그림에 나타난 소스를 복사하여 아크로에디트에 복사하였습니다.

메모장의 내용을 아크로에디트로 복사하여 붙여넣기를 한 다음 저장한 화면

메모장의 내용을 아크로에디트로 복사하여 붙여넣기를 한 다음 저장한 화면

그런데 겉보기에는 아무런 이상이 없지만, 아무튼 이번에도 이상한 점이 발견되었습니다.

시험용 파일 Test-3.htm : 533바이트

시험용 파일 Test-3.htm : 533바이트

원본은 분명히 536바이트였는데, 지금은 533바이트입니다. 겨우 3바이트이지만, 내용이 바뀌었습니다.

옛한글을 제대로 나타내지 못하는 화면

옛한글을 제대로 나타내지 못하는 화면

어찌된 일인지 아크로에디트로 저장한 Test-3.htm 파일은 옛한글을 제대로 나타내지 못하고 있습니다. 앞서 나타난 옛한글이 깨지는 결과는 파이어폭스의 문제라고 생각할 수도 있으나, 지금 이 결과는 아크로에디트의 문제로 봐야 할 듯싶습니다.

파일을 불러왔다가 저장하기

클립보드는 복사되는 과정에서 변형이 일어날 수 있다는 의혹도 제기할 수 있습니다. 그래서 아예 파일을 직접 읽어오기로 했습니다.

메모장에서 본 내용 : 536바이트

메모장에서 본 내용 : 536바이트

위 내용을 아크로에디트에서 직접 불러오겠습니다. 불러오기에 앞서 메모장을 닫습니다. 이것은 혹시나 메모장에서 간섭이 생길 수도 있기 때문입니다.

아크로에디트에서 Test-1.htm 파일 불러오기

아크로에디트에서 Test-1.htm 파일 불러오기


아크로에디트에서 Test-1.htm 파일을 불러온 화면

아크로에디트에서 Test-1.htm 파일을 불러온 화면

위 그림은 앞서 나온 메모장의 내용을 아크로에디트로 복사하여 붙여넣기를 한 다음 저장한 화면 그림과 매우 비슷합니다. 이것을 Test-4.htm 파일로 저장했습니다.

아크로에디트에서 Test-1.htm 파일을 Test-4.htm 파일로 저장

아크로에디트에서 Test-1.htm 파일을 Test-4.htm 파일로 저장

Test-1.htm 파일과 Test-4.htm 파일은 모두 536바이트입니다. 그러면 이것을 파이어폭스에서 보면 어떻게 될까요?

Test-4.htm 파일은 미스테리를 담은 파일??

Test-4.htm 파일은 미스테리를 담은 파일??

편집도 않고 그냥 불러들였다가 다른 이름으로 저장만 했을 뿐인데 왜 이런 일이 생기는지 알 수 없었습니다.

아크로디프 프로그램에서 파일 비교

Test-1.htm 파일과 Test-4.htm 파일을 비교해 보겠습니다.

HxD 프로그램에서 비교한 Test-1.htm 파일과 Test-4.htm 파일

HxD 프로그램에서 비교한 Test-1.htm 파일과 Test-4.htm 파일

Test-1.htm 파일과 Test-4.htm 파일은 확실하게 다른 점이 있습니다. 원본인 Test-1.htm 파일을 아크로에디트에서 불러와서 아무런 수정도 없이 Test-4.htm 파일로 저장하기만 했을 뿐인데, 1바이트가 변형되어 있습니다.

이 두 파일을 아크로에디트에서 비교하면 어떻게 될까요? 정확하게는 AcroDiff(아크로디프)에서 비교하면 어떻게 될까요? AcroDiff 프로그램은는 파일 비교를 해 주는 유틸리티로서 아크로에디트에 포함되어 있습니다. 일종의 헬퍼 프로그램이죠.

AcroDiff(아크로디프) 프로그램 실행 화면

AcroDiff(아크로디프) 프로그램 실행 화면

여기에서 빨간 네모 표시를 클릭하여 파일을 왼쪽 창에 불러올 수 있습니다.

AcroDiff 프로그램에서 파일 불러오기

AcroDiff 프로그램에서 왼쪽 창에 파일 불러오기


AcroDiff 프로그램에서 왼쪽 창에 파일을 불러온 화면.

AcroDiff 프로그램에서 왼쪽 창에 파일을 불러온 화면. 이 상태에서는 내용은 나타내 주지 않습니다.

위 그림에서 파일 내용은 나타내 주지 않습니다. 파일 내용이 안 나타난다고 당황하지 마시기 바랍니다. 위 화면에서 빨간 네모 부분을 클릭하여 오른쪽 창에도 파일을 불러옵니다.

AcroDiff 프로그램에서 오른쪽 창에도 파일을 불러온 화면.

AcroDiff 프로그램에서 오른쪽 창에도 파일을 불러온 화면. 이 상태에서는 내용은 나타내 주지 않습니다.

오른쪽 창도 내용이 나타나지 않습니다. 이 화면에서 비교 실행(빨간 네모)을 클릭하여 파일 비교를 합니다.

두 창의 내용을 비교한 화면

두 창의 내용을 비교한 화면

놀랍게도 AcroDiff는 두 파일의 다른 점을 찾아내지 못하고 있습니다. 이로써 아크로에디트의 저장 과정이 아니라 불러오기에서 문제가 생김을 추측해 볼 수 있습니다.

벌레의 원인

벌레의 원인은 알 수 없었습니다. 다만 한글 깨짐 현상이 있습니다 문서와 관련이 있으리라 추측해 봅니다. 또한 아크로디프 프로그램에서 파일 비교 항목에서 보이듯이, 저장 과정에서 문제가 생긴 것이 아니라 파일을 불러왔을 때 파일 내용이 이미 변형되었으리라 추측할 수 있습니다.

관련 벌레

이 벌레와 관련이 있는 벌레는 다음과 같습니다. 다음 두 벌레는 ᄒᆞᆫ자의 화면 표시와 관련한 버그를 소개하고 있습니다.

관련 문서

내부 문서

외부 문서

이 글은 스프링노트에서 작성되었습니다.


글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

블로그 CSS를 고치다가 아크로에디트가 URL 강조를 틀리게 하는 것을 하나 더 발견하였습니다.

벌레의 유형

  • 자신이 끼어야 할 때와 끼지 말아야 할 곳을 제대로 알지 못하는 벌레입니다.
  • 또한 꼬리가 달렸다고 엉뚱한 짓을 하는 벌레이기도 하고요.

개발자의 답변

2010년 1월 17일 버그 리포팅을 한 상태입니다.

벌레의 발견

아크로에디트 홈페이지에서 URL 인식기능 개선 건의라는 글을 읽고 URL 강조 기능을 시험해 보았을 때도 미처 발견하지 못한 벌레입니다.

공백까지 URL로 인식해 버렸습니다.

공백까지 URL로 인식해 버렸습니다.

벌레의 원인

지난 번과 마찬가지로 URL을 인식하는 알고리듬에서 URL의 끝을 인식하는 부분에서 오류가 있지 않나 예상해 봅니다.

비슷한 벌레

관련 문서

내부 문서

외부 문서

이 글은 스프링노트에서 작성되었습니다.

글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

지난 달에 아크로에디트 홈페이지에 들렀다가 URL 강조에 대한 오류를 지적한 글을 보았습니다. 그때 저도 한 가지 벌레를 발견했으나, 한컴오피스2010 베타버전에 대한 버그 리포팅 때문에 올리지를 못하다가 이제야 올립니다.

벌레의 유형

자신이 끼어야 할 곳과 끼지 말아야 할 곳을 제대로 알지 못하는 벌레입니다.

개발자의 답변

2010년 1월 4일 버그 리포팅을 한 상태입니다.

벌레의 발견

아크로에디트 홈페이지에서 URL 인식기능 개선 건의라는 글을 읽고 URL 강조 기능을 시험해 보고 알게 되었다.

아크로에디트 URL 강조 테스트

아크로에디트 URL 강조 테스트

아크로에디트 URL 강조 테스트 그림에는 URL 강조에 대한 여러 가지 상황이 나타나 있습니다.

  • 제1열 : 올바른 URL이며, URL 강조도 정상 작동합니다.
  • 제2열 및 제3열 : URL 인식기능 개선 건의에서 지적했습니다. 올바른 URL이며, URL 강조에서 오류가 있습니다. 이때 물음표(?)는 쿼리(query; 데이터베이스에서의 요청)를 나타냅니다. 그리고 그 뒤에 오는 등호(=)는 쿼리의 물음표와 함께 쓰여 URL을 구성합니다.
  • 제4열 : 올바른 URL이며, URL 강조에서 오류가 있습니다. 마지막 슬래시(/)를 포함해서 URL을 구성합니다. 그러므로 당연히 URL 강조도 마지막 슬래시(/)를 포함해야 합니다.
  • 제5열 : 올바르지 않은 URL이며, URL 강조는 정상 작동합니다. 등호(=)는 물음표(?)과 함께 쓰여 URL을 구성합니다.
  • 제6열 및 제7열 : 올바른 URL이며, URL 강조도 정상 작동합니다. 이때 역슬래시(\ 또는 )는 윈도에서는 경로에 임의로 사용할 수 없는 예약어로서 경로의 구분에만 사용합니다만[각주:1], 유닉스 환경을 바탕으로 한 인터넷에서는 사용할 수 있습니다. 다만 여러 가지 이유로 인터넷에서도 자주 사용하지 않습니다. 따라서 제6열 및 제7열의 URL이 실재할는지는 의문입니다만, 그 형식은 올바릅니다.

그런데 제4열의 오류는 뜻밖이었습니다. 왜냐하면 인터넷에서는 http://www.AcroEdit.pe.krhttp://www.AcroEdit.pe.kr/은 서로 다르기 때문입니다. 물론 그 두 주소가 대부분 같은 대상을 가리키도록 나타나지만, 엄밀히 말해 서로 다르다는 뜻입니다. 그러므로 마지막에 붙은 슬래시(/)를 URL 강조에서 인식하지 못한 것은 뜻밖이었습니다.

벌레의 원인

URL을 인식하는 알고리듬에서 URL의 끝을 인식하는 부분에서 오류가 있지 않나 예상해 봅니다.

비슷한 벌레

관련 문서

내부 문서

외부 문서

이 글은 스프링노트에서 작성되었습니다.


  1. 유닉스에서는 슬래시(/)가 경로를 구분하는 역할을 합니다 [본문으로]
글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

리사이즈 브라우저는 웹브라우저뿐만 아니라 일반 프로그램 창의 크기도 바꿀 수 있습니다.

  • 참고 : 이번에 다루는 작업은 약간 위험할 수도 있습니다. 그러므로 너무 심한 장난을 하지 말도록 하십시오.

기본 원리

앞서 리사이즈 브라우저는 창의 제목 표시줄의 캡션 문자열을 읽어서 동작한다고 말했습니다. 반대로 말하면, 캡션 문자열만 안다면 창의 크기를 제어할 수 있다는 뜻이 됩니다. 심지어 리사이즈 브라우저 자신의 크기도 바꿀 수 있습니다. 다시 말해 크기 조절이 안되는 창도 리사이즈 브라우저를 이용하면 크기 조절을 할 수 있다는 뜻입니다. 다만 이 경우에는 프로그램을 다시 시작하면 크기가 원래대로 돌아옵니다.

옵션 (Options)

765 x 514 크기의 AcroEdit 창

765 x 514 크기의 AcroEdit 창

위와 같이 아크로에디트의 창의 제목은 항상 AcroEdit - 라는 문자열로 시작합니다. 이것을 등록하여 아크로에디트 창의 크기를 변경할 수 있습니다.

옵션 화면

옵션 화면

위와 같은 옵션 화면에서 "AcroEdit -"라는 문자열을 등록합니다. 그 뒤 저장하고 프로그램 화면으로 돌아옵니다.

등록되었을까?

제대로 등록되었을까?

제대로 등록된 AcroEdit

제대로 등록된 AcroEdit

목록에서 AcroEdit의 창 제목이 보이지 않는다면 Refresh를 한 번 클릭해 주면 됩니다.

위 화면에서 Resize를 클릭!

800 x 600 크기의 AcroEdit 창

800 x 600 크기의 AcroEdit 창

그밖에 여러분이 등록하고 싶은 프로그램을 등록해서 사용하시면 됩니다. 가장 압권은 프로그램에서 띄우는 대화상자, 그것도 크기를 변경할 수 없는 대화상자의 크기를 변경해 버리는 뻘짓입니다. 그야말로 궁극의 리사이즈라고 할 수 있습니다.

01

관련 문서

내부 문서

이 글은 스프링노트에서 작성되었습니다.


글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

2009년 한 해 동안 소개한 버그 가운데 실제로는 버그(또는 오류)가 아니었거나, 이미 수정된 버그 등이 있는지를 살펴보았다. 기간은 2009년 3월부터 11월 30일까지입니다. 12월은 내년으로 넘겨야 할 듯합니다.,

  1. 2009/11/29 스프링노트 : 문자 인코딩 관련 사항 : 관점에 따라 버그일 수도 있고 아닐 수도 있다.
  2. 2009/11/27 티스토리 BBCode 오류 : 제작자가 수정하는 중이라는 답변을 받았다. 아직 고쳐지지 않았다.
  3. 2009/11/03 스프링노트 : 첨부파일 대화상자의 옵션 가리기 벌레 : 개발자에게 전달하겠다는 답변을 받았다. 아직 고쳐지지 않았다.
  4. 2009/11/02 한/글/ 2007에서 나타난 구결 표기 오류 2 : 이 사항은 버그가 아니다. 내가 잘못 알았다.
  5. 2009/10/30 한/글/ 2007에서 나타난 구결 표기 오류 1 : 이 사항은 버그가 아니다. 내가 잘못 알았다.
  6. 2009/06/18 광고인가? 사기인가? : 광고 문구를 교묘히 조작하여 클릭을 유도한다. 구글 광고와는 다른 사기성 광고
  7. 2009/05/30 티스토리 주석에서 \ 문자 표기 문제 : 출력 과정에서 정확히 나타나지 않는 버그이다. 아직 고쳐지지 않았다.
  8. 2009/05/28 티스토리에서 주석이 제대로 인식되지 않는 현상 : 출력 과정에서 정확히 나타나지 않는 버그이다. 아직 고쳐지지 않았다.
  9. 2009/05/16 아크로에디트 : 배치파일 주석 문법 강조 기능 : 잘 고쳐져 있다.
  10. 2009/05/15 스프링노트 : 공개 및 비공개 설정에서 이상한 점 : 잘 고쳐져 있다.
  11. 2009/05/14 스프링노트 : 일부 글자 속성이 제대로 지정되지 않는 벌레 : 일부는 고쳐졌으나, 일부는 고쳐지지 않았다.
  12. 2009/05/10 버추얼박스 v2.2.2 설치 오류 : 한글 경로명 문제 : 최신 버전인 VirtualBox v3.1.0 빌드55467 (윈도 버전)에서도 고쳐지지 않았다. 이는 단순히 설치 프로그램의 문제이며, 프로그램 실행에는 아무런 영향도 없습니다.
  13. 2009/04/28 V3 계열 백신의 폴더 경로명 표기 벌레 : 고쳐지지 않았다.
  14. 2009/04/27 스프링노트의 링크 편집 벌레 : 잘 고쳐져 있다.
  15. 2009/04/26 스프링노트의 태그 표기 벌레 : 잘 고쳐져 있다.
  16. 2009/04/11 버추얼박스 2.2.0 네트워크 접속 문제 : 후속 버전에서 잘 고쳐져 있다.
  17. 2009/04/07 네이버 결계 벌레 : 현재 전혀 나아지지 않았다. 여전히 내 네이버 블로그에서 그림 파일을 불러올 수 없다.
  18. 2009/04/05 네이버 뻥튀기 벌레 : 현재 전혀 나아지지 않았다. 여전히 내 네이버 블로그에서 그림 파일을 불러올 수 없다.
  19. 2009/03/31 벌레 잡는 알약, 벌레에 먹히다 2 : 확인하지 않음.
  20. 2009/03/30 티스토리 파일 첨부 창 잘라먹기 : 잘 고쳐져 있다.
  21. 2009/03/27 벌레 잡는 알약, 벌레에 먹히다 : 확인하지 않음.
  22. 2009/03/27 네이버의 나눔고딕코딩 선문자 오류 : 선문자를 정확히 표시해 준다.
  23. 2009/03/26 아크로에디트 구문 강조 오류 : 일부는 고쳐졌지만, 일부(예컨대 @의 처리)는 고쳐지지 않았다.
  24. 2009/03/26 Offree.net에서 발견한 이상한 점 : 사이트의 문제가 아니라 IE와 파이어폭스의 문제였다.
  25. 2009/03/21 한/글/ 2005에 나타난 구결 표기 오류 : 이 사항은 버그가 아니다. 내가 잘못 알았다.
  26. 2009/03/21 티스토리 그림 파일 업로드 벌레 : 티스토리에서 수정해 주었다.

이 글은 스프링노트에서 작성되었습니다.


글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

최근 아크로에디트에 관한 글을 쓰다가 조금 불편한 기능이 있어서 개선할 수 없을까 궁리하다가 멀티 라인 기능이 있음을 알게 되었습니다. 

문법 강조와 자동 줄 바꿈

강제 열 맞춤 지시선에 걸쳐 있는 내용

강제 열 맞춤 지시선에 걸쳐 있는 내용

위 그림을 보면 글 내용이 강제 열 맞춤 지시선에 걸쳐 있습니다. 이때 모두 문법 강조가 올바르게 되어 있어 색깔이 잘 나타납니다. 이것을 강제 줄 바꿈 하게 되면 아래 그림처럼 됩니다.

자동 줄 바꿈 화면

자동 줄 바꿈 화면

그런데 이때 2번 영역은 전체가 다음 줄로 밀려나면서 문법 강조가 올바르게 되었습니다. 기본적으로 3번 영역은 모두 비었습니다. 자동 줄 바꿈을 하였으니 당연한 일이지요.

문제는 1번 영역이다. 이것은 중간이 잘립니다.

비교 1 : 잘린 부분만 표시

비교 1 : 잘린 부분만 표시

위 그림 비교 1을 살펴보면, 윗부분은 제대로 문법 강조가 되었는데, 아랫부분은 문법 강조가 제대로 되지 못하였습니다. 결국 윗부분은 파란색으로, 아랫부분은 검정색으로 나타납니다.

문법 강조 설정 변경 : 올바르게 보기

기왕에 문법 강조를 하였으니 제대로 봐야 하지 않겠습니까? 지금부터 환경 설정을 해 봅시다.

문법 강조 설정 : 현재 파일에 알맞은 문법 강조 설정을 편집

문법 강조 설정 : 현재 파일에 알맞은 문법 강조 설정을 편집

위와 같이 환경 설정에서 문법 강조를 불러 옵니다. 이때 현재 편집하고자 하는 문법 강조를 찾아서 편집 단추를 클릭합니다. 현재 자주색 네모로 테두리가 된 부분을 살펴보시면 이해할수 있으리라 생각합니다.

멀티 라인 문자열 허용에 체크 표시

멀티 라인 문자열 허용에 체크 표시

위 그림처럼 문법 강조 기능 설정 대화상자에서 멀티 라인 문자열 허용 체크박스에 체크 표시를 하면 됩니다. 끝난 뒤에는 확인 단추를 클릭해 주시면 됩니다.

올바르게 나타난 문법 강조

올바르게 나타난 문법 강조

찾아 보기 힘든 사람을 위해 문제가 된 부분만 떼어내면 다음과 같습니다.

비교 2 : 올바르게 바뀐 부분만 표시

비교 2 : 올바르게 바뀐 부분만 표시

위 그림 비교 2를 살펴보면, 비교 1과는 달리 윗줄과 아랫줄 모두 파란색으로 문법 강조를 올바르게 나타내고 있습니다.

추가 정보

이때 바꾸기 기능(문자열을 찾아서 바꾸는 기능)으로 바꿀 경우 위 비교 2에서 나타난 문자열 부분은 찾지 못하였습니다. 버그인지 아닌지 확인 중입니다.

관련 문서

내부 문서

외부 문서

이 글은 스프링노트에서 작성되었습니다.

글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

최근 아크로에디트에 여러 가지 문법 강조(Syntax Highlight) 파일을 추가하였습니다. 그런데 일부 문법 강조에서 그 표시가 정확하지 않은 현상을 발견하였습니다.

벌레의 유형

  • 다른 놈에게 이름이 없다고 자기 이름을 강요하는 난폭한 벌레이다.

벌레의 발견

2009년 12월 16일경에 아크로에디트 최신 버전(0.9.20.92)을 실행하여 문법 강조 파일을 추가하다가 발견하였습니다.

문법 강조의 문법 이름에서 오류가 나타난 화면

문법 강조의 문법 이름에서 오류가 나타난 화면

위 그림을 보면 같은 문법 이름으로 나타나 있지만, 실제로는 전혀 다른 문법 강조 파일입니다. 이는 확장자만 확인해도 알 수 있습니다.

벌레의 원인

이 벌레가 나타난 부분을 살펴보다가 모두 세 부분임을 알게 되었습니다. 화면에 보이는 두 가지(C#, MS SQL2000), 그리고 나머지 하나는 VB.NET 입니다. 확장자로 볼 때 *.cs 는 C#, *.sql은 MS SQL2000, *.vbs는 VB.NET로 여겨졌습니다. 이것은 모두 아크로에디트 홈페이지 사용자 자료실에서 받은 파일에 포함되어 있었습니다. 직접 파일을 받아서 확인해 보고 싶은 사람은 C#, MSSQL2000, VB.NET문법강조파일 문서에서 첨부 파일을 받아서 Syntax 폴더에 복사해 넣고 확인해 보기 바랍니다.

아무튼 이 벌레가 나타나는 원인문법 이름을 지정해 주지 않았기 때문으로 여겨집니다. 그러므로 직접 문법 이름을 수정해 주면 됩니다. 다만 개발자가 이 벌레가 전혀 나타나지 않도록 고치는 일도 병행되어야 한다고 생각합니다.

이번 버그의 원인

이번 버그의 원인

벌레 잡기

아크로에디트 프로그램이 수정될 때까지는 사용자가 직접 이름을 지정하여 이 벌레를 없애야 합니다. 여기에서는 이미 아크로에디트를 설치하고, 문법 강조 파일을 다운로드 하였다고 가정하고 설명하겠습니다.

다운로드 한 문법 강조 파일

다운로드 한 문법 강조 파일

압축 파일을 풀면 세 파일이 나타난다. cs.stx, mssql2000.stx, vbnet.stx 파일이다. 참고로 위 화면은 다른 컴퓨터에서도 나타나는 현상인지를 알기 위해 PC방에 와서 잡은 화면입니다. 제 컴퓨터에는 알집이 없습니다. ^^a

AcroEdit 폴더에서 문법 강조 폴더(Syntax)를 찾아서 복사해 넣는다.

AcroEdit 폴더에서 문법 강조 폴더(Syntax)를 찾아서 복사해 넣는다.

문법 강조 파일을 <아크로에디트 폴더>\Syntax 폴더로 복사한다.

아크로에디트 옵션 >> 문법 강조

아크로에디트 옵션 >> 문법 강조

아크로에디트를 실행하여 환경 설정 대화상자를 불러와서 문법 강조 설정 화면을 봅니다. 위와 같은 화면에서 추가를 눌러 하나씩 추가하거나, 자동 검색을 눌러 새로운 문법 강조 파일을 자동으로 추가할 수 있습니다. 다만 작업이 끝나면 반드시 적용 또는 확인을 클릭하여야 합니다.

문법 강조 파일 목록이 잘못 나타난 예시 1

예시 1 - 문법 강조 파일 목록이 잘못 나타난 화면

예시 화면 1에서는 문법 강조가 세 부분에서 틀려 있다. 직접 찾아 보면 프로그램 오류를 찾는 눈이 밝아질 수도... (아니면 말고.)

문법 강조 파일 목록이 잘못 나타난 예시 2

예시 2 - 문법 강조 파일 목록이 잘못 나타난 화면

예시 화면 2에서는 틀린 문법 강조 표시가 마지막 부분에 몰려 있다.

위와 같이 두 가지 형태로 버그가 나타날 수 있으므로 다르다고 해서 이 기사 내용이 틀리다고 생각하지는 말아주기 바랍니다. 이때 예시 1은 문법 강조를 많이 추가했을 때 그 가운데 섞여서 나타납니다. 그때 파일명의 자모순으로 정렬해 주는데, 파일 사이에 정렬되면서 바로 앞의 문법 이름을 그대로 쓰게 됩니다. 예시 2에서는 이미 문법 강조를 적용한 상태에서 해당 문법 강조만을 추가하면, 앞서 적용한 문법 강조는 그 앞에까지 정렬되어 있고, 새로 추가한 파일만 따로 정렬해 줍니다. 그러면서 문법 이름은 바로 앞의 문법 이름을 가져오게 됩니다.
이 글에서는 예시 1을 기준으로 설명합니다.

엉뚱하게 나타난 문법 이름

엉뚱하게 나타난 문법 이름

편집할 문법 강조 부분에 커서를 두고 편집을 클릭합니다. 여기에서는 확장자가 *.cs인 부분을 클릭한 뒤, 편집 단추를 클릭합니다.

문법 이름이 비어 있다.

비어 있는 문법 이름

위와 같이 문법 이름 부분이 비어 있습니다. 이것이 바로 버그의 원인으로, 이것에 대한 처리 과정에서 엉뚱한 결과가 나타났습니다.
문법 이름 부분에 알맞은 값을 넣어 주면 됩니다. 이 경우에는 C#을 넣어 줍니다.

올바르게 나타난 문법 이름

올바르게 나타난 문법 이름

이제 C# 언어에 대한 문법 강조 이름이 올바르게 나타납니다. 이때 적용 단추를 클릭하면 방금 한 작업이 환경 설정적용됩니다.

다른 문법 이름을 편집하려면 원하는 부분을 클릭하여 선택한 뒤에 편집 단추를 클릭하고, 그냥 끝내려면 확인 단추를 클릭합니다. 이 과정에 대한 설명은 생략합니다.

참고 사항

팝업 메뉴

이때 환경 설정문법 강조 항목만 엉뚱하게 나타나느냐? 아닙니다. 팝업 메뉴도 엉뚱하게 나타납니다.

엉뚱하게 나타난 팝업 메뉴

엉뚱하게 나타난 팝업 메뉴

아마도 팝업 메뉴의 내용은 환경설정 > 문법 강조 항목의 내용을 읽어서 표시해 주기 때문으로 여겨집니다.

올바르게 나타나는 팝업 메뉴

올바르게 나타나는 팝업 메뉴

환경설정 > 문법 강조 항목에서 올바르게 고쳐주면 팝업 메뉴의 내용도 올바르게 나타납니다.

숫자와 URL/URI 표시

위의 올바르게 나타나는 팝업 메뉴 그림에서 숫자 1숫자 2로 표시한 부분에서 조금 엉뚱한 현상이 보입니다. 이는 버그인지 아닌지 확인할 수 없었습니다.

  • 숫자 1에서 보면, 문법 강조 Text File은 아무런 기능도 없이 빈 문법 강조입니다. 그런데 이처럼 숫자만 다른 색깔(밝은 자주색)로 문법강조가 되어 있습니다.
  • 숫자 2에서 보면, URL/URI를 파란 색으로 표현해 주고 있습니다. 이것은 아크로에디트의 기능으로 보입니다.

제작자/제공자의 답변

2009년 12월 22일 오류를 보고한 상태이다.

관련 문서

내부 문서

외부 문서

이 글은 스프링노트에서 작성되었습니다.


글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

아크로에디트snoopy 님윈도우 7 언어팩 통합/삭제 가이드에 나타난 사항을 배치파일로 만들다가 벌레를 하나 발견하였다.

벌레의 유형

단순히 화면 출력을 잘못하는 벌레로 여겨졌다.

하지만 문법 강조에 관한 기능을 살펴본 끝에 대부분 아크로 에디트에 사는 벌레가 아니라, 처음에 문법 강조를 만들 때 해당 문법 강조 설정에 숨어 있던 벌레로 판명났다. 이 설정 파일은 내가 만든 것이 아니라 마소리스 님이 만든 것을 수정해서 쓰고 있었고, 거기에 숨어 있던 벌레였다. 물론 마지막에 가서 아크로에디트에 사는 벌레 하나를 찾을 수 있었다.

벌레 정보

  • 아크로에디트 버전 0.9 / 빌드 0.9.19.84 (2008년 12월 17일자)에서 발견하였고, 이전 버전 확인하지 못하였다.
  • 배치파일 구문 강조에서 나타났다.

벌레의 발견

배치 파일에서 "ECHO Do you want to remove other language package ? [Y/n]"라는 명령문을 입력했다가 다음과 같이 나타나서 벌레가 있음을 알게 되었다.

배치파일 문법 강조 오류

배치파일 문법 강조에서 rem이 나온 행에서 그 뒤로는 모두 주석으로 인식되는 벌레가 있다.

이때 배치파일 문법 강조 설정은 다음과 같다.

배치파일 문법 강조 설정

배치파일 문법 강조 설정.

위에서 보다시피 배치파일 문법 강조에서 행 주석으로 "rem"과 "REM"은 인식하도록 했다(파란색 네모 부분). 그런데 이 부분에서 무언가 잘못된 처리를 하고 있기 때문에 벌레가 나타난다고 여겨진다.

정말로 벌레인가? 1

아무튼 첫 번째 그림에서 129행 부분만을 떼어 내어 여러 가지 측면에서 살펴보았다.

예제 1-1. 맨 처음 발견한 벌레

예제 1-1. 맨 처음 발견한 벌레

예제 1-2. 대문자로 바꾸어도 마찬가지

예제 1-2. 대문자로 바꾸어도 마찬가지

예제 1-3. 큰따옴표(

예제 1-3. 큰따옴표(

예제 1-4. 작은따옴표(' ')로 묶어도 마찬가지

예제 1-4. 작은따옴표(' ')로 묶어도 마찬가지

예제 1-3과 1-4에서는 조금 뜻밖이었다. 보통 큰따옴표나 작은따옴표로 묶이면 문자열로 인식하고, 그럼으로써 행 주석 기호가 인식되지 않아야 하기 때문이다. 그래서 현재의 배치파일 문법 강조 설정에서 문자열 시작 문자(빨간색 네모 부분)에 "' (큰따옴표와 작은따옴표를 연속으로 입력)라고 지정함으로써 예제 1-3과 1-4를 해결하였다. 그 그림은 다음과 같다.

예제 2-1. 작은따옴표로 문자열 처리

예제 2-1. 작은따옴표로 문자열 처리

예제 2-1. 큰따옴표로 문자열 처리

예제 2-1. 큰따옴표로 문자열 처리

결국 예제 1-1과 1-2는 벌레로 여겨지지만, 예제 1-3과 1-4는 벌레가 아니었다.

정말로 벌레인가? 2

앞서 벌레로 여겨진 예제 1-1과 1-2를 다시 살펴보자.

예제 1-1. 맨 처음 발견한 벌레

예제 1-1. 맨 처음 발견한 벌레

여기에서 하나 짚고 넘어가야 할 문제가 있었다. 바로 배치파일에서 행 주석을 나타내는 지시어인 REM명령어라는 사실이다. 이게 왜 중요하냐고? 명령어 다음에 한 칸 이상의 공백이 있어야 하기 때문에 중요하다.

수정한 배치파일 문법 강조 설정

수정한 배치파일 문법 강조 설정.

위의 그림처럼 행 주석을 "rem"과 "REM"에서 "rem "과 "REM "(뒤에 공백 한 칸 있음)로 바꾸었다.

예제 3-1.

예제 3-1.

예제 3-2.

예제 3-2.

에제 3-2에서는 왜 주석으로 인식될까? 이는 당연하다. 명령어처럼 인식하도록 뒤에 공백을 넣었지만, 실제로 명령어 인식되지는 않았기 때문이다. 아크로에디트를 수정하지 않고 문법 강조 설정을 수정해서는 여기가 한계인 셈이다.

아무튼 예제 3-2에서 아크로에디트가 가진 벌레 하나를 찾을 수 있었다.

또 다른 상황

아크로에디트 구문 강조 오류 문서에서 살펴본 벌레를 상기하자. 그 글에서는 아크로에디트에서 rEm 등이 주석으로 처리되지 않는 벌레가 있음을 보였다. 여기에서도 그 벌레가 적용되는지를 살펴보았다.

예제 4-1.

예제 4-1.

예제 4-2.

예제 4-2.

벌레와 벌레가 만나자 한쪽은 작동하지 못하게 되었다.

파일

마소리스 님이 만든 배치파일 문법 강조 파일은 더 이상 유효하지 않다고 생각하여 이번에 수정한 파일을 첨부한다.

  • batch.stx (5174 바이트)
  • CRC32 : 857C74D9
  • MD5 : ac9cc62baa2f4d56330eef3449b45101
  • SHA : ab6d03405ff9c649f15ec5bb65745ad2006ff66b

제작자/제공자의 답변

2009년 5월 16일 현재 AcroEdit - 질문 및 답변에 글을 올린 상태이다.

관련 문서

내부 문서

외부 문서

이 글은 스프링노트에서 작성되었습니다.


글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

벌레의 유형

단순히 화면 출력을 잘못하는 벌레이다.

벌레의 발견

벌레 정보

아크로에디트 버전 0.9 / 빌드 0.9.19.84 (2008년 12월 17일자)에서 발견하였고, 이전 버전 확인하지 못함.

배치파일 구문 강조에서 나타났다.

벌레 찾기

20090321ae01.png
그림1. 주석 명령어 REM을 5번 사용하였으나 2번만 주석이 달렸다. 또한 @도 문법 강조가 되지 않고 있다.

강좌를 올리려고 배치파일을 찾아서 편집하다가 우연히 알게 된 벌레이다.

위에서 보면 배치파일에서 주석을 나타내는 지시자는 REM이다. 엄밀히 말하자면 REM 명령어이다. 이때 배치파일은 대문자와 소문자를 가리지 않으므로 rem, REM, Rem, rEm, reM 등은 모두 주석으로서 작동해야만 한다. 실제로 설정에서도 다음 그림처럼 rem과 REM이 적용되어 있다.

20090321ae03.png
그림2. 행 주석 표시자로 REM을 지정하고 있다.

한편 @ (at)에 대한 문법 강조도 이루어지지 않고 있다.

20090321ae02.png 20090321ae04.png
그림3 / 그림4. 단어 구분 기호에 대한 문법 강조 설정

위 그림에 보면 단어 구분 기호로서 @을 사용하고 있고, 그 색상은 빨간색이다.

그러나 위 그림 1을 보면 문법 강조가 되어 있지를 않다.

제작자/제공자의 답변

AcroEdit - 질문 및 답변에 글을 올린 상태이다. 현재 제작자가 검토를 하고 있는 중이다.

관련 문서

 

 

이 글은 스프링노트에서 작성되었습니다.

글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

아크로에디트(AcroEdit)는 마이크로소프트 윈도(Windows 95 또는 이후 버전, Windows NT 4.0 또는 이후 버전) 환경에서 사용 가능한 텍스트 편집기입니다.

아크로에디트를 쓰기 전에는 이지패드와 이지뷰어를 사용했다. 그런데 그쪽 개발자와 마찰이 생겨서 아크로에디트를 쓰기 시작했다. 초기 아크로에디트의 실행 속도는 이지뷰어나 이지패드에 비해 그리 빠른 속도가 아니었다. 하지만 너무 느린 이지뷰어/이지패드의 업데이트에 질려 있던 나는 아크로에디트 개발자의 성실함에 반해 지금까지 쓰고 있다.

프로그램 정보

  • 저작권자/제작자 : 김성동
  • 운영체제 : 윈도95 또는 이후 버전, 윈도NT 4.0 또는 이후 버전
  • 버전 : 버전 0.9 / 빌드 0.9.19.84 (2008년 12월 17일자)
  • 홈페이지 : http://www.acrosoft.pe.kr/
  • 다운로드 페이지 : http://www.acrosoft.pe.kr/board/ae_download
  • 저작권 : 프리웨어
  • 소스 공개 여부 : 소스 비공개
  • 평가 : @@@@@@@@@@ ( 8 / 10 )
  • 실행 화면 :

    제작자가 홈페이지에 공개한 실행화면
    20090322ae00(1).png
    내 컴퓨터에서 실행한 화면
  • 설명 :
    오류를 지속적으로 보정하여 완성도가 높은 프로그램이 되어 가고 있다. 또한 쉬운 사용법과 문법 강조 기능을 갖춘 기본에 충실한 문서 편집기이다.
  • 기타 :
    강력한 기능을 바라는 사용자에게는 권하지 않는다. 그런 사람은 울트라에디트에디트플러스를 사용하기 바란다.

관련글

없음

이 글은 스프링노트에서 작성되었습니다.

'소프트웨어 > 소개' 카테고리의 다른 글

Windows Automated Installation Kit for Windows 7  (2) 2009.05.09
HxD  (2) 2009.04.23
MultiArc  (0) 2009.04.02
Total Commander  (0) 2009.03.28
OpenCapture  (0) 2009.03.21
글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

카테고리

분류 전체보기 (1005)
스크립트 (22)
벌레와 팁 (126)
소프트웨어 (240)
하드웨어 (6)
이야기 (24)
말의 나무 (506)
미쳐보자 (22)
일기 (48)
아이폰 (10)

최근에 올라온 글

최근에 달린 댓글

최근에 받은 트랙백

달력

«   2024/03   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31

글 보관함