Re: PEAR-FAQ

i'm not a PEAR-person myself, not yet at least. but what about something like NAME_OF_PACKAGE.pear_doc and then on the pear-web have a "translator" the .pear_doc could look something like this, #NAME "blah blah encoder" #DESCRIPTION "this blah blah will encode any file named .blah and then put it into .bleh-format. great, isn't it?" #FUNCTION "encodeBleh" #FUNCTION_DESCRIPTION "this is the actual function you use" or maybe something more like html, <NAME>blah blah encoder</NAME> <DESCRIPTION>this blah blah will encode any file named .blah and then put it into .bleh-format. great, isn't it?</DESCRIPTION> <FUNCTION>encodeBleh</FUNCTION> <FUNCTION_DESCRIPTION>this is the actual function you use</FUNCTION_DESCRIPTION> and then the translator could translate into .html, .doc, .txt, .pdf and whatever formats you like :o) in this way you are not limiting the number of formats and it's easy to change format and look in the future as well. just a thought. / d "Richard Heyes" <richard.heyes@heyes-computing.net> wrote in message news:NEBBIDEMHHJJCANAAAKFEEHEINAA.richard.heyes@heyes-computing.net... > > > - How should I write the documentation of my package? > > > > I would prefer HTML, at least. > > How about allowing multiple formats. For example someone can do their > documentation in plain text/html/whatever if they so desire. I saw > docbook/xml mentioned in one recent post, which I'm not currently up on, so > if the docs have to be strictly this format (for example), then they > wouldn't get done (at least not until I have time to look it up). Having > some docs is better than none (well, most of the time :). > > -- > Richard Heyes > "When you were born, you cried and the world rejoiced. Live your life > so that when you die, the world cries and you rejoice " - Cherokee saying >