-
- 1. 외국ISBN링크 아마존 그림으로 표시
-
- 2. 오에카키에 대해서 수정해주셨으면 하는 내용
-
- 3. 한줄 달기
-
- 4. 음반 이미지
-
- 5. 자체 Upload
-
- 6. Print용 출력
-
- 7. weblog
-
- 8. include
-
- 9. 오에카키
-
- 10. RSS
-
1. 외국ISBN링크 아마존 그림으로 표시
sub ISBNLink {
....
if ($num =~ /^89/) {
return "<a target=_blank href=\"http://www.aladdin.co.kr/catalog/book.asp?ISBN=$num\"><img $ImageTag src=\"http://www.aladdin.co.kr/Cover/$num\_1.gif\" border=1></a>";
}
$rawprint = "<img src=http://images.amazon.com/images/P/$num.01.MZZZZZZZ.gif>";
$first = "<a target=_blank href=\"http://www.amazon.com/exec/obidos/"
. "ISBN=$num\">";
$second = "<a target=_blank href=\"http://shop.barnesandnoble.com/bookSearch/"
. "isbnInquiry.asp?isbn=$num\">" . T('other') . "</a>";
$html = $first . $rawprint . "</a> ";
$html .= "($second, $third)";
....
}
저는 그냥 아마존만 나오게 해버렸습니다. --
Bab2 2002-12-17 2:10 pm
- 그러면 인터페이스가 어찌 되는 건가요? 그냥 평소처럼 쓰면 그림은 아마존에서 가져온다는 건가요? 요새 남의 소스를 들여다 보면서 생각할 여유가 없어서... 그간에 올려주신 것들도 반영 못하고 있네요. 에구구...
-
$html .= "($second, $third)";
이것을 없애면 그림만 뜹니다.
$rawprint = "<img src=http://images.amazon.com/images/P/$num.01.MZZZZZZZ.gif>";
$html = $first . $rawprint . "</a> ";
이것은 아마존으로부터 가져올 그림주소와, 그것의 출력입니다. 이것만 추가하면 그림은 아마존, 링크는 반스앤노블스로 걸릴겁니다.
--
Bab2 2002-12-17 5:47 pm
2. 오에카키에 대해서 수정해주셨으면 하는 내용
제가 사실은 홈페이지 위키는 제 맘대로 고친걸 사용하고 있지만 회사에 몰래 깔아서 쓰는 위키는 여기서 받아서 쓰고 있습니다. -_-;
좌우지간 그래서 오에카키 기능을 넣어봤는데 좀 문제가 있어서 다음과 같이 수정해주셨으면 합니다.
sub WriteBinaryToFile {
my ($file, $string) = @_;
open (OUT, ">$file") or die(Ts('cant write %s', $file) . ": $!");
binmode(OUT);
print OUT $string;
close(OUT);
}
&WriteBinaryToFile($target_full, substr($buffer, $p+2));
서버가 윈2000 IIS이고 ActivePerl일 경우 binmode를 안해주면 0a를 0d 0a 로 바꾸기 때문에 사이즈가 커져버리는 문제가 있더군요.
- 예, 반영해 놓겠습니다. 간만에 업데이트되겠군요. :-)
- 반영했습니다.
3. 한줄 달기
안녕하세요. 오랜만이네요. 조프입니다. WikiSandBox 를 보셨으니 아시겠지만 페이지에 대한 짧은 의견을 달 수 있는 매크로를 만들고 있습니다. 대강의 구현은 어찌어찌 했다 치고, 매크로의 형식이 문제가 되어서요.
일단, 매크로의 형식을 <comments> 이렇게 해놨습니다만, 이게 인자로 자기 페이지 이름을 가져야 하는데 매크로 처리하는 부분에서 페이지 이름을 알 방법이 있나요? 지금은 땜빵으로 전역 변수를 만들어서 거기다 설정을 해버렸습니다만... -_-; 영 맘에 들지 않는군요. 그렇다고 <comments(페이지이름)> 이렇게 하자니 너무 귀찮고요.
그리고 화면에 출력하는 방식은 각자 알아서 수정해서 쓴다 치더라도. 문제가 있습니다.
- 한 페이지에 여러개가 가능하게 할 것인가? 이게 되게 하려면 <comments(식별자)> 이런식으로 해야할텐데. 구현이야 어렵지 않지만. 과연 필요한가 문제가 있습니다.
- 그리고 지금 제가 구현한 것처럼 입력폼의 위에 아래로 쌓이게 하느냐, 아니면 입력폼의 아래에 위로 쌓이게 하느냐의 문제도 있지요. <commentsup>, <commentsdown> 이렇게 따로 구현을 할까요? -_-;
윗단락은 질문이고 아랫단락은 의견 수렴입니다. 의견 남겨주세요.
- 와 좋군요. 의견 답니다 :)
- 한 페이지에 여러개 있을 필요는 있을듯 합니다.
- 디폴트값을 일단 주는게 좋을거 같네요. 제 추천으로는 위로 쌓이는 한줄달기.
- <comments(up / down, 1 / n)> 이런 식으로 인자를 주는게 어떨까요? n이라고 인자를 주면 한줄달기가 아니라 칸이 좀 큼직하게 나와서 긴 댓글을 달 수 있도록요.
- 일단 제 홈페이지에 [소스 수정할 내용]을 올렸습니다. 칸이 큼직하게 나오는 것은 태그를 바꿔써야 하다보니 귀찮아서 못했습니다. 아마 다른 분이 수정을 해주실 겁니다;;; -_-;
사실 처음에 이 매크로를 만들고 싶었던 것은 꽤나 오래전 얘기인데... 그 때 이 매크로를 만들고 싶었던 이유 중 하나는 위키로 최대한 일기장스럽게 만들 수 있지 않을까 하는 것이었습니다. 예를 들자면 [Nyxity님의 Monologue 페이지] 같이 말이지요. (특정 페이지를 거론한 이유는 제가 옛날에 생각했던 모습을 거의 똑같이 구현하셨기 때문입니다. Nyxity님의 양해 부탁드립니다.) 날짜별로 페이지 마지막에 comments 매크로를 써주면 쉽게 답글을 달 수 있겠죠. 그런데 여기서 문제가 무엇이냐. 바로 페이지 아이디입니다. 지금 생각으로는 매크로 인자에 페이지 이름을 주지 않는 이상, include를 할 때 제대로 처리되게 만들 방법이 없네요. 돌이킬 수 없기 전에 같이 생각 좀 해보시면 좋겠습니다.
이것도 mysign 처럼 post 매크로로 페이지 이름을 넣어버리는 방식으로 바꾸는게 맞을까요?
<comments(UseModWiki소스수정/반영된사용자의견,0)> 이렇게 치고 저장을 하면
<comments(UseModWiki소스수정/사용자의견, 0)> 이런 식으로 저장이 되는 것이죠.
이렇게 하면 위에 인용한 페이지 같은 경우 각 날짜별로 페이지 끝에 <comments(UseModWiki소스수정/반영된사용자의견,0)> 매크로를 달아놓으면 해당 날짜 페이지에서 입력을 처리할 때는 물론, 위의 링크건 페이지에서 입력을 처리할 때도 잘 처리할 수 있을겁니다. 입력을 하면 include 된 페이지로 이동한다는 문제가 있긴 합니다. 어쨌든 지금까지 제가 구현한 방식으로는 include에서 아무 일도 할 수 없습니다. 부디 아이디어나 구현 부탁드립니다.
- mysign방식을 그냥 써버리면 해결이 되지 않나 싶군요. 이미 그렇게 하신듯 하구요. :)
--
거북이 2003-8-19 12:43 pm
- 네, 귀찮아서 딴 방법이 없을까 했는데 결국 그 방법으로 대강 해결했습니다.
조프님이 만드신 것을 /Comments매크로에 반영했음. (사실은 이 의견이 올라왔을 당시에는 정신이 없어서 전혀 관심을 가지지 못했고... 그 후에는 이 의견의 존재를 망각하고 살다가 지금 생각났습니다 ^^;;)
4. 음반 이미지
음반 이미지를 가져오는 핫트랙의 이미지 서버 주소가 바뀌었습니다. 다음과 같이 수정해주시기 바랍니다.
sub StoreHotTrack {
my ($id) = @_;
return "<a href=\"http://www.hottracks.co.kr/cgi-bin/hottracks.storefront/Product/View/$id\">" .
"<img src=\"http://image.hottracks.co.kr/hottracks/cdimg/$id.jpg\" alt=\"$id\"></a>";
}
- 예, 감사합니다. 지금은 졸려서 내일 고치겠습니다 ^^
그 후로 보름이 지나서야 반영함 :-)
5. 자체 Upload
UseModWiki에서도 게시판을 통해 그림을 올리고 link를 거는 시스템 보다는 자체 페이지 내 upload를 지원했으면 좋겠습니다. 구현 자체도 큰 어려움은 없을 것 같고 Perl로 된 file upload library들이 많이 돌아다니고 있으니 거기 있는 code를 이용해도 될 것 같구요. -Jmjeong
- 글쎄요, 제게는 구현에 막대한 어려움이 있을 것 같군요. ^^; 그리고 동일한 화일을 여러번 업데이트할 경우 이전 버전의 화일을 어떻게 처리할 것인지 등에 대해서 WikiX 에서도 말이 나왔던 것 같은데 어찌 해결했나 모르겠네요. 이건 겨울방학 때로 미루죠. 그리고 지금도 UseModWiki 가 점점 심플함에서 멀어지는 것 같아 가슴이 아픈데... :-)
- 전 벌써 200k 돌파했습니다.. -ㅅ-;
--
Bab2 2002-12-10 3:18 am
/화일업로드에 반영. 완료.
6. Print용 출력
Palm에서Wiki사용하기 을 고민하고 있는데 막상 PalmWiki 페이지를 palm에서 보기는 윗쪽 header 정보 때문에 번거롭습니다. [JofWiki Palm Page]에 가보니 palm argument가 존재하면 윗쪽 header가 나오지 않도록 하고, link에도 argument를 넘겨서 iSilo등에서 보기좋도록 변경해 놓았던데, 여기 소스에도 반영해 주세요.
- 조프님 홈페이지의 그 것은 예전에 봤습니다만, 그게 완성된 모습인지는 모르겠네요. 그 상태에서 더 손을 봐야 된다거나 아쉬운 점이 있다면 조프님께 건의를 하고, 최종 결과물을 적용하도록 하죠.
- WikiZ는 어떤가요? 전 PDA는 구경도 못해본지라..;;
--
Bab2 2002-12-11 11:51 am
언제나 그러하듯이 perl을 모르는 제가 짠 소스는 가라입니다. -_-; 일단 제 PDA 페이지 수준으로만 나오게 하자면 고칠 부분은 그리 많지는 않네요. 사실 지양위키 PDA 처럼 diff가 위에 나오는게 더 좋지 않을까도 생각하고 있습니다. 어쨌든. 원하시는 분이 이렇게 많으니(-_-;) 소스 조금 더 손 본 다음에 올리도록 하지요. --
조프 2002-12-11 12:24 pm
- 대강 정리해서 프로그래밍팁/Wiki 에 올렸습니다.
/PDA용클립에 반영. 완료.
7. weblog
Blog이라고 하나요? 방명록을 완전히 없애버렸었는데. 별로 좋아하는 사람이 없네요. '_'a
[여기]를 한번 봐주세요.
저런것이 구현된다면, 일반인들이 보기에 거부감이 줄어들 수도 있다는 점에서 좋을거 같네요.
(WikiX에는 이미 구현이 되었던가요?) --
Bab2 2003-2-12 1:24 am
- 으음... 이슈 하나를 해결하는 속도보다 새로운 이슈가 등장하는 속도가 더 빠르니.. 이 /사용자의견 페이지의 양이 줄어들 겨를이 없군요. ^^; 링크한 곳에 있는 그것은.. WikiX 에서 등장했을 때 많은 사람들이 경악한 그것이로군요. 저는 도전하고 싶지 않은데요. ^^; (그런데 blog 하고는 무관한 거 아닌가요? 방문객의 코멘트를 받을 수 있다는 것만 유사할 뿐.. 제가 잘못 알고 있는지도. weblog 니 blog 니 하는 게 갑자기 주목받는 이유를 저는 잘 모르겠던데요. 기존의 웹게시판에 코멘트 기능이 있는 것이나 포럼 사이트들과 뭐가 다른지.. 하긴 한국의 웹게시판들이 워낙 뛰어나긴 하죠)
- 상관이 없진 않을겁니다. 입력폼을 한줄짜리가 아닌걸로 바꿔주고 답글기능도 가능하게 후처리를 해주면 완벽하게 방명록하나가 만들어지는거겠죠.. '_';; 처음엔 간단하게 매크로를 만들어주고 입력폼은 직접 html로 문두에 삽입해주면 되겠다 생각했는데 페이지의 중간에 새로운 내용을 삽입한다는게 쉬운게 아니었네요.. 우웅.. '_'a
- 지금 관심이 있는게 터치그래프위키브라우저(아니면 비주얼투어)나, TeX연동 같은 것들 몇개가 더 있는데 이건 도저히 엄두가 안나네요. 특히나 터치그래프같은건 자바애플릿을 수정해줘야되는데, 그럴 자신도 없고요(자바 잘하시는분 어디 없나여 ㅜㅡ).
--
Bab2 2003-2-12 2:03 am
/Comments매크로에 반영. 완료.
8. include
UseModWiki소스수정/Include매크로가 아주 유용하더군요... 그런데... 이런 경우가 있습니다. A페이지에서 B페이지의 내용을 include를 하고는 싶은데 전체는 하기 싫고 #을 이용해서 일부만 include를 했으면 좋겠다.. 라는 생각이 들더군요. (욕심은 끝도 없어 ^0^ ) 설마 이미 이렇게 되는건가... ^_^;;
- 무리라고 생각됩니다. :-) 그 '일부'의 내요만 별도의 페이지로 만들어서 양쪽에서 링크를 하시면 될 것 같네요.
/NoInclude태그에 반영. 완료.
9. 오에카키
며칠 전부터 이거에 매달리고 있습니다. /화일업로드하고 유사하게 페이지 편집시에 별도로 창을 띄워서 할 수 있도록 하고 있는데, 그럭저럭 되어 가고 있는데 커다란 문제 두 가지가 있네요.
- 그림을 저장할 때 호출하는 스크립트와 오에카키를 종료할 때 호출하는 스크립트가 별개로 동작한다.
- 따라서 저장이 제대로 되었는지, 제대로 되었다면 저장된 화일명이 무엇인지 등을 제대로 위키에서 알려줄 수 없습니다. 이것은 좀 불편해도 어찌어찌 하겠는데...
- 그림을 저장할 때 그림 데이타를 스크립트로 전송하는 포맷이 제멋대로이다
- 이게 진짜 문제인데... 위키에서 $q->param() 의 형식으로 그림을 가져올 수가 없네요. 오에카키에 같이 들어 있던 스크립트에서는 그냥 POST 로 넘어온 것을 통채로 읽어서 저장을 하는데, 위키에서는 다른 액션들과 구분을 해야되기 때문에 그럴 방법이 없죠..
궁여지책으로, 저장할 때 불리는 스크립트만 별도의 화일로 작성할 수는 있습니다. 그런데 이 경우 사용자 인증이라던가 환경설정 등에 관련된 부분을 죄다 중복해서 작성해야 합니다. (아니면 기존 위키 스크립트를 쪼개어서 모듈로 만들던가..)
CGI.pm 모듈을 사용하면서 원래의 POST 데이타를 어떠한 가공도 없이 통채로 얻어낼 수 있는 방법을 아시는 분 계시면 좀 가르쳐 주세요. 펄매니아에도 올렸는데 답은 얻었으나 별 도움이 안 되네요. 이것만 알아내면 남은 것은 일사천리로 되는데 말이죠...
- 지금은 myring3.com의 소스를 약간 수정해서 쓰고있습니다. jar화일(시짱 폐인트BBS의 그것이라고 생각됩니다만..) 사용시 저장과 화일등록이 두개의화일로 구분되어 있습니다. 어차피 중간단계에 별도의 스크립트를 두어야 한다는 얘기입니다. 일단 연습장 한번 보구나서..ㅡ.ㅡa -- bab2
- 예, 저도 거기서 시작했죠 (일본어를 모르는터라, 다운받을 수 있는 곳을 찾느라 힘들었습니다. 잘 안 찾아지더군요) 애초에 PaintBBS.jar 화일의 개발자가 그림 전송을 조금만 더 신경써 주어서 화일 업로드처럼 multipart/form-data 형식에 맞춰 줬다면 전혀 문제가 안 되었을 거라고 생각됩니다. 그러면 $q->param('image') 처럼 가져오면 되니까 wiki.pl 에 통합시키는 것이 일사천리로 되었을 텐데... 솔직히 개발자가 원망스럽기 그지없습니다. :-) 그 부분을 변경할 생각이 없냐는 메일을 보냈는데, 영어로 쓰려니 왜 그렇게 요청을 하게 되었는지 사정을 제대로 설명하기 힘들더라고요. 답장은 왔는데 전송 데이타 형식이 나와 있는 URL 을 알려주고 끝이로군요. 하긴 자기 입장에서는 왜 잘 돌아가는 것을 굳이 바꿔야 하는지 이해하기 힘들겠죠...
- 그래서 별 수 없이 저장 (게다가 저장시 호출하는 스크립트와 종료시 호출하는 스크립트들 별도로 호출하게 한 것도 악수라고 생각되네요) 하는 부분만 따로 작성했습니다. 일단 궁한대로 동작은 하지만 사용자 권한 검사나 기타 복잡한 에러 처리는 꿈도 꾸지 못하고 있네요. :-/
- 사용자 권한 같은건 [이걸] 참고해주시구요. 사실 가장 필요한건 존재하는 그림화일의 수정입니다. 매크로 형식으로 구현할 수 있을까 생각되는데... 그리고, 그 사람의 라이센스로는 자바애플릿 본체는 수정불가라고 했었던거 같은데, 저런 링크를 보냈다니, 놀랍군요..으흐흐.. 따로 작성할 필요없이 액션을 별도로 둬버리면 될거 같단 생각은 드네요. 오늘도 술좀 먹은지라..ㅡ.ㅡa
--
Bab2 2003-3-24 12:32 am
- 애플릿은 수정 가능한지 모르겠고, 외부의 펄 스크립트를 수정배포하는 것은 허용하는 듯 하던데요. 알려 준 링크도 원래 있던 것 같습니다. 일본어라서 알아 듣지는 못하겠지만.. [이것]이 답장으로 받은 링크입니다. 그리고 위에 적어주신 링크는 도움이 될 것 같기도 하군요. 해봐야 알겠습니다만, 잘 하면 훨씬 깔끔해지겠네요. 위키 본체를 require 한다는 것이 배보다 배꼽이 더 크긴 하겠습니다만. :-)
- 그리고 그냥 wiki.pl 에서 액션을 두어 저장하는 것은.. 저도 그러고 싶은 마음 간절하나 방법을 찾지 못하고 있습니다. 처음에 했던 얘기지만 그림 데이타가 CGI.pm 모듈이 처리할 수 없는 (없는 건지 있는데 제가 못하는 건지 몰라도) 형식으로 오기 때문에 액션을 별도로 받을 방법이 없더군요. [펄매니아 게시판]에 제가 올린 글을 참조하세요. 외국 뉴스그룹에 올려도 답이 없군요. ㅠ,.ㅠ
이런... 저장할 때 별개의 스크립트를 썼더니만, UserCanEdit 가 제대로 동작을 못 하는군요. 스크립트 이름이 달라지는 바람에 쿠키의 문제가 있는 건지.. EditAllowed 를 0 으로 한 상태에서 editor 또는 admin 권한이 있는 사용자의 경우 허용을 해줘야 하는데 해주지를 못 하는군요.
- 천상 확인하는 시점을 오에카키 애플릿이 불리기 직전으로 잡아야 되겠네요. -- bab2
myring3의 것을 거의 수정 안하고 [finish.cgi], [getpic.cgi] 이렇게 쓰고 있습니다. getpic.cgi가 화일을 저장하는데 쓰이는데, 그저 참고용입니다.ㅡ,.ㅡa 근데 그림저장하는데 CGI모듈을 써야하는건가요?
에에.. 그리고, 오에카키링크를 편집창에 두는 것보다는 매크로를 사용하는게 더 낫지 않을까 싶은데요.. 근영님 생각은 어떤지 궁금하네요. 잠시 담배사러.. ^^a --
Bab2 2003-3-24 11:21 am
- 예, 현재는 오에카키 애플릿을 부르는 순간과, 그림 저장후에 결과를 출력하는 시점은 wiki.pl 이 처리하니까 문제가 없고, 딱 한 경우, 즉 애플릿을 일단 띄운 후에, 다른 창에서 로그아웃을 하고 (따라서 수정권한이 없어지죠) 그 상태에서 그림을 그려서 저장하면 저장이 되어 버리는 것을 막을 수가 없는 상태입니다. 이게 말을 바꾸면... 다른 사람이 자기 계정에 애플릿을 설치하여 그림을 그린 후 남의 홈페이지에 저장을 시켜버릴수도 있다는 얘기입니다. (시도해 보지는 않았지만...) 뭐 이것은 오에카키 자체의 한계이고, 그래봤자 wiki.pl 에서 권한을 주지 않으니 그림을 저장만 할 수 있을 뿐 그 후에 다른 일을 할 수는 없겠습니다만, 그래도 기분이 매우 나쁘죠... 확인해보니까 확실히 스크립트 이름이 달라서인지 쿠키를 얻어오지 못하는군요. (그런데 익스플로러에 저장된 쿠키를 보면 스크립트 이름은 없고 디렉토리까지만 나와 있는 것 같은데... -.-;)
- 이런 이유로 getpic.cgi 의 기능을 wiki.pl 에 설치하는 게 불가피한데, 그러자니 CGI 모듈을 반드시 써야만 한다는 거죠. 그림을 제외한 다른 모든 정보 (action, 쿠키 등) 를 CGI 모듈을 통해서 받아오니까요. 그런데 현재 저 PaintBBS.jar 가 리턴해주는 그림 데이타가 CGI 모듈을 통해서 읽을 수 없기 때문에, 결국 CGI 모듈 사용을 아예 포기하고 다른 정보들까지도 죄다 wiki.pl 이 스스로 STDIN 에서 읽어서 파싱해줘야 하는 사태가 발생해버린다는 거죠. 뭐 제가 CGI 에 대해 잘 아는 게 아니라서 여기까지 한 말은 다 짐작에 불과합니다.
- 오호... 방금 제 홈페이지에서 오에카키를 띄워서 폐인월드에 업로드시키는 것을 시도했는데 (죄송^^), 자바 클래스 차원에서 보안 에러를 일으키며 거부되는군요. :-) 그러면 저 "남의 계정에 업로드" 의 걱정은 해결되었으니, 그냥 이 상태로 마무리해도 될 것 같네요.
- 그리고 매크로를 사용한다는 말은 저번에 말씀하신 "그림을 클릭하면 다시 그 그림을 수정할 수 있는" 것을 말씀하시는 건가요? 일반적인 경우에는 남의 그림을 맘대로 편집할 수 있게 하는 게 그다지 좋은 생각 같지는 않습니다. 그렇지만 여러 사람이 수정가능하게 그림을 올려야 되는 경우도 있을 수 있겠네요. 회의에 사용하는 그림 같은 경우... 이 경우 기존의 데이타를 바로 덮어쓰게 한다면 위키의 edit conflict 같은 처리를 해주기가 힘들것 같으니, 기존 그림을 불러와서 편집하되, 저장은 새 이름으로 하게 하는 것을 생각해 볼 수 있겠네요. 그런데 PaintBBS.jar 에서 '기존 데이타 편집'을 하게 할 수 있나요?
- 그런데 제 홈에서는 그림을 저장할 때 "성공"이라는 한자어가 다시 뜨는 바람에 ok 버튼을 한 번 더 눌러줘야 했는데, 폐인월드의 오에카키는 그렇지 않네요? 어떻게 하신건가요?
- 아마도 페인트비비에서 기본기능으로 이어그리기를 제공할겁니다. 처음 애플릿을 부를때, 이미 있는 그림을 인자로 주면 되었던걸로 알고 있는데, 요전에 그거때문에 삽질좀 하다가 관두긴 했습니다만..
<param name="pch_file" value="./data/s_000026.pch">
요거이 그리는 과정을 저장하는 화일을 지정하는 파라미터이고
<param name="image_canvas" value="./data/IMG_000028.jpg">
요거이 이어그리는데 필요한 파라미터인데, 실제로는 원래 그림을 배경으로 사용하는 형식일겁니다.
애니메이션은 그다지 필요하지 않아보여서(사실은 귀찮아서..==;) 손을 안댔었고, 이어그리기 같은 경우는, 작품(?)을 만들때 꼭 필요한 기능인데, 저는 애플릿을 위키페이지에 그냥 붙여버렸기 때문에, 딱히 방법이 없더군요. 애플릿 파라메터는 http://senicy.net 의 페인트비비 cgi를 참고 하시면 많은 도움이 될겁니다. 여유가 있으시면 저곳에 있는 자바스크립트로 추가된 색목록도 적용을 시켜주시면 좋겠지요. :)
아. 그리고, 성공 메세지는... 이곳의 애플릿은 1.06버전인거 같군요. 2.04 최신을 쓰면 될겁니다. 2.04도 2.04x라고 완전 영문화된 버전이 있던데.. 자세한건 모르겠네요.
--
Bab2 2003-3-24 12:46 pm
- 저 팔래트 기능은 멋지긴 한데 일거리가 너무 느는군요. 근데 저 senicy 란 곳에서 사용하는 cgi 는 어디서 구할 수 있는 건가요? 그 사이트의 링크는 안 뜨는 게 너무 많아서... html 소스를 보면서 역추적하는 것도 지겹고... 그리고 애플릿은 업글 했습니다. 감사~
- 그리고 그 이어그리기 문제 말이죠.. 제가 잘못 한 건지는 몰라도 그림을 저장할 때는 png 형식으로 저장되는데 png 는 image_canvas 로 올려도 안 되던데요. jpg 는 되고요. 저장한 후 불러올 수가 없네요.. -_-a
- 정말 그렇네요. 파라미터에서 jpg랑 png를 선택하는게 있긴 한거 같은데..ㅡ.ㅡ;; 그리고, 그 cgi는 에에.. 링크가 죽었나 보네요. 좀 이따가 압축해서 자료실에 올려놓겠습니다.
--
Bab2 2003-3-24 3:04 pm
bbs_note.zip 입니다.
- 흐미... 들여다봤더니만... 분석할 엄두조차 나지 않습니다. ㅠ,.ㅠ 그렇게까지 많은 기능의 오에카키 기능을 위키에 내장할 필요도 느껴지지 않고요. 전문적인 오에카키는 그냥 extern 을 사용해서 페이지만 별도로 삽입한다던가 아니면 폐인월드의 오에카키 페이지 식으로 위키와 통합하는 쪽으로 하고, 위키에 내장하는 것은 이 쯤에서 마무리할까 합니다.
/오에카키에 반영. 완료.
RSS논의로 옮깁니다.
/RSS제공에 반영. 완료.
위키위키분류