Re: [PHP-DOC] table of contents (mess?)
On Thu, 29 Nov 2001, Gabor Hojtsy wrote: This is a general issue in the DocBook DSSSL (and I think also in the XSL) style sheets. We are familiar with that special placings, but for novices, these can be annoying. What do others think about that? I think the placement of TOCs can be controlled by setting some parameters. If it can't, then we can do it ourselves... and I'd prefer them to be at the start of the relevant section. Funny how I (or anyone else) have never realized this problem to even exist before. -- Jouni
Re: [PHP-DOC] cvs: phpdoc /ar preface.xml
On Sun, 18 Nov 2001, Salah Faya wrote: visualmindSun Nov 18 09:41:43 2001 EDT Added files: /phpdoc/arpreface.xml Log: Translated to Arabic Index: phpdoc/ar/preface.xml +++ phpdoc/ar/preface.xml ?xml version=1.0 encoding=iso-8859-1? Encoding can't be the right one... -- Jouni
Re: [PHP-DOC] cvs: phpdoc /ar preface.xml
On Sun, 18 Nov 2001 [EMAIL PROTECTED] wrote: On Sun, 18 Nov 2001, Jouni Ahto wrote: Yes. Are there other new translations in work that aren't supported? Might add those as well... ar, tr, kr and hk (already added) Turkish is already supported, also korean (but the subdir should be renamed ko), and hk seems to have own versions of the needed. If they were sent to Norman Walsh too, it will probably appear in some future version of the stylesheets. So that leaves arabic. There was some guy on the list a few months ago who spoke about a hebrew translation. Has anyone heard about him after that? -- Jouni
Re: [PHP-DOC] cvs: phpdoc /ar preface.xml
On Sun, 18 Nov 2001 [EMAIL PROTECTED] wrote: On Sun, 18 Nov 2001, Jouni Ahto wrote: Index: phpdoc/ar/preface.xml +++ phpdoc/ar/preface.xml ?xml version=1.0 encoding=iso-8859-1? Encoding can't be the right one... should be iso-8859-6 iirc And Jouni, the stylesheets do not support the 'ar' language out of the box, do you know what is needed to make it work? Yes. Are there other new translations in work that aren't supported? Might add those as well... -- Jouni
Re: [PHP-DOC] cvs: phpdoc /ar preface.xml
On Sun, 18 Nov 2001, Jirka Kosek wrote: The best way is to create Arabic version of file http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/docbook/gentext/locale/en.xml I know, I asked Norman. and send it as a patch to DocBook project on SourceForge. From this file are generated localizations for DSSSL and XSL stylesheets. For DSSSL stylesheets you should also make arabic version of http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/docbook/dsssl/common/dbl1en.dsl Where are defined other subtle things related to localization. I'll try to help Salah with this whenever I can, but I think your knowledge is needed at some phase. But I'm not sure wheter Jade and JadeTeX support right-to-left text, so if it is possible to get printed version of Arabic documentation. Maybe one more reason to switch to an XSLT-based solution. -- Jouni
Re: [PHP-DOC] cvs: phpdoc /en/functions oracle.xml
On Mon, 12 Nov 2001, Hartmut Holzgraefe wrote: hholzgra Mon Nov 12 11:39:46 2001 EDT Modified files: /phpdoc/en/functions oracle.xml Log: there is no comment tag in DocBook4 :( - changed comment.../comment to !-- ... -- It's probably remark or something now... -- Jouni
Re: [PHP-DOC] New CHM manual opinions
On Thu, 1 Nov 2001, Hojtsy Gabor wrote: in a short time (although one of the goals of this new CHM is to show how many things can be using the current manual content as input). Just to note, with some transformations with XSLT, almost anything can use the current manual as input. And I'm learning that technology on a fast pace. Because I'm under a non-disclosure agreement, I can't tell exactly why, but it relates to some finnish banks, and they wouldn't like to the old currency (FIM) to show up in a new (EUR) systems' reports. And it's not only fixing the old system, they'll have a completely new system (that seems to have a strange sentence 'This product includes software developed by the Apache Software Foundation (http://www.apache.org/' when it either launches itself or the user selects 'Help-About'.) So, I think, I'm going to have a few ideas about the manual and how to produce some of the readable versions early in the next year. (If those hints were not enough, go to http://xml.apache.org/) -- Jouni
Re: [PHP-DOC] Polish national characters
On Mon, 22 Oct 2001, Egon Schmid wrote: Jouni Ahto is our guru and have access to php.net. And the guru is both quite drunken now and thinking how to match 59 transactions with only 27 distinct transaction numbers that should finally resolve to a dately changed Dow Jones STOXX 30 Nordic 30 index future variation margin. With one transaction number. I hate BHF-Bank. But back to the business. There is support for polish in dsssl stylesheets. So, there should be no problems, unless the stylesheets have some translations wrong. In that case, contact Norman Walsh. I'll do the setup for polish language next wednesday evening, unless someone beats me. Going to sleep now, and having something else tomorrow evening to do. -- Jouni
Re: [PHP-DOC] DocBook DTD upgrade
On Sun, 21 Oct 2001, Hojtsy Gabor wrote: Is anybody against upgrading the current DTD to the actual 4.1.2? I would happyly do the updates the weekend if nobody complains (sure I would test the whole module before, so it is working with the new DTD set). Please don't do it yet... because our docs do *not* conform to it. There's going to be a *lot* of errors. (But then, I can always make a customization... :) -- Jouni
Re: [PHP-DOC] RFC
On Sat, 20 Oct 2001, Jirka Kosek wrote: If you want to customize DTD it is always better to create customization layer than to directly edit existing DTD. With this approach it is much more easy to upgrade to new version DocBook which is used as a base for your DTD. The customization DTD might look like: !-- PHPBook DTD 1.0 (based on DocBook 4.1.2) -- !ENTITY % docbook PUBLIC '-//OASIS//DTD DocBook XML V4.1.2//EN' '/path/to/local/copy/of/docbookx.dtd' %docbook; !ELEMENT funcprototype %ho; (funcdef, (void | varargs | (optional | paramdef)+)) !ELEMENT optional %hh; (paramdef+ | %cptr.char.mix;)* !ELEMENT parameter %hh; (optional | %smallcptr.char.mix;)* In PHPBook documents you then would use this DTD instead of standard DocBook DTD. Thanks. I never understood that it's so easy... I think that change to DocBook DTD which you propose would be useful in general. I suggest you to post this request as RFE for DocBook DTD at the sourceforge pages. DocBook Technical Commitee has meatings each month, so they should discuss it quite early. Done. -- Jouni
Re: [PHP-DOC] RFC
I'm beginning to think that because we don't actually conform to DocBook anyway, we might as well do some small customization to the DTD and try get the changes (or something that provides similar functionality) to 6.0, even if it takes a few years. Before my reasoning why we should customize the DTD, some snippets out of the current DocBook documentation. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - funcsynopsis [...] Description A FuncSynopsis contains the syntax summary of a function prototype or a set of function prototypes. The content model of this element was designed specifically to capture the semantics of most C-language function prototypes (for use in UNIX reference pages). This is one of the few places where DocBook attempts to model as well as describe. Using FuncSynopsis for languages that are unrelated to C may prove difficult. [...] Future Changes Future versions of DocBook may provide additional environments for describing the syntax summaries of functions in other programming languages. [...] funcprototype Synopsis Content Model funcprototype ::= (funcdef, (void|varargs|paramdef+)) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - So, I take this to mean that DocBook isn't even meant to be the exactly right DTD for our documentation purposes, although it could become that in the future. The content model of funcprototype actually makes it impossible to correctly describe the way how PHP functions take arguments, so we should change it. The proposed changes: --- dbpoolx.mod Mon Mar 12 15:49:18 2001 +++ dbpoolx.mod.modifiedSat Oct 20 13:45:13 2001 @@ -3705,7 +3705,7 @@ !ENTITY % funcprototype.element INCLUDE ![%funcprototype.element;[ -!ELEMENT funcprototype %ho; (funcdef, (void | varargs | paramdef+)) +!ELEMENT funcprototype %ho; (funcdef, (void | varargs | (optional | paramdef)+)) !--end of funcprototype.element--]] !ENTITY % funcprototype.attlist INCLUDE @@ -6493,7 +6493,7 @@ !ENTITY % optional.element INCLUDE ![%optional.element;[ -!ELEMENT optional %hh; (%cptr.char.mix;)* +!ELEMENT optional %hh; (paramdef+ | %cptr.char.mix;)* !--end of optional.element--]] !ENTITY % optional.attlist INCLUDE @@ -6513,7 +6513,7 @@ !ENTITY % parameter.element INCLUDE ![%parameter.element;[ -!ELEMENT parameter %hh; (%smallcptr.char.mix;)* +!ELEMENT parameter %hh; (optional | %smallcptr.char.mix;)* !--end of parameter.element--]] !-- Class: Type of the Parameter; no default -- The last change is there just to stay compatible with the current way we write the documentation, and could(|should?) be removed if we change the DTD after fixing the current documentation. The first two would allow us to model PHP functions the way they really behave. For example: funcprototype funcdefint functionfoo/function/funcdef paramdefint parameterbar/parameter/paramdef optional paramdefint parameterbaz/parameter/paramdef paramdefint parameteraaa/parameter/paramdef optional paramdefint parameterbbb/parameter/paramdef paramdefint parameterccc/parameter/paramdef /optional /optional /funcprototype See how optional arguments could be grouped together, and later optional arguments be made depented on on previous ones. I'd like to hear Jirka's comments about alternative ways of doing this. Preferably in a way that has some chance to get accepted into DocBook 6.0. Speaking about a former RFC that I haven't made much noise of lately... the current DTD makes it very easy to split the function reference to smaller pieces, because the following is allowed: part [...] chapter titleDatabase functions/title [here go references...] /chapter [...] chapter titleMathematical functions/title [here go references...] /chapter [...] /part Was this actually forbidden in the old DTD, or were we all, including me, just too stupid to see it? (Hartmut should prepare to rewrite his RFC...) -- Jouni
Re: [PHP-DOC] RFC
On Fri, 19 Oct 2001, Hartmut Holzgraefe wrote: i have just uploaded the draft for the 'beyond' part of my conference talk The manual and beyond to http://zugeschaut-und-mitgebaut.de/php/conference-talk.pdf comments suggestions are highly appreciated :) I really like the part 'Maybe its time to get invloved [typos not fixed] into the DocBook project itself, [...]' (Jirka actually is doing exactly that). If DocBook can't satisfy a programming projects' needs, someone is not modeling something the right way. Currently, I refuse to have any opinions about whether it's us or the team that defines DocBook. -- Jouni
Re: [PHP-DOC] RFC
On Fri, 19 Oct 2001, Egon Schmid wrote: From: Hojtsy Gabor [EMAIL PROTECTED] So reworded: using namespaces to define tags, and use them along DocBook tags. This is exaclty not extending DocBook, but defining a DTD for our custom elements and use those two DTDs (DocBook and PHPDoc) side-by-side. This may be a misinformation. With tags I am always reffering to elements. Please don´t touch them. Customization is another deal. Just to note: we are actually not using any official DocBook... manual.xml says: !DOCTYPE book PUBLIC -//Norman Walsh//DTD DocBk XML V1.7//EN ./dbxml/docbookx.dtd [... etc , then, phpdoc/dbxml/docbookx.dtd starts with: !-- DocBk XML V3.1.7 DTD Copyright (C) 1998, 1999 Norman Walsh http://nwalsh.com/docbook/xml/ See COPYRIGHT for more information Please direct all questions and comments about this DTD to Norman Walsh, [EMAIL PROTECTED]. -- And then, when I went and poked around at http://www.docbook.org/, found this: XML DocBook XML 4.1.2 is the current XML version of DocBook. There are no official XML versions of DocBook prior to V4.0. Maybe it should be the time to find out what the current DTD actually is, and what it allows us to do? -- Jouni
Re: [PHP-DOC] RFC
On Fri, 19 Oct 2001, Hartmut Holzgraefe wrote: Jouni Ahto wrote: Maybe it should be the time to find out what the current DTD actually is, and what it allows us to do? very good point! (i was always refereing to the book which is for V3.1.x AFAIR) Besides, even if there's a clear need to change something, there's always the possibility of getting it accepted in the official version. See http://www.docbook.org/rfe/index.html http://sourceforge.net/tracker/?atid=384107group_id=21935func=browse -- Jouni
[PHP-DOC] cvs: phpdoc / configure.in
jah Fri Oct 5 18:31:32 2001 EDT Modified files: /phpdoc configure.in Log: ... accidentally saw the right coding somewhere ... Index: phpdoc/configure.in diff -u phpdoc/configure.in:1.75 phpdoc/configure.in:1.76 --- phpdoc/configure.in:1.75Sun Aug 26 08:42:35 2001 +++ phpdoc/configure.in Fri Oct 5 18:31:32 2001 @@ -1,4 +1,4 @@ -dnl $Id: configure.in,v 1.75 2001/08/26 12:42:35 jah Exp $ +dnl $Id: configure.in,v 1.76 2001/10/05 22:31:32 jah Exp $ AC_INIT(global.ent) @@ -334,7 +334,7 @@ ISO-8859-9) JADE=SP_ENCODING=ISO-8859-9 $JADEPATH NSGMLS=SP_ENCODING=ISO-8859-9 $NSGMLSCMD -# HTMLHELP_ENCODING=windows- +HTMLHELP_ENCODING=windows-1254 ;; *) JADE=$JADEPATH
[PHP-DOC] Re: i hate tex.
Jim Winstead wrote: if anyone can provide notes on how to increase the string limit for jadetex on a debian box, it would be much appreciated. once again, i've spent way longer than it should take trying to get the limit to increase to no avail. (similarly, if anyone else has run across openjade 1.4devel barfing on the phpdoc stuff because of the pdflevels.dsl stuff, clues would be appreciated.) I'll try to solve this problem next weekend. -- Jouni
Re: [PHP-DOC] install.xml en
On Thu, 4 Oct 2001, Hojtsy Gabor wrote: It would be great then if someone could knowck up a script which auto-generated the install.txt file from the install.xml one. Actually there is a txt downloadable version of the manual, so the install.txt file can be cropped from that file. Goba It would still be nice if that could be automatic - otherwise it's liekly to be forgotten when building a new release. OK, I'll see what I can do... May I suppose adding a new target to Makefile? make install.txt... will need some auxiliary files too, but should be anyway quite easy. -- Jouni
[PHP-DOC] Re: bz2 pdf only
Hojtsy Gabor wrote: Hi! Is it intended that there is only a bz2 compressed version available from the PDF version, and the zip and tar.gz columns are empty? I looked at the distributions/manual dir, and only the bz2 files are there, so it is not a problem of phpweb I assume. http://www.php.net/download-docs.php Strange. Did someone remove the other versions? I don't remember doing it myself. I think someone made a bug report last week about the zip and tar.gz versions being somehow corrupted. Maybe they really were. Anyway, the new versions will be there within 24 hours. -- Jouni
Re: [PHP-DOC] Re: phpdoc /de Translators /de/functions fdf.xml recode.xml satellite.xml wddx.xml zip.xml /en/functions satellite.xml wddx.xml zip.xml
On Mon, 17 Sep 2001, Hojtsy Gabor wrote: yet another reason for putting each translation into a CVS module of its own Indeed, what about your not-so-recent-anymore proposals for changing the set-up of translations? IIRC, people were enthousiast about it... What's thet status of it again? We can hear more about this at the PHPConf in Frakfurt. :)) There will be a session named The PHP Manual and beyond, if I remember correctly... Then there will be some live discussion about the subject with the people there. It would be interesting to hear something about Hartmuts thoughts, if they are something not already discussed on this list. There's a *lot* of bigger probability them being accepted as-is if we know something beforehand. And yes, I'm too lazy to browse through mail archives, unless someone clearly says RTFMLA. Hope I can be there in Frankfurt. Although, doesn't seem very probable. Have to save some money. Working like hell with my current project hoping I can get it finished. Stock exchange software seemed like a good idea 9 months ago. Doesn't seem so good now, at least in Finland. Possibbly unemployed within the next 3 months, like 30-40% of dealers. Hints about new possibilities would be appreciated. CV available at request. -- Jouni PS: Sorry for being a bit off-topic.
Re: [PHP-DOC] Finnish translation..(was: Re: [PHP-DOC] Revisioncheck, now working)
On Sun, 2 Sep 2001, Jani Taskinen wrote: On Sun, 2 Sep 2001, Jouni Ahto wrote: because he finds the exactly same things extremely useful. And if I would start a Finnish translation, I too would find them useful, so I side with Would you? :) Someone asked for CVS account for translating the manual to finnish some time ago. He didn't get the account I think.. A pity. Maybe he sent an example of his work and nobody in the group did understand a word about it, which in itself would have been a good reason to give that account... I could help a little on translating but I don't wanna do that all the time. :) Same thing. Not enough time. -- Jouni
[PHP-DOC] cvs: phpdoc / Makefile.in
jah Sun Sep 2 09:16:42 2001 EDT Modified files: /phpdoc Makefile.in Log: - Added -wno-idref option to jade arguments, so the manuals will be generated even if the are missing IDs. - New target 'test_man_gen' that checks if its possible to generate the manual. - No changes to target 'test'. It still complains about all errors. Index: phpdoc/Makefile.in diff -u phpdoc/Makefile.in:1.63 phpdoc/Makefile.in:1.64 --- phpdoc/Makefile.in:1.63 Sun Aug 26 08:42:35 2001 +++ phpdoc/Makefile.in Sun Sep 2 09:16:42 2001 @@ -17,14 +17,14 @@ # # -# $Id: Makefile.in,v 1.63 2001/08/26 12:42:35 jah Exp $ +# $Id: Makefile.in,v 1.64 2001/09/02 13:16:42 jah Exp $ # VPATH=@srcdir@ srcdir=@srcdir@ PHP_SOURCE=@PHP_SOURCE@ LANG=@LANG@ -JADE=@JADE@ +JADE=@JADE@ -wno-idref NSGMLS=@NSGMLS@ CATALOG=@CATALOG@ @@ -198,9 +198,13 @@ .ps.pdf: ps2pdf -p $@ $ +# test all possible errors test: manual.xml $(NSGMLS) -i lang-$(LANG) -s $(srcdir)/phpdocxml.dcl $ +# ignore missing IDs and check if the manual can be generated anyway +test_man_gen: manual.xml + $(NSGMLS) -wno-idref -i lang-$(LANG) -s $(srcdir)/phpdocxml.dcl $ clean: rm -rf html php rm -f manual.txt [a-z]*.html manual.rtf manual.info
Re: [PHP-DOC] Revision check, now working
On Sun, 2 Sep 2001, Egon Schmid wrote: From: Hojtsy Gabor Hope this helps to start a discussion about the usefullness of this revision comment syntax... It may be working in the hu tree, there is only one maintainer :) This would not work in the German manual, because we have many maintainers and not every maintainer is active. So the only solution to this dilemma is, every translator have to lookup the changes (cvs.php.net) in the en tree back to the time the translation was modified. I see a picture forming here. I think I remember at least Jeroen, Derick and Damien strongly supporting Gobas idea. And all these translations are maintained by a very small team, in Damiens case really just one. So it seems that what works for and helps one translation team may be completely useless for another. Although I think this could apply also to different persons within a team. I know that Egon won't change his mind, because he finds revision numbers and comments totally useless. I also know that Goba won't change his mind, because he finds the exactly same things extremely useful. And if I would start a Finnish translation, I too would find them useful, so I side with Goba in this. Could we try to come to a solution that would let anyone to work the way the find the easiest? So, my two points: - Are the revision numbers and comment actually harmful some way? I don't think so. - Are these different ways of working mutually exclusive? At least they shouldn't be. That revcheck script could even be used to update the existing entries and create new ones in Translators file based on the information found in comments (unless it already does it...). Let's find a way that allows those who want to use revision comments to do it, but doesn't force it on those ones who think it to be totally useless. I say it again, revision numbers and comments are useless for every translation. All information you need is in http://cvs.php.net/ -- phpdoc --[en|de|hu ...]. There have been discussions to split every file in files which contain only one function description. But if we can do this we should reorganize the function reference first. The next days Hartmut will be back. The Linux Beer Hike 2001 in Belgium is over. I'm actually trying to write the first draft of the new layout now. I hope this discussion won't get so heated that it takes all my time... -- Jouni
Re: [PHP-DOC] Revision check, now working
On Sun, 2 Sep 2001, Hojtsy Gabor wrote: As I wrote down in my last long letter (titled: Re: [PHP-DOC] Revision longer example), we can think of the Revision comments as a splitup of translators and the script generated revheck.html as a HTML version of Translators with much extra stuff in it. Yep, I received that long letter after writing my response. Very clear explanation of the system. So this is just a renewal of the current system we have with some extra convinient features added. As I heard, we can make the revcheck.php script run on every commit, so the table can be autogenerated on every commit, and there would be no need to run it manually in most of the cases. Otherwise a good idea, but that would be also forcing everyone to the new system... would it be OK if we just require the people using revision comments system to also run a script that updates Translators too and commit both ones? Besides, I think that over the time most people just switch to use revision comments, because the idea really is a good one, and this problem slowly fades away. So, if we at some time in the future realize that over 90% commits are using revision tags, we can come to the conclusion that the revision comments system has won. Pure survival-of-the-fittest game. -- Jouni
Re: [PHP-DOC] Revision check, now working
On Sun, 2 Sep 2001, Hojtsy Gabor wrote: If you think there will be too much extra processor time, the script will take on the server, doing nothing, because the commit changes no Revision number, we can introduce a flag in CVS commit messages, so eg: No, I was just thinking about a scenario where someone who doesn't use revision comments commits both a new version of a file and updates Translators too (we should keep that one too, it too has useful purpose), and somehow through a strange interaction of running scripts on the server and the order of files committed, Translators gets changed back or there comes CVS conflicts with files that are edited both manually and by a script, or something. But I really didn't think about it more than 5 seconds, so there's a very strong possibility that what I'm saying is just pure bullshit and doesn't need any more discussion, at least for now. Anyway, a flag in commit messages would be a working solution to a problem that I'm not sure even exists :) -- Jouni
Re: [PHP-DOC] RFC: Re-organizing function reference part
On Sun, 2 Sep 2001, Hojtsy Gabor wrote: What do you think about these additional groups? Variables, types and function handling Array Class-object Function handling Variable Session handling Miscellaneous: Apache-specific Error handling and logging GNU readline PHP options information Program execution Printer Semaphore and shared memory Shared memory Fine. I was just too lazy to invent them myself :) Commenting the categories list, I don't think that categories, with only one item should be opened (eg. Search or URL or Data Exchange). Yes, under Miscellaneous, unless some other module too gets moved under those categories. -- Jouni
Re: [PHP-DOC] RFC: Re-organizing function reference part
On Sun, 2 Sep 2001, Jeroen van Wolffelaar wrote: I would merge string/character and Variables,types and function handling, and name it: basic functions, since they are very general-purpose, do NOT have external depencies (like mysql, etc), and are quite close to the language. Error-handling, program execution are also good candidates for basic functions, along with probably others? That's quite a relevant way too to categorize sections. My problem is that I actually haven't any kind of opinion, I could argue for both alternatives... I might go to a local bookstore next week and check some PHP books from different publishers. If there's some common categories under which some function groups seem to always fall, it could be because publishers may have done some research on how to present information the most clear way. -- Jouni
Re: [PHP-DOC] PHP version on function docs
On Sat, 1 Sep 2001, Marco Cucinato wrote: Since the PHP version numbers related to every function (/version.xml) are applied to the doc every time they are generated, the old docs are not updated: Look at the array_walk function over the different translations. EN: (PHP 3= 3.0.3, PHP 4 = 4.0b1) CZ: (PHP 3= 3.0.3, PHP 4 = 4.0b1) FR: (PHP 3= 3.0.3, PHP 4 = 4.0b1) but ES: (PHP 3= 3.0.3, PHP 4 ) because it was last updated on 2001/05/20, and version.xml was changed on 2001/06/25. If the docs were always reprocessed, the version numbers would be homogeneous. Seems that the spanish version isn't recreated automatically due to a few errors in it. Mainly some references in the non-translated files (our documentation generation system automatically substitutes the english version for a non-translated one) to IDs in another file that exist in the latest english version, but not yet added to a translated version. I'd like to propose a small change in Makefile.in: - JADE=@JADE@ + JADE=@JADE@ -wno-idref NSGMLS=@NSGMLS@ This way, the documentation will be generated even if parts of the translation are a bit old and don't yet have those IDs needed, but 'make test' still catches the errors. -- Jouni
[PHP-DOC] cvs: phpdoc /hu/functions image.xml
jah Sat Sep 1 19:49:36 2001 EDT
Modified files:
/phpdoc/hu/functionsimage.xml
Log:
Fixed tags.
Index: phpdoc/hu/functions/image.xml
diff -u phpdoc/hu/functions/image.xml:1.9 phpdoc/hu/functions/image.xml:1.10
--- phpdoc/hu/functions/image.xml:1.9 Sat Sep 1 16:22:05 2001
+++ phpdoc/hu/functions/image.xml Sat Sep 1 19:49:36 2001
@@ -919,8 +919,10 @@
/para
para
note
+ para
Ha nem bal felsõ és jobb alsó koordinátákat adsz meg, akkor lehal a
program, és a képbõl semmit sem fogsz látni!!![angol doksiba!]
+ /para
/note
/para
/refsect1
@@ -1109,7 +,7 @@
kerül. Ha szeretnéd megadni a kép minõségét akkor, amikor a képet a
kimenetre szeretnéd küldeni, akkor a kép nevének üres karakterláncot ('')
adj meg! Ha egy image/jpg értékû content-type fejlécet írsz ki a
- functionheader/function függvénnyel, akkor a acronymJPEG/acrony
+ functionheader/function függvénnyel, akkor a acronymJPEG/acronym
típusú kép közvetlenül a kimenetre küldhetõ.
note
para
Re: [PHP-DOC] PHP version on function docs
On 2 Sep 2001 [EMAIL PROTECTED] wrote: Jouni Ahto [EMAIL PROTECTED] wrote: This way, the documentation will be generated even if parts of the translation are a bit old and don't yet have those IDs needed, but 'make test' still catches the errors. actually, the manual generation does a make test before making things for real, so that change alone won't help. Oh, I see. Any chance of of slightly changing it, for example adding target test_man_gen to the Makefile? Unlike other errors, like incorrect XML tags etc., incorrect IDs are somewhat acceptable (at least to me). The net result is just a link not being created. And it's just plain impossible that all the translations would be really up-to-date all the time. -- Jouni
[PHP-DOC] cvs: phpdoc /tr language-snippets.ent /tr/faq general.xml
jah Sun Aug 26 07:52:47 2001 EDT Modified files: /phpdoc/tr language-snippets.ent /phpdoc/tr/faq general.xml Log: Fixed problems 'make test' complained about (so I can found what the next ones are, especially concerning PDF version...). Index: phpdoc/tr/language-snippets.ent diff -u phpdoc/tr/language-snippets.ent:1.2 phpdoc/tr/language-snippets.ent:1.3 --- phpdoc/tr/language-snippets.ent:1.2 Fri Aug 10 17:40:19 2001 +++ phpdoc/tr/language-snippets.ent Sun Aug 26 07:52:46 2001 @@ -1,5 +1,5 @@ -!ENTITY warn.experimental 'warningsimparaBu modül emphasisDENEYSELDYacute;R/emphasis. Bunun anlamyacute;, burada listenen fonksiyonlar, fonksiyon isimleri, kyacute;saca burada yazyacute;lan HER THORN;EY PHP'nin ilerki sürümlerinde UYARI YAPILMAKSIZIN DEETH;Yacute;THORN;TYacute;RYacute;LEBYacute;LYacute;R. Dikkatli olun, ve bu modülü aldyacute;eth;yacute;nyacute;z riski bilerek kullanyacute;n./simpara/warning' -!ENTITY warn.experimental.func 'warningsimparaBu modül emphasisDENEYSELDYacute;R/emphasis. Bunun anlamyacute;, burada listenen fonksiyonlar, fonksiyon isimleri, kyacute;saca burada yazyacute;lan HER THORN;EY PHP'nin ilerki sürümlerinde UYARI YAPILMAKSIZIN DEETH;Yacute;THORN;TYacute;RYacute;LEBYacute;LYacute;R. Dikkatli olun, ve bu modülü aldyacute;eth;yacute;nyacute;z riski bilerek kullanyacute;n./simpara/warning' +!ENTITY warn.experimental 'warningsimparaBu modül +emphasisDENEYSELDYacute;R/emphasis. Bunun anlamyacute;, burada listenen +fonksiyonlar, fonksiyon isimleri, kyacute;saca burada yazyacute;lan HER THORN;EY +PHPquot;nin ilerki sürümlerinde UYARI YAPILMAKSIZIN +DEETH;Yacute;THORN;TYacute;RYacute;LEBYacute;LYacute;R. Dikkatli olun, ve bu +modülü aldyacute;eth;yacute;nyacute;z riski bilerek +kullanyacute;n./simpara/warning' +!ENTITY warn.experimental.func 'warningsimparaBu modül +emphasisDENEYSELDYacute;R/emphasis. Bunun anlamyacute;, burada listenen +fonksiyonlar, fonksiyon isimleri, kyacute;saca burada yazyacute;lan HER THORN;EY +PHPquot;nin ilerki sürümlerinde UYARI YAPILMAKSIZIN +DEETH;Yacute;THORN;TYacute;RYacute;LEBYacute;LYacute;R. Dikkatli olun, ve bu +modülü aldyacute;eth;yacute;nyacute;z riski bilerek +kullanyacute;n./simpara/warning' !ENTITY tip.ob-capture 'tipsimpara Normalde betiklerin ürettieth;i bütün çyacute;ktyacute;lar direk olarak tarayyacute;cyacute;ya gönderilir. link linkend=ref.outcontrolçyacute;ktyacute;-kontrol fonksiyonlaryacute;/link kullanyacute;larak çyacute;ktyacute; içerieth;inin farklyacute; bir deeth;ere kaydedilmesi mümkündür - örneeth;in typestring/type tipinde bir deeth;ere atabilirsiniz./simpara/tip' @@ -15,11 +15,11 @@ !ENTITY note.sm.disabled 'notesimparasm.disabled;/simpara/note' !ENTITY note.sm.uidcheck 'notesimparalink linkend=features.safe-modesafe-mode/link etkin oldueth;unda, PHP çalyacute;thorn;tyacute;rdyacute;eth;yacute;nyacute;z betieth;in -ithorn;lem yaptyacute;eth;yacute;nyacute;z dosya(lar)/dizin(ler) ile aynyacute; UID'e sahip olup olmadyacute;eth;yacute;nyacute; kontrol eder. +ithorn;lem yaptyacute;eth;yacute;nyacute;z dosya(lar)/dizin(ler) ile aynyacute; +UIDquot;e sahip olup olmadyacute;eth;yacute;nyacute; kontrol eder. /simpara/note' !ENTITY note.sm.uidcheck.dir 'notesimparalink linkend=features.safe-modeSafe-mode/link etkin oldueth;unda, PHP çalyacute;thorn;tyacute;rdyacute;eth;yacute;nyacute;z betieth;in -ithorn;lem yaptyacute;eth;yacute;nyacute;z dosya(lar)/dizin(ler) ile aynyacute; UID'e sahip olup olmadyacute;eth;yacute;nyacute; kontrol eder. +ithorn;lem yaptyacute;eth;yacute;nyacute;z dosya(lar)/dizin(ler) ile aynyacute; +UIDquot;e sahip olup olmadyacute;eth;yacute;nyacute; kontrol eder. /simpara/note' !-- Common pieces in features/safe-mode.xml Index: phpdoc/tr/faq/general.xml diff -u phpdoc/tr/faq/general.xml:1.1 phpdoc/tr/faq/general.xml:1.2 --- phpdoc/tr/faq/general.xml:1.1 Fri Aug 10 17:12:42 2001 +++ phpdoc/tr/faq/general.xml Sun Aug 26 07:52:46 2001 @@ -1,4 +1,4 @@ -!-- $Revision: 1.1 $ -- +!-- $Revision: 1.2 $ -- chapter id=faq.general titleGenel Bilgi/title titleabbrevGenel Bilgi/titleabbrev @@ -59,7 +59,7 @@ qandaentry id=faq.general.differences-34 question - paraPHP 3 ile PHP 4 arasyacute;ndaki farklar nelerdir? + paraPHP 3 ile PHP 4 arasyacute;ndaki farklar nelerdir?/para /question answer para
[PHP-DOC] cvs: phpdoc / Makefile.in configure.in
jah Sun Aug 26 08:42:35 2001 EDT Modified files: /phpdoc Makefile.in configure.in Log: Starting the move to the naming convention suggested by Goba. Now only for PDF version, let's wait for possible reactions before continuing. Index: phpdoc/Makefile.in diff -u phpdoc/Makefile.in:1.62 phpdoc/Makefile.in:1.63 --- phpdoc/Makefile.in:1.62 Sun Jul 8 00:03:56 2001 +++ phpdoc/Makefile.in Sun Aug 26 08:42:35 2001 @@ -17,7 +17,7 @@ # # -# $Id: Makefile.in,v 1.62 2001/07/08 04:03:56 jimw Exp $ +# $Id: Makefile.in,v 1.63 2001/08/26 12:42:35 jah Exp $ # VPATH=@srcdir@ @@ -75,7 +75,7 @@ rtf: manual.rtf dvi: manual.dvi ps: manual.ps -pdf: manual.pdf +pdf: @MANUAL@.pdf howto: howto.html FORCE: @@ -129,7 +129,7 @@ manual.txt.gz: manual.txt gzip -9 -c $ $@ -manual.pdf: manual.tex +@MANUAL@.pdf: manual.tex # a hack around bugs in jade/jadetex... mv manual.tex manual.tex.tmp sed -e '/HeadingText/,/endHeadPar/ s/_/\\137/g' manual.tex.tmp manual.tex @@ -138,7 +138,7 @@ -jadetex $ -jadetex $ -jadetex $ - dvipdfm -p @PDF_PAPER_TYPE@ manual.dvi + dvipdfm -o @MANUAL@.pdf -p @PDF_PAPER_TYPE@ manual.dvi html/index.html: manual.xml $(HTML_DEPS) @test -d html || mkdir html Index: phpdoc/configure.in diff -u phpdoc/configure.in:1.74 phpdoc/configure.in:1.75 --- phpdoc/configure.in:1.74Mon Aug 13 11:11:06 2001 +++ phpdoc/configure.in Sun Aug 26 08:42:35 2001 @@ -1,4 +1,4 @@ -dnl $Id: configure.in,v 1.74 2001/08/13 15:11:06 jkj Exp $ +dnl $Id: configure.in,v 1.75 2001/08/26 12:42:35 jah Exp $ AC_INIT(global.ent) @@ -191,6 +191,9 @@ ]) AC_SUBST(LANG) AC_SUBST(LANGDIR) + +MANUAL=php_manual_$LANG +AC_SUBST(MANUAL) dnl localize paper size by language dnl (instead of using system-dependant default)
[PHP-DOC] RFC: Re-organizing function reference part
This topic has popped up a few times before on the list, and I think I've seen even bug report(s?) claiming that the current function reference part makes it hard to find information, because it has grown so big. But I don't remember that we would haver ever deciced either to do it or not do it... The main problem is that in DocBook, we can't splice an additional level between a part and reference. What I could come up with by reading DocBook reference is the following: part -- Function reference chapter -- General category of functions, ie. like Database functions section -- replaces reference, not allowed here, ie. like MySQL functions abstract -- replaces partintro, not allowed here refentry -- the original refentry text I did some testing, and this seems to work quite well, although there are of course some problems to solve first. Things that must be modified, *if* we come to an agreement that we reorganize the function reference: Can be done without any hurry before the change: - Modify the *.dsl files so that TOC is created the right way. Some small fixing with HTML version, a bit more with printable versions. I will volunteer, unless Hartmut explicitly requests to have the honour... - New subtitles must be agreed on and added to each language-defs.ent. - I guess that some scripts relating to the online HTML-manual should be fixed. Not sure though. - Probably more... Can be done only after the re-organization, and with great hurry, because the change will temporarily break a lot of things: - Change the tags, and within abstract, add para tags around notes and warnings and change simparas to paras, because the DTD requires this. - Probably more... So, if this will ever happen, the change should be planned carefully and slowly, make sure that we've got everything ready, and all the translators should be aware of what's going on and can make a few hours available to fix broken things within a day or two after the change. Which should happen on a day commonly agreed upon, preferable at least a week before. Comments? -- Jouni
Re: [PHP-DOC] RFC: Re-organizing function reference part
On Sun, 26 Aug 2001, Egon Schmid wrote: It would be nice, if someone could make a first draft about the names of new chapters and which sections could be within sections. Something very near to the list of bug types bugs.php.net. I think there actually was a draft some time ago, but I'll have to go through the mail-archives. I could only guess, but I think, Hartmut is at The Linuxbierwanderung (Linux Beer Hike) and this hike ends on 09/01/2001. He'll have time to part in this discussion later. As the change is quite big and needs cooperation from so many people, I think we should proceed quite slowly and think everything really through. I'm thinking something like the last weekend of September for a possible date for this change. -- Jouni
Re: [PHP-DOC] RFC: Re-organizing function reference part
On Sun, 26 Aug 2001, Hojtsy Gabor wrote: - New subtitles must be agreed on and added to each language-defs.ent. This is what needs to be the same for the bug system. So if it is not right, we should collect the functions and make a new category system, and start to use it in the bug system and here too. Something very near to it, but not actually the same. I think we can safely leave out for example 'Website problems' and 'Reproducible crash' from the manual :) - I guess that some scripts relating to the online HTML-manual should be fixed. Not sure though. As long as we can get the file names stay the same, there is nothing [I can think of] to modify in the scripts at phpweb. The notes are binded by file names, so this is why the file names are important for us. At least the left part listing links to different parts Function reference in the online manual should be re-organized the same way. Erm, if we start to change things in a way like that, we can also start paralelly on proofing the split up the function reference by functions into files plan. This was a great plan IMHO, and [if we can agree in both cases] we should make the two changes the same time, instead of two separate repository-wide changes. Yes, let's wait for Hartmut to come back from hiking and drinking beer. If we do these things at the same time, it should be possible to declare maybe a 24-36 hours time when commits are not posted to the list. The patches would be really mega-sized and this seems be a great inconvenience to some of the people on this list. -- Jouni
[PHP-DOC] PDF updates
New versions should be available within a few hours, for those languages that compiled: cs, en, fr, it nl. If your language is missing from the list and you want the update too, please make sure it passes 'make test' before 17:00 GMT. I'm a bit in hurry today, haven't time to fix anything, and leaving the country for a few days very early tomorrow. Note that the copyright notice has somehow creeped to the first page too, and there could be some other surprises too, although I don't think anything critical. Probably caused by switching to use docbook-dsssl 1.72, but I didn't have time to investigate :( -- Jouni
[PHP-DOC] Re: FOP problems :)
On Wed, 8 Aug 2001, Hojtsy Gabor wrote:
Hi!
I try to test that XML-PDF generation but get the folowing error:
Exception in thread main java.lang.NoClassDefFoundError:
org/apache/tools/ant/Main
What do I need to install to make this class be defined???
You shouldn't need ant for running FOP, it's just one of the tools used if
you actually compile FOP yourself. At least I think so, because I got FOP
working without adding ant to my classpath.
This probably won't help much, because you are running Windows, but I'm
attaching the script I use for running FOP anyway. Maybe you can get at
least some ideas on how to make it work on Windows.
-- Jouni
#!/bin/sh
FOP_HOME=/home/staff/jah/xslt/Fop-0.19.0-CVS
java -mx312m -cp
${FOP_HOME}/fop.jar:${FOP_HOME}/lib/batik.jar:${FOP_HOME}/lib/xalan-2.0.0.jar:${FOP_HOME}/lib/xerces-1.2.3.jar:${FOP_HOME}/lib/jimi-1.0.jar
org.apache.fop.apps.Fop $@
Re: [PHP-DOC] Re: PDF with internal links
On Sun, 5 Aug 2001, Hojtsy Gabor wrote: And you can read README.xsl in the phpdoc root to get some info how you can build the docs using XSLT. Did it. Somehow I have missed realizing that there's already so much work done... I'll start playing with this. Don't expect immediate results. -- Jouni
[PHP-DOC] cvs: phpdoc / README.xsl
jah Sun Aug 5 04:47:50 2001 EDT Modified files: /phpdoc README.xsl Log: Found out that saxons' homepage has moved. Index: phpdoc/README.xsl diff -u phpdoc/README.xsl:1.2 phpdoc/README.xsl:1.3 --- phpdoc/README.xsl:1.2 Mon Feb 19 06:52:11 2001 +++ phpdoc/README.xsl Sun Aug 5 04:47:50 2001 @@ -11,7 +11,7 @@ XSLT processors: XT: http://www.jclark.com/xml/xt.html - Saxon: http://users.iclway.co.uk/mhkay/saxon/ + Saxon: http://saxon.sourceforge.net/ Xalan: http://xml.apache.org/xalan/ XSL DocBook Stylesheets: @@ -87,4 +87,4 @@ Jirka Kosek [EMAIL PROTECTED] -Last modified $Date: 2001/02/19 11:52:11 $ +Last modified $Date: 2001/08/05 08:47:50 $
[PHP-DOC] cvs: phpdoc / README.xsl
jah Sun Aug 5 05:24:09 2001 EDT Modified files: /phpdoc README.xsl Log: Another changed link... Index: phpdoc/README.xsl diff -u phpdoc/README.xsl:1.3 phpdoc/README.xsl:1.4 --- phpdoc/README.xsl:1.3 Sun Aug 5 04:47:50 2001 +++ phpdoc/README.xsl Sun Aug 5 05:24:09 2001 @@ -12,7 +12,7 @@ XSLT processors: XT: http://www.jclark.com/xml/xt.html Saxon: http://saxon.sourceforge.net/ - Xalan: http://xml.apache.org/xalan/ + Xalan: http://xml.apache.org/xalan-j/ XSL DocBook Stylesheets: http://www.nwalsh.com/docbook/xsl/index.html @@ -87,4 +87,4 @@ Jirka Kosek [EMAIL PROTECTED] -Last modified $Date: 2001/08/05 08:47:50 $ +Last modified $Date: 2001/08/05 09:24:09 $
[PHP-DOC] cvs: phpdoc /en bookinfo.xml /en/chapters security.xml /en/faq languages.xml obtaining.xml using.xml /en/functions com.xml info.xml mbstring.xml ming.xml sockets.xml strings.xml xslt.xml /en/language variables.xml
jah Sun Aug 5 06:51:48 2001 EDT
Modified files:
/phpdoc/en bookinfo.xml
/phpdoc/en/chapters security.xml
/phpdoc/en/faq languages.xml obtaining.xml using.xml
/phpdoc/en/functionscom.xml info.xml mbstring.xml ming.xml
sockets.xml strings.xml xslt.xml
/phpdoc/en/language variables.xml
Log:
Fixed a lot of things fop doesn't think to be legal.
Index: phpdoc/en/bookinfo.xml
diff -u phpdoc/en/bookinfo.xml:1.12 phpdoc/en/bookinfo.xml:1.13
--- phpdoc/en/bookinfo.xml:1.12 Thu Aug 2 13:36:36 2001
+++ phpdoc/en/bookinfo.xml Sun Aug 5 06:51:43 2001
@@ -1,4 +1,4 @@
-!-- $Revision: 1.12 $ --
+!-- $Revision: 1.13 $ --
bookinfo id=bookinfo
authorgroup id=authors
@@ -66,7 +66,7 @@
simpara
This manual is copy; Copyright 1997, 1998, 1999, 2000, 2001 by
the PHP Documentation Group. The members of this group are listed
-link linkend=authorson the front page of this manual/link.
+on the front page of this manual.
/simpara
simpara
This manual can be redistributed under the terms of the GNU
Index: phpdoc/en/chapters/security.xml
diff -u phpdoc/en/chapters/security.xml:1.22 phpdoc/en/chapters/security.xml:1.23
--- phpdoc/en/chapters/security.xml:1.22Fri Aug 3 03:12:58 2001
+++ phpdoc/en/chapters/security.xml Sun Aug 5 06:51:44 2001
@@ -1,4 +1,4 @@
-!-- $Revision: 1.22 $ --
+!-- $Revision: 1.23 $ --
chapter id=security
titleSecurity/title
@@ -590,8 +590,8 @@
titleDetecting simple variable poisoning/title
programlisting role=php
lt;?php
-if ($HTTP_COOKIE_VARS['username']
-!$HTTP_POST_VARS['username']
+if ($HTTP_COOKIE_VARS['username'] amp;amp;
+!$HTTP_POST_VARS['username'] amp;amp;
!$HTTP_GET_VARS['username'] ) {
// Perform other checks to validate the user name...
$good_login = 1;
Index: phpdoc/en/faq/languages.xml
diff -u phpdoc/en/faq/languages.xml:1.3 phpdoc/en/faq/languages.xml:1.4
--- phpdoc/en/faq/languages.xml:1.3 Thu Aug 2 13:36:43 2001
+++ phpdoc/en/faq/languages.xml Sun Aug 5 06:51:44 2001
@@ -1,4 +1,4 @@
-!-- $Revision: 1.3 $ --
+!-- $Revision: 1.4 $ --
chapter id=faq.languages
titlePHP and other languages/title
titleabbrevPHP and other languages/titleabbrev
@@ -71,7 +71,7 @@
para
A great summary by Michael J Sheldon on this topic has
been posted to the PHP mailing list. A copy can be found
- ulink url=faqurl.coldfusion.summaryhere/ulink.
+ ulink url=faqurl.coldfusion.summary;here/ulink.
/para
/answer
/qandaentry
Index: phpdoc/en/faq/obtaining.xml
diff -u phpdoc/en/faq/obtaining.xml:1.4 phpdoc/en/faq/obtaining.xml:1.5
--- phpdoc/en/faq/obtaining.xml:1.4 Thu Aug 2 13:36:43 2001
+++ phpdoc/en/faq/obtaining.xml Sun Aug 5 06:51:44 2001
@@ -1,4 +1,4 @@
-!-- $Revision: 1.4 $ --
+!-- $Revision: 1.5 $ --
chapter id=faq.obtaining
titleObtaining PHP/title
titleabbrevObtaining PHP/titleabbrev
@@ -88,88 +88,88 @@
/listitem
listitem
simpara
-ulink url=faqurl.snmpSNMP* (Unix): /ulink.
+ulink url=faqurl.snmp;SNMP* (Unix): /ulink.
/simpara
/listitem
listitem
simpara
-ulink url=faqurl.gdGD* (Unix/Win)/ulink.
+ulink url=faqurl.gd;GD* (Unix/Win)/ulink.
/simpara
/listitem
listitem
simpara
-ulink url=faqurl.msql.winmSQL* (Win)/ulink.
+ulink url=faqurl.msql.win;mSQL* (Win)/ulink.
/simpara
/listitem
listitem
simpara
-ulink url=faqurl.msql.unixmSQL* (Unix)/ulink.
+ulink url=faqurl.msql.unix;mSQL* (Unix)/ulink.
/simpara
/listitem
listitem
simpara
-ulink url=faqurl.mysqlMySQL* (Unix)/ulink.
+ulink url=faqurl.mysql;MySQL* (Unix)/ulink.
/simpara
/listitem
listitem
simpara
-ulink url=faqurl.imapIMAP* (Win/Unix)/ulink.
+ulink url=faqurl.imap;IMAP* (Win/Unix)/ulink.
/simpara
/listitem
listitem
simpara
-ulink url=faqurl.snmpSybase-CT* (Linux, libc5)/ulink :
+ulink url=faqurl.sybase;Sybase-CT* (Linux, libc5)/ulink :
Available locally.
/simpara
/listitem
listitem
simpara
-ulink url=faqurl.freetypeFreeType (libttf):/ulink.
+ulink url=faqurl.freetype;FreeType (libttf):/ulink.
/simpara
/listitem
listitem
simpara
-ulink url=faqurl.zlibZLib (Unix/Win32)/ulink.
+ulink url=faqurl.zlib;ZLib (Unix/Win32)/ulink.
/simpara
/listitem
listitem
simpara
-ulink url=faqurl.expatexpat XML parser (Unix/Win32)/ulink.
+ulink
Re: [PHP-DOC] Re: PDF with internal links
On Sun, 5 Aug 2001, Hojtsy Gabor wrote: Maybe Jirka Kosek can say something positive about the PDF version. He is involved closely in DocBook XSL stylesheets IMHO. Let's hope so. -- Jouni
Re: [PHP-DOC] Re: PDF with internal links
On Sun, 5 Aug 2001, Jirka Kosek wrote: The problem of generating PDFs with XSL stylesheet isn't in stylesheets but in FO processors. All current free implementations of XSL FO (PassiveTeX, FOP) have some serious limitations. IMHO for these days, it is better to use XSL for getting HTML and HTML Help output and stay with DSSSL for getting printed version. I think that in one year maturity of XSL FO processors will be better than Jade, but not for now. Ah, I'm reliefed. There's still quite a lot of time to learn XSL. If I have understood it right, you are somehow involved with the development of DocBook XSL and, if not directly, you at least follow the development of some FO processor. Please drop a note to this list when you think it would be the time to test and seriously consider switching the PDF generating tools. Unless, of course, you just do the switch yourself... I think you are one of the few (maybe the only one) who actually knows what he's speaking about when it comes to XSL. -- Jouni
Re: [PHP-DOC] Re: oh, those pdfs [and chms]
On Sat, 4 Aug 2001, Sascha Schumann wrote:
Jouni Ahto genererated the PDFs, and uploaded them to
rsync.php.net, but noone had some minutes, to give some
rights to Jouni, or just move the files to the webspace
to let it spread across mirrors, and be downloadable.
This is the first I personally hear that they are available.
Was not Derick supposed to take care of it? At least, I set
up his account on the server and waited for the created `chm´
directory to fill up (it is still empty as of today).
Anyway, I'll take care of the pdfs.
Thanks. There has been some problems with my account on rsync.php.net, and
I think Rasmus has just been too busy lately. See the message at the end.
Would someone please reset my password to something known and send it to
me? GPG public key id 8A6ED6B1 available at least from certserver.pgp.com.
-- Jouni
-- Forwarded message --
Date: Thu, 26 Jul 2001 20:25:52 +0300 (EEST)
From: Jouni Ahto [EMAIL PROTECTED]
To: Rasmus Lerdorf [EMAIL PROTECTED]
Subject: RE: [PHP-DOC] cvs: phpdoc /en preface.xml
On Thu, 26 Jul 2001, Rasmus Lerdorf wrote:
I have added you to the sudoers file on that machine.
Either I don't know how to create a correct md5-password (very possible, I
do understand almost nothing about crypting...), or then I don't know my
password on that machine.
The password I sent earlier was created (almost) with the following:
? print crypt('', '$1$*'); ?
-- Jouni
Re: [PHP-DOC] Re: oh, those pdfs [and chms]
On Sat, 4 Aug 2001, Sascha Schumann wrote: If the PDFs are generated and uploaded automatically, please coordinate with us to set up a proper cron-job which moves the files into the right place automatically. That's the plan, at least until the new toye is up and able to autogenerate PDFs. -- Jouni
Re: [PHP-DOC] Re: oh, those pdfs [and chms]
On Sat, 4 Aug 2001, Rasmus Lerdorf wrote: Cannot anybody realize, that we are stating that the PDFs are temporary unavailable, but this is the case for months now Sure Jouni Ahto genererated the PDFs, and uploaded them to rsync.php.net, but noone had some minutes, to give some rights to Jouni, or just move the files to the webspace to let it spread across mirrors, and be downloadable. Jouni has full sudo access on both rsync.php.net and www.php.net. It seems that some people on the lists have got the impression that the main developers of PHP and the people administering php.net servers don't care about documentation, especially the PDF version. That's 110% *not true*. The delays were caused by a slightly incorrect email-address in cvsusers (it was found out today), which has probably made many attempts to communicate fail with mail bouncing back. The situation is corrected now. Please re-adjust your attitudes accordingly. -- Jouni
Re: [PHP-DOC] cvs: phpdoc / global.ent
On Wed, 1 Aug 2001 [EMAIL PROTECTED] wrote: On Wed, Aug 01, 2001 at 09:41:48AM +0200, Hojtsy Gábor wrote: I talked about global.ent, not de/language-defs.ent. We have sometimes errors if someone makes a reference to the install chapter. If this chapter is not uptodate in this language, the manual building would fail. OK, I know what you said, but what is Jouni talking about I don't know :) If he doesn't have any beer he will come back. Yes, and unfortunately having a terrible hangover... What I meant (I guess I didn't express my thoughts quite coherently), is that I do somewhat agree with Goba about that entities relevant only to a specific language could go into that languages language-defs.ent. Note that I'm not saying they *should*, but it makes somewhat more sense to me anyway. And I was also hinting that Egon should translate those two snippets in de/language-defs.ent. Note that I'm not saying he *could*... :) -- Jouni
Re: [PHP-DOC] cvs: phpdoc / global.ent
Hojtsy Gábor wrote: I tried to understand this paragraph in connection with the DE language entities file. But nothing helped me to understand. These two new entities are not there for quite many years... Why are those guys are crazy? It's best if you don't even try to understand, that paragraph doesn't make much sense even to myself. -- Jouni
RE: [PHP-DOC] cvs: phpdoc / global.ent
On Tue, 31 Jul 2001, Hojtsy Gábor wrote:
If Damien use his French ENTITY's, there is nothing wrong to
put them into global.ent.
globals.ent should contain global entities, as the name suggest.
Language only entities should go IMHO to language-defs.ent
(see hu dir). We started faqurls.ent for the same reason. This
way you can find entities where they should be.
Goba
Language-only entities can (like any kind of errors) break the whole
documenting system. I'm not saying that all the translations should be the
same, and have exactly the same (link) entities. Actually, I think I'm
seconding Goba.
SO:
I'm not very sure what I'm writing about (had a few beers too much), but
it should be possible within the DSSSL / our configuration framework, to
just detect which version of a language specific *.ent should be used. I
mean after global.ent, overriding or adding something to it, according to
the needs of the translation team.
There is even a good example of this:
cat de/language-defs.ent
!ENTITY PHPManual PHP Handbuch
!ENTITY Date Datum:
!ENTITY GettingStarted Einführung
!ENTITY LanguageReference Sprachreferenz
!ENTITY Features Features
!ENTITY FunctionReference Funktionsreferenz
!ENTITY Appendixes Anhang
!ENTITY PEAR PEAR: the PHP Extension and Application
Repository
!ENTITY FAQ FAQ: Frequently Asked Questions
Egon, this is something we have already been using quite many years. Now,
please fix that file :-; (But then some crazy guys added that PEAR and
FAQ. What the hell do they think about, especially with PEAR, that's
somewhat recent. ('FAQ' is not recent, many of those questions finally
answered are years old)
Yeah, it's possible that I haven't got a slightest idea what I'm writing
about. Just ranting.
-- Jouni
[PHP-DOC] cvs: phpdoc / configure.in
jah Mon Jul 30 10:48:48 2001 EDT Modified files: /phpdoc configure.in Log: Preparing for the turkish translation (I saw that Serdar got his CVS account). Index: phpdoc/configure.in diff -u phpdoc/configure.in:1.70 phpdoc/configure.in:1.71 --- phpdoc/configure.in:1.70Mon Jul 16 03:45:28 2001 +++ phpdoc/configure.in Mon Jul 30 10:48:48 2001 @@ -1,4 +1,4 @@ -dnl $Id: configure.in,v 1.70 2001/07/16 07:45:28 perugini Exp $ +dnl $Id: configure.in,v 1.71 2001/07/30 14:48:48 jah Exp $ AC_INIT(global.ent) @@ -195,7 +195,7 @@ dnl localize paper size by language dnl (instead of using system-dependant default) case $LANG in - cs|de|hu|it|ja|ko|zh_hk) + cs|de|hu|it|ja|ko|tr|zh_hk) PAPER_TYPE=A4 PDF_PAPER_TYPE=a4 ;; @@ -264,6 +264,7 @@ ja|tw|ko) ENCODING=UTF-8;; zh_hk) ENCODING=big5;; cs|hu) ENCODING=ISO-8859-2;; + tr) ENCODING=ISO-8859-9 *) ENCODING=ISO-8859-1;; esac AC_SUBST(ENCODING) @@ -277,6 +278,7 @@ it) PALMDOCTITLE='Manuale PHP';; nl) PALMDOCTITLE='PHP Handleiding';; pt_BR) PALMDOCTITLE='Manual do PHP';; +# tr) PALMDOCTITLE=;; zh_hk) PALMDOCTITLE=PHP ¤â¥U;; *) PALMDOCTITLE='PHP Manual';; esac @@ -325,6 +327,11 @@ JADE=SP_ENCODING=ISO-8859-2 $JADEPATH NSGMLS=SP_ENCODING=ISO-8859-2 $NSGMLSCMD HTMLHELP_ENCODING=windows-1250 +;; + ISO-8859-9) +JADE=SP_ENCODING=ISO-8859-9 $JADEPATH +NSGMLS=SP_ENCODING=ISO-8859-9 $NSGMLSCMD +# HTMLHELP_ENCODING=windows- ;; *) JADE=$JADEPATH
Re: [PHP-DOC] Turkish Translation of Manual
On Sun, 29 Jul 2001, Hojtsy Gabor wrote: A question for manual maintainers; is it enough to get a CVS account for /phpdoc/tr and put our translations in them, or we must also work on Jade and Docbook/DSSSL to help make different versions of manual? You need to somewhat know Docbook XML to translate the pages correctly, and you also need the utilities on your own computer, because every contributor is advised to test his/her contributions, before comitting (with make test). This means you need a CVS chechkout of the phpdoc modules main directory, the en language directory, and your languages dir, and all the tools to process XML. Although the generation of different formats are automatic, so this is actually only needed for testing. The first thing to do is to make DocBook/DSSSL to support turkish. It doesn't yet. But it's not very hard to get that support in. It didn't support hungarian a year ago. It does now. The hungarian translation of PHP manual had something to do with it... Goba, let's help Serdar. -- Jouni
Re: [PHP-DOC] offer re - PDF unavailable
On Sat, 28 Jul 2001, Hojtsy Gabor wrote: Hi... i noticed that PDF editions of the PHP docs are temporarily unavailable. I dunno whether this is due to a no-interest in having PDF versions available or maybe just the sheer cost of a copy of Acrobat being the issue. Anyway, I got Acrobat 4.05 and 5 here, and my boss is quite happy for me to use it for non-work purposes (he belives that since we don't make extreme use of it, we can afford to 'share the wealth'). So, if a PDF edition of the manuals is still wanted, please let me know and i'll get on to it as soon as possible. Thanks for the offer. But we do not use Acrobat for PDF generation :) The PDFs are ready and on the way to be online on the site, and updated weekly. Please be patient for some days. Hmm. I guess that using Acrobat could cut down the size of PDF files a lot. Let's do some testing. Bookmarks and internal links in the doc *must* work. -- Jouni
[PHP-DOC] cvs: phpdoc / global.ent
jah Fri Jul 27 02:13:31 2001 EDT Modified files: /phpdoc global.ent Log: Not available on old site anymore. Index: phpdoc/global.ent diff -u phpdoc/global.ent:1.101 phpdoc/global.ent:1.102 --- phpdoc/global.ent:1.101 Thu Jul 26 14:04:11 2001 +++ phpdoc/global.ent Fri Jul 27 02:13:30 2001 @@ -1,6 +1,6 @@ !-- -*- SGML -*- - $Id: global.ent,v 1.101 2001/07/26 18:04:11 goba Exp $ + $Id: global.ent,v 1.102 2001/07/27 06:13:30 jah Exp $ Contains global macros for all the XML documents. @@ -144,7 +144,7 @@ !ENTITY url.swf http://reality.sgi.com/grafica/flash/; !ENTITY url.swf.test http://www.designmultimedia.com/swfphp/test.swf; !ENTITY url.sybase http://www.sybase.com/; -!ENTITY url.t1lib ftp://ftp.neuroinformatik.ruhr-uni-bochum.de/pub/software/t1lib/; +!ENTITY url.t1lib ftp://sunsite.unc.edu/pub/Linux/libs/graphics/; !ENTITY url.tenon http://www.tenon.com/products/webten/; !ENTITY url.tiff http://www.libtiff.org/; !ENTITY url.ucd-snmp http://ucd-snmp.ucdavis.edu/;
[PHP-DOC] PDF manual - about compression
As the PDF manuals should be coming back really soon now, I'm thinking about compressing them, because the file size is is quite big (approx. 11M per language). What do you think, should they be offered as .gz, .bz2 and .zip versions like the HTML version (in many files), or would .gz suffice? AFAIK some of the newer zip programs for Windows do handle .gz. But then, .bz2 compression is the best one. See directory listing. -- Jouni -rw-r--r--1 jah staff11073633 Jul 25 18:32 manual-de.pdf -rw-r--r--1 jah staff 3596586 Jul 25 21:08 manual-de.pdf.bz2 -rw-r--r--1 jah staff 3938446 Jul 25 21:06 manual-de.pdf.gz -rw-r--r--1 jah staff 3938572 Jul 25 21:12 manual-de.pdf.zip -rw-r--r--1 jah staff11938128 Jul 25 19:11 manual-en.pdf -rw-r--r--1 jah staff 3847560 Jul 25 21:08 manual-en.pdf.bz2 -rw-r--r--1 jah staff 4228765 Jul 25 21:06 manual-en.pdf.gz -rw-r--r--1 jah staff 4228891 Jul 25 21:12 manual-en.pdf.zip -rw-r--r--1 jah staff11001028 Jul 25 19:46 manual-it.pdf -rw-r--r--1 jah staff 3538368 Jul 25 21:09 manual-it.pdf.bz2 -rw-r--r--1 jah staff 3873942 Jul 25 21:06 manual-it.pdf.gz -rw-r--r--1 jah staff 3874068 Jul 25 21:12 manual-it.pdf.zip -rw-r--r--1 jah staff11874674 Jul 25 20:17 manual-nl.pdf -rw-r--r--1 jah staff 3840079 Jul 25 21:09 manual-nl.pdf.bz2 -rw-r--r--1 jah staff 4224977 Jul 25 21:07 manual-nl.pdf.gz -rw-r--r--1 jah staff 4225103 Jul 25 21:13 manual-nl.pdf.zip
[PHP-DOC] cvs: phpdoc /fr/functions math.xml
jah Wed Jul 25 16:26:56 2001 EDT Modified files: /phpdoc/fr/functionsmath.xml Log: Fixed last illegal chars. French version compiles now. Index: phpdoc/fr/functions/math.xml diff -u phpdoc/fr/functions/math.xml:1.11 phpdoc/fr/functions/math.xml:1.12 --- phpdoc/fr/functions/math.xml:1.11 Tue Jul 24 09:08:31 2001 +++ phpdoc/fr/functions/math.xmlWed Jul 25 16:26:56 2001 @@ -631,7 +631,7 @@ refentry id=function.log refnamediv refnameLog/refname - refpurposeLogarithme naturel (nprien)/refpurpose + refpurposeLogarithme naturel (neacute;peacute;rien)/refpurpose /refnamediv refsect1 titleDescription/title @@ -643,7 +643,7 @@ /funcsynopsis para functionlog/function retourne le logarithme naturel -(ou nprien) de parameterarg/parameter. +(ou neacute;peacute;rien) de parameterarg/parameter. /para /refsect1 /refentry
[PHP-DOC] cvs: phpdoc /cs/language constants.xml
jah Wed Jul 25 16:41:26 2001 EDT Modified files: /phpdoc/cs/language constants.xml Log: Added id so that it compiles again. Index: phpdoc/cs/language/constants.xml diff -u phpdoc/cs/language/constants.xml:1.4 phpdoc/cs/language/constants.xml:1.5 --- phpdoc/cs/language/constants.xml:1.4Sat Jul 7 18:14:33 2001 +++ phpdoc/cs/language/constants.xmlWed Jul 25 16:41:26 2001 @@ -9,7 +9,7 @@ nemohou pozdìji nabývat jiných hodnot. /simpara - para + para id=language.constants.predefined Pøeddefinované konstanty (dostupné v¾dy) jsou: variablelist
[PHP-DOC] cvs: phpdoc / faqurls.ent
jah Fri Jul 20 15:46:48 2001 EDT Modified files: /phpdoc faqurls.ent Log: Added missing entities, though mostly still empty :( Index: phpdoc/faqurls.ent diff -u phpdoc/faqurls.ent:1.5 phpdoc/faqurls.ent:1.6 --- phpdoc/faqurls.ent:1.5 Fri Jul 20 04:40:50 2001 +++ phpdoc/faqurls.ent Fri Jul 20 15:46:48 2001 @@ -1,13 +1,19 @@ !-- -*- SGML -*- - $Id: faqurls.ent,v 1.5 2001/07/20 08:40:50 dams Exp $ + $Id: faqurls.ent,v 1.6 2001/07/20 19:46:48 jah Exp $ Contains macros for all the XML documents within the FAQ. -- +!ENTITY faqurl.apache http://httpd.apache.org/; +!ENTITY faqurl.asp2php !ENTITY faqurl.aspell http://download.sourceforge.net/aspell/aspell-.29.1.tar.gz; +!ENTITY faqurl.bison !ENTITY faqurl.browscap http://www.cyscape.com/asp/browscap/; +!ENTITY faqurl.chilisoft http://www.chilisoft.com/; +!ENTITY faqurl.chilisoft.asp http://www.chilisoft.com/; +!ENTITY faqurl.coldfusion.summary !ENTITY faqurl.dmalloc http://www.dmalloc.com/; !ENTITY faqurl.expat http://www.jclark.com/xml/expat.html; !ENTITY faqurl.file.installation http://cvsweb.php.net/viewcvs.cgi/php3/INSTALL?rev=1.31; @@ -19,8 +25,11 @@ -- !ENTITY faqurl.freetype http://www.freetype.org/; !ENTITY faqurl.gd http://www.boutell.com/gd/#buildgd; +!ENTITY faqurl.halcyon +!ENTITY faqurl.iis !ENTITY faqurl.imap ftp://ftp.cac.washington.edu/imap/old/imap-4.5.tar.Z; !ENTITY faqurl.install http://www.webgenx.com/php/phpnes.php3; +!ENTITY faqurl.instantasp !ENTITY faqurl.ldap ftp://ftp.openldap.org/pub/openldap/openldap-stable.tgz; !ENTITY faqurl.ldap.free ftp://ftp.critical-angle.com/pub/cai/slapd/; !ENTITY faqurl.ldap.mt ftp://terminator.rs.itd.umich.edu/ldap/ldap-3.3.tar.Z; @@ -30,15 +39,18 @@ !ENTITY faqurl.msql.unix http://www.hughes.com.au/; !ENTITY faqurl.msql.win http://blnet.com/msqlpc/; !ENTITY faqurl.mysql http://www.mysql.com/; +!ENTITY faqurl.openasp !ENTITY faqurl.openlinksw http://www.openlinksw.com/; !ENTITY faqurl.pdflib http://www.pdflib.com/; !ENTITY faqurl.php http://www.php.net/; +!ENTITY faqurl.php.bugs http://bugs.php.net/; !ENTITY faqurl.php.cvs http://cvs.php.net/; !ENTITY faqurl.php.download http://www.php.net/downloads.php; !ENTITY faqurl.php.manual http://www.php.net/manual/; !ENTITY faqurl.php.manual.config.nt http://www.php.net/manual/config-apache-nt.html; !ENTITY faqurl.php.support http://www.php.net/support.php; !ENTITY faqurl.php.support.winbuild http://www.php.net/extra/win32build.zip; +!ENTITY faqurl.popup !ENTITY faqurl.readline ftp://prep.ai.mit.edu/pub/gnu/readline/; !ENTITY faqurl.sleepycat http://www.sleepycat.com/; !ENTITY faqurl.snmp http://www.ece.ucdavis.edu/ucd-snmp/;
[PHP-DOC] cvs: phpdoc /en/functions domxml.xml
jah Wed Jul 18 13:13:24 2001 EDT Modified files: /phpdoc/en/functionsdomxml.xml Log: Removed some stray chars... Index: phpdoc/en/functions/domxml.xml diff -u phpdoc/en/functions/domxml.xml:1.17 phpdoc/en/functions/domxml.xml:1.18 --- phpdoc/en/functions/domxml.xml:1.17 Wed Jul 18 08:57:28 2001 +++ phpdoc/en/functions/domxml.xml Wed Jul 18 13:13:24 2001 @@ -1,4 +1,4 @@ -?gt; reference id=ref.domxml +reference id=ref.domxml titleDOM XML functions/title titleabbrevDOM XML/titleabbrev
Re: [PHP-DOC] Re: pdf manuals
On Sun, 8 Jul 2001, Jim Winstead wrote: i haven't been able to set up the pdf generation on the current rsync.php.net, because it is running an older version of redhat, and all the jvm's i tried to install wanted a newer glibc. (the pdf generation was using saxon and passivetex, right? it would be interesting to see if libxslt is up to the task, since it is reportedly quite fast.) It was actually jade, tex and dvipdfm. On Sun, Jul 08, 2001 at 11:59:40AM +0200, Hojtsy Gabor wrote: Is there anybody interested in seting up the PDF generation framework again? This question was askes by Rasmus some days ago, but nobody seemed to answer. I was on holiday :) If the old setup is ok, I could find some time the next weekend. Anything java-based, and I'm out of the game. -- Jouni
[PHP-DOC] cvs: phpdoc /it/functions oci8.xml
jah Sun Apr 1 09:44:57 2001 EDT Modified files: /phpdoc/it/functionsoci8.xml Log: Fixed incorrect closing tag. Index: phpdoc/it/functions/oci8.xml diff -u phpdoc/it/functions/oci8.xml:1.6 phpdoc/it/functions/oci8.xml:1.7 --- phpdoc/it/functions/oci8.xml:1.6Mon Mar 26 08:10:54 2001 +++ phpdoc/it/functions/oci8.xmlSun Apr 1 09:44:57 2001 @@ -1198,7 +1198,7 @@ functionOCIColumnType/function restituisce il tipo del campo corrispondente alla posizione (1 = primo campo) specificata. - /simpara + /para para example titleOCIColumnType/title
Re: [PHP-DOC] cvs: phpdoc /fr/functions session.xml
On Mon, 19 Mar 2001, Egon Schmid wrote: eschmid Mon Mar 19 09:18:07 2001 EDT Modified files: /phpdoc/fr/functions session.xml Log: Added two missing paras. In general, should we be using paranotepara.../para/note/para, or the simpler form notepara.../para/note? Both are valid. -- Jouni Index: phpdoc/fr/functions/session.xml diff -u phpdoc/fr/functions/session.xml:1.10 phpdoc/fr/functions/session.xml:1.11 --- phpdoc/fr/functions/session.xml:1.10 Mon Mar 19 09:01:15 2001 +++ phpdoc/fr/functions/session.xml Mon Mar 19 09:18:06 2001 @@ -126,15 +126,17 @@ literalsession_name=session_id/literal, ou bien, c'est une chaicirc;ne vide. /para -para - note + para +note + para La fonction qui geacute;rera l'eacute;criture des donneacute;es ne sera appeleacute;e qu'une fois le script aura envoyeacute; toutes ses donneacute;es. Ainsi, les affichages tenteacute;s par cette fonction ne pourront jamais ecirc;tre recus par le navigateur. Si un tel affichage est neacute;cessaire, il est conseilleacute; d'eacute;crire les debugs dans un fichier. - /note -/para + /para +/note + /para para L'exemple suivant montre comment enregistrer une variable, et comment relier correctement des pages avec SID. @@ -161,11 +163,13 @@ literal--enable-trans-sid/literal a eacute;teacute; utiliseacute; pour compiler PHP. /para -para + para note + para Les URL absolues sont consideacute;reacute;es comme des sites externes, et PHP ne leur attribuera pas le SID, qui pourrait repreacute;senter un risque de trou de seacute;curiteacute;. + /para /note /para para
Re: [PHP-DOC] cvs: phpdoc /fr/functions session.xml
On Mon, 19 Mar 2001, Egon Schmid (@work) wrote: Jouni Ahto wrote: In general, should we be using paranotepara.../para/note/para, or the simpler form notepara.../para/note? Both are valid. I don't know but I think the appearance could be different. Compare the PDF or PostScript output for getallheaders() in the German manual. The paras following the examples are wrong indented. Yes, I see. Print versions of the DSSSL-stylesheets seem to have a problem. When any block element, like para, has a note inside it, the whole block gets intended. Also, the more there are block elements inside block elements, the more extra vertical white space gets generated after the outermost one is closed. So, I think my opinion will be: always use the simplest valid alternative. -- Jouni
[PHP-DOC] cvs: phpdoc /fr/appendices resources.xml /fr/functions xslt.xml /fr/language oop.xml
jah Sun Mar 18 03:11:58 2001 EDT Modified files: /phpdoc/fr/appendices resources.xml /phpdoc/fr/functionsxslt.xml /phpdoc/fr/language oop.xml Log: French version compiles ok again. Damien, please check the changes, I don't actually speak french... (Jouni) Index: phpdoc/fr/appendices/resources.xml diff -u phpdoc/fr/appendices/resources.xml:1.1 phpdoc/fr/appendices/resources.xml:1.2 --- phpdoc/fr/appendices/resources.xml:1.1 Thu Mar 15 06:22:43 2001 +++ phpdoc/fr/appendices/resources.xml Sun Mar 18 03:11:57 2001 @@ -1,8 +1,8 @@ -appendix id=resources +appendix id="resources" titleTypes des ressources PHP/title para - Voici la liste des fonctions qui crent, utilisent ou dtruisent les - resources PHP. Vous pouvez dterminer si une variable contient une + Voici la liste des fonctions qui creacute;ent, utilisent ou deacute;truisent les + resources PHP. Vous pouvez deacute;terminer si une variable contient une resource avec la fonction functionis_resource/function, et le type d'une resource que vous utilisez avec la fonction functionget_resource_type/function. @@ -10,14 +10,14 @@ para table titleTypes de ressource/title - tgroup cols=5 + tgroup cols="5" thead row entryRessource/entry entryConstruite par/entry - entryUtilis par/entry - entryDtruite par/entry - entryDfinition/entry + entryUtiliseacute; par/entry + entryDeacute;truite par/entry + entryDeacute;finition/entry /row /thead tbody @@ -626,4 +626,4 @@ /tgroup /table /para -/appendix \ No newline at end of file +/appendix Index: phpdoc/fr/functions/xslt.xml diff -u phpdoc/fr/functions/xslt.xml:1.9 phpdoc/fr/functions/xslt.xml:1.10 --- phpdoc/fr/functions/xslt.xml:1.9Fri Mar 16 08:17:44 2001 +++ phpdoc/fr/functions/xslt.xmlSun Mar 18 03:11:57 2001 @@ -300,7 +300,7 @@ /funcsynopsis para functionxslt_process/function prend la chaicirc;ne - parameterstring parameterxsl_data/parameter comme feuille de style XSLT, et + string parameterxsl_data/parameter comme feuille de style XSLT, et des donneacute;es XML dans parameterxml_data/parameter. Le reacute;sultat de la transformation sera placeacute; dans parameterresult/parameter. functionxslt_process/function retourne literalTRUE/literal Index: phpdoc/fr/language/oop.xml diff -u phpdoc/fr/language/oop.xml:1.9 phpdoc/fr/language/oop.xml:1.10 --- phpdoc/fr/language/oop.xml:1.9 Mon Mar 12 04:12:37 2001 +++ phpdoc/fr/language/oop.xml Sun Mar 18 03:11:58 2001 @@ -1,4 +1,4 @@ - chapter id="oop" + chapter id="language.oop" titleClasses et objets/title sect1 id="keyword.class" titleLes classes : literalclass/literal/title
Re: [PHP-DOC] PDF bug with -- operators
On Mon, 19 Feb 2001 [EMAIL PROTECTED] wrote: On Mon, Feb 19, 2001 at 03:58:32PM -0600, Daniel Beckham wrote: Yes, it would be a bit harder to read, but I think it might be worth it to correct readability issues with the PDF version of the manual. Please wait for Jouni. The problem is that we cannot pass a verbatim environment throu TeX. I was glad enough while Jouni produced my private PostScript and PDF versions of the PHP manual. "a" looked like ", "o" comes out as " and so on. With a pure english TeX version this problem don't appear. Probably the right person to blame is Norman Walsh with his modular stylesheets or the author of Jadetex. No reason to wait, I don't have a solution for this problem :( (at least now). Someone who knows a lot about TeX could probably prevent this from happening. The only thing I know is that after processing from XML to TeX format with Jade '--' is still '--', after jadetex it has changed. But I don't think we can blame jadetex either. -- Jouni - Original Message - From: "Damien Seguy" [EMAIL PROTECTED] To: "Daniel Beckham" [EMAIL PROTECTED] Sent: Monday, February 19, 2001 3:39 PM Subject: Re: [PHP-DOC] PDF bug with "--" operators le 19/02/01 20:20, Daniel Beckham [EMAIL PROTECTED] a crit : What would be the best way to turn them into entities, create them and put it in global.ent? Or use the #xx; format? When I needed it (and I did, with French language), I created the @#xx; format. It is totally save, and easy to go. However, it makes it harder to read again.
Re: [PHP-DOC] windows-doc-generation
On Wed, 7 Feb 2001, Hojtsy Gabor wrote: The error here is that //f/phpcvs type of paths are generated by cygwin, and jade.exe can't deal with this. So we need to put here f:/phpcvs/dsssl/html/docbook.dsl. Do anybody know an elegant way to do this? Well, cygwin understands f:/phpcvs... So use this insted, and the manual generation works!!! :) There seems to be also /cygdrive/f/ alternative. Don't know which one would be the best alternative... -- Jouni (who now uses/must use NT4 daily in his new workplace)
Re: [PHP-DOC] cvs: phpdoc /en/functions mail.xml
On Mon, 5 Feb 2001, Egon Schmid wrote: eschmid Mon Feb 5 14:55:59 2001 EDT Modified files: /phpdoc/en/functions mail.xml Log: Tested only with the older Jade. Jouni, I need some help from you with Openjade. Help is, of course, granted. But... the problem description was a little bit vague. Unless you just need OpenJade installed somewhere. Or what? -- Jouni Index: phpdoc/en/functions/mail.xml diff -u phpdoc/en/functions/mail.xml:1.10 phpdoc/en/functions/mail.xml:1.11 --- phpdoc/en/functions/mail.xml:1.10 Mon Feb 5 13:50:59 2001 +++ phpdoc/en/functions/mail.xml Mon Feb 5 14:55:59 2001 @@ -21,8 +21,8 @@ paramdefstring parametersubject/parameter/paramdef paramdefstring parametermessage/parameter/paramdef paramdefstring - parameteroptionaladditional_headers/optional - /parameter + parameteroptionaladditional_headers/optional/parameter + /paramdef paramdefstring parameteroptionaladditional_parameters/optional /parameter
[PHP-DOC] cvs: phpdoc / configure.in
jah Sat Feb 3 13:51:52 2001 EDT Modified files: /phpdoc configure.in Log: Missed setting papersize option for PDF. Index: phpdoc/configure.in diff -u phpdoc/configure.in:1.53 phpdoc/configure.in:1.54 --- phpdoc/configure.in:1.53Thu Feb 1 06:26:03 2001 +++ phpdoc/configure.in Sat Feb 3 13:51:51 2001 @@ -1,4 +1,4 @@ -dnl $Id: configure.in,v 1.53 2001/02/01 14:26:03 jkj Exp $ +dnl $Id: configure.in,v 1.54 2001/02/03 21:51:51 jah Exp $ AC_INIT(global.ent) @@ -141,10 +141,17 @@ dnl localize paper size by language dnl (instead of using system-dependant default) case "$LANG" in - cs|de|hu|ja|ko) PAPER_TYPE="A4" ;; - *) PAPER_TYPE="USletter" ;; + cs|de|hu|ja|ko) +PAPER_TYPE="A4" +PDF_PAPER_TYPE="a4" +;; + *) +PAPER_TYPE="USletter" +PDF_PAPER_TYPE="letter" +;; esac AC_SUBST(PAPER_TYPE) +AC_SUBST(PDF_PAPER_TYPE) dnl localize order of number and element name dnl in some headers autogenerated by jade
[PHP-DOC] cvs: phpdoc / configure.in
jah Sat Feb 3 13:54:43 2001 EDT Modified files: /phpdoc configure.in Log: Prefer OpenJade over the older Jade. Index: phpdoc/configure.in diff -u phpdoc/configure.in:1.54 phpdoc/configure.in:1.55 --- phpdoc/configure.in:1.54Sat Feb 3 13:51:51 2001 +++ phpdoc/configure.in Sat Feb 3 13:54:42 2001 @@ -1,4 +1,4 @@ -dnl $Id: configure.in,v 1.54 2001/02/03 21:51:51 jah Exp $ +dnl $Id: configure.in,v 1.55 2001/02/03 21:54:42 jah Exp $ AC_INIT(global.ent) @@ -213,18 +213,18 @@ esac AC_SUBST(ENCODING) -dnl look for the jade DSSSL parser -AC_PATH_PROG(JADECHK, "jade", no) -if test $JADECHK = "no"; then -dnl Jade isnt present, so look for OpenJade instead -AC_PATH_PROG(OPENJADECHK, "openjade", no) -if test $OPENJADECHK = "no"; then +dnl look for the OpenJade DSSSL parser +AC_PATH_PROG(OPENJADECHK, "openjade", no) +if test $OPENJADECHK = "no"; then +dnl OpenJade isnt present, so look for the older Jade instead +AC_PATH_PROG(JADECHK, "jade", no) +if test $JADECHK = "no"; then AC_MSG_ERROR(unable to locate either Jade or OpenJade) else -JADEPATH=$OPENJADECHK +JADEPATH=$JADECHK fi else -JADEPATH=$JADECHK +JADEPATH=$OPENJADECHK fi case "$ENCODING" in
[PHP-DOC] cvs: phpdoc / Makefile.in
jah Sat Feb 3 13:55:57 2001 EDT Modified files: /phpdoc Makefile.in Log: Ignore more errors from jadetex. Index: phpdoc/Makefile.in diff -u phpdoc/Makefile.in:1.53 phpdoc/Makefile.in:1.54 --- phpdoc/Makefile.in:1.53 Sat Feb 3 13:51:07 2001 +++ phpdoc/Makefile.in Sat Feb 3 13:55:56 2001 @@ -26,7 +26,7 @@ # +--+ # -# $Id: Makefile.in,v 1.53 2001/02/03 21:51:07 jah Exp $ +# $Id: Makefile.in,v 1.54 2001/02/03 21:55:56 jah Exp $ # VPATH=@srcdir@ @@ -135,8 +135,8 @@ rm manual.tex.tmp -jadetex $ - jadetex $ - jadetex $ + -jadetex $ + -jadetex $ dvipdfm -p @PDF_PAPER_TYPE@ manual.dvi html/index.html: manual.xml $(HTML_DEPS)
[PHP-DOC] cvs: phpdoc / global.ent /fr/functions image.xml info.xml misc.xml pcre.xml session.xml strings.xml var.xml xml.xml /fr/language variables.xml
jah Sat Feb 3 16:33:29 2001 EDT
Modified files:
/phpdoc global.ent
/phpdoc/fr/functionsimage.xml info.xml misc.xml pcre.xml
session.xml strings.xml var.xml xml.xml
/phpdoc/fr/language variables.xml
Log:
Fixed some errors with tags in the french version. There are still a few other
errors, someone who actually understands french, please fix them...
nsgmls:./fr/functions/sem.xml:229:19:E: non SGML character number 146
nsgmls:./fr/functions/sem.xml:240:40:E: non SGML character number 146
nsgmls:./fr/functions/yaz.xml:260:55:E: non SGML character number 136
Index: phpdoc/global.ent
diff -u phpdoc/global.ent:1.70 phpdoc/global.ent:1.71
--- phpdoc/global.ent:1.70 Fri Jan 26 08:48:52 2001
+++ phpdoc/global.ent Sat Feb 3 16:33:28 2001
@@ -1,10 +1,11 @@
!-- -*- SGML -*-
- $Id: global.ent,v 1.70 2001/01/26 16:48:52 jmoore Exp $
+ $Id: global.ent,v 1.71 2001/02/04 00:33:28 jah Exp $
Contains global "macros" for all the SGML documents.
--
+!ENTITY % lang-hu "INCLUDE"
!ENTITY url.adabas "http://www.adabas.com/"
!ENTITY url.adobe "http://www.adobe.com/"
!ENTITY url.apache "http://www.apache.org/"
Index: phpdoc/fr/functions/image.xml
diff -u phpdoc/fr/functions/image.xml:1.13 phpdoc/fr/functions/image.xml:1.14
--- phpdoc/fr/functions/image.xml:1.13 Tue Jan 30 00:45:19 2001
+++ phpdoc/fr/functions/image.xml Sat Feb 3 16:33:28 2001
@@ -2252,8 +2252,11 @@
}
?gt;
/programlisting
+ simpara
Cet exemple va afficher :
- computeroutput
+ /simpara
+ literallayout
+ computeroutput
FileName: p0001807.jpg
FileDateTime: 929353056
FileSize: 378599
@@ -2274,7 +2277,8 @@
RawFocusDistance: 16.65847412
Orientation: 1
ExifVersion: 0200
- /computeroutput
+ /computeroutput
+ /literallayout
/example
/para
para
Index: phpdoc/fr/functions/info.xml
diff -u phpdoc/fr/functions/info.xml:1.9 phpdoc/fr/functions/info.xml:1.10
--- phpdoc/fr/functions/info.xml:1.9Tue Jan 30 01:05:50 2001
+++ phpdoc/fr/functions/info.xmlSat Feb 3 16:33:28 2001
@@ -998,7 +998,8 @@
/informalexample
affichera la liste suivante :
informalexample
- computeroutput
+ literallayout
+ computeroutput
Array
(
[0] =gt; xml
@@ -1014,7 +1015,8 @@
[10] =gt; Calendar
[11] =gt; bcmath
)
- /computeroutput
+ /computeroutput
+ /literallayout
/informalexample
/para
para
@@ -1102,7 +1104,8 @@
/example
va geacute;neacute;rer l'affichage suivant :
informalexample
- computeroutput
+ literallayout
+ computeroutput
Fichiers requis par required_once()
Array
(
@@ -1117,7 +1120,8 @@
[util3] =gt; util3.php
[util4] =gt; util4.php
)
- /computeroutput
+ /computeroutput
+ /literallayout
/informalexample
/para
para
Index: phpdoc/fr/functions/misc.xml
diff -u phpdoc/fr/functions/misc.xml:1.4 phpdoc/fr/functions/misc.xml:1.5
--- phpdoc/fr/functions/misc.xml:1.4Tue Jan 30 00:45:20 2001
+++ phpdoc/fr/functions/misc.xmlSat Feb 3 16:33:28 2001
@@ -326,7 +326,8 @@
simpara
L'affichage devrait ressembler agrave; ceci :
/simpara
-computeroutput
+literallayout
+ computeroutput
Mozilla/4.5 [en] (X11; U; Linux 2.2.9 i586)lt;hrgt;
lt;Bgt;browser_name_pattern:lt;/Bgt; Mozilla/4\.5.*lt;brgt;
lt;Bgt;parent:lt;/Bgt; Netscape 4.0lt;brgt;
@@ -347,7 +348,8 @@
lt;Bgt;crawler:lt;/Bgt; lt;brgt;
lt;Bgt;authenticodeupdate:lt;/Bgt; lt;brgt;
lt;Bgt;msn:lt;/Bgt; lt;brgt;
-/computeroutput
+ /computeroutput
+/literallayout
simpara
Pour fonctionner, votre configuration
link linkend="ini.sect.browscap"browscap/link
Index: phpdoc/fr/functions/pcre.xml
diff -u phpdoc/fr/functions/pcre.xml:1.13 phpdoc/fr/functions/pcre.xml:1.14
--- phpdoc/fr/functions/pcre.xml:1.13 Tue Jan 30 23:57:49 2001
+++ phpdoc/fr/functions/pcre.xmlSat Feb 3 16:33:28 2001
@@ -22,7 +22,7 @@
example
titleExemples de masques valides/title
itemizedlist
- listitemsimpara/tl;\/\w+//simpara/listitem
+ listitemsimpara/lt;\/\w+//simpara/listitem
listitemsimpara|(\d{3})-\d+|Sm/simpara/listitem
listitemsimpara/^(?i)php[34]//simpara/listitem
listitemsimpara{^\s+(\s+)?$}/simpara/listitem
@@ -197,10 +197,12 @@
/informalexample
Cet exemple va afficher :
informalexample
- computeroutput
+ literallayout
+ computeroutput
lt;bgt;exemple: lt/bgt;, lt;div align=leftgt;ceci est un testlt;/divgt;
exemple: , ceci est un test
- /computeroutput
+ /computeroutput
+ /literallayout
/informalexample
Ainsi, $out[0] est un tableau qui contient les reacute;sultats qui
satisfont le masque complet, et $out[1] est un tableau qui contient
@@ -227,10
[PHP-DOC] cvs: phpdoc / Makefile.in
jah Wed Jan 31 12:20:41 2001 EDT Modified files: /phpdoc Makefile.in Log: Added specific rule to create manual.pdf. Index: phpdoc/Makefile.in diff -u phpdoc/Makefile.in:1.51 phpdoc/Makefile.in:1.52 --- phpdoc/Makefile.in:1.51 Tue Jan 23 15:49:44 2001 +++ phpdoc/Makefile.in Wed Jan 31 12:20:40 2001 @@ -26,7 +26,7 @@ # +--+ # -# $Id: Makefile.in,v 1.51 2001/01/23 23:49:44 jimw Exp $ +# $Id: Makefile.in,v 1.52 2001/01/31 20:20:40 jah Exp $ # VPATH=@srcdir@ @@ -127,6 +127,17 @@ manual.txt.gz: manual.txt gzip -9 -c $ $@ + +manual.pdf: manual.tex + # a hack around bugs in jade/jadetex... + mv manual.tex manual.tex.tmp + sed -e '/HeadingText/,/endHeadPar/ s/_/\\137/g' manual.tex.tmp manual.tex + rm manual.tex.tmp + + jadetex $ + jadetex $ + jadetex $ + dvipdfm -p @PDF_PAPER_TYPE@ manual.dvi html/index.html: manual.xml $(HTML_DEPS) @test -d html || mkdir html
Re: [PHP-DOC] PHP manual
On Wed, 31 Jan 2001 [EMAIL PROTECTED] wrote: On Tue, Jan 30, 2001 at 07:51:43PM -0500, David Elrom wrote: Why r we using TeX ? why not some other XML format ? If you want a printed manual, DocBook uses a TeX backend. TeX is better than every XML style shit. To be more precise, we use DocBook XML format and then convert it to TeX to get a printable version. To be even more precise, the TeX format is then converted to printable/vievable versions. This is currently the best way to do it. XSL/XSLT maybe the future, maybe not, but we ain't there yet... -- Jouni
Re: [PHP-DOC] the php manual....
On Mon, 29 Jan 2001, Jim Winstead wrote: In article 00dd01c0892d$1d296680$cd0110ac@shuttle, [EMAIL PROTECTED] wrote: [snip] Which also introduces the questions: 1. What would it take to get the PDF versions into other languages besides english? I have asked this question some time ago. I guess the answer is just time. I don't know about any technological problems generating manuals in other languages... right now, producing the pdf with the table-of-contents is a non-scriptable process. if someone were to figure out the correct combination of tools to fix that, we could add automatically generated pdf versions to the list of things on the website. This is fortunately old news. See the example at end, it could be added to our Makefile with the necessary modifications. Would it be OK to proceed? As for languages other that english, as long as dsssl-stylesheets support it, it's uses one from the ISO-8859 character sets and the writing direction is left-to-right, I can figure out how to do it. With japanese and korean, I know a few hints, but without the necessary fonts available for me, it's a bit hard to test. -- Jouni # must use openjade, the plain old jade (ie. 1.2 or older) didn't handle # bookmarks/outlines so well openjade -V tex-backend -i lang-en -d ./print.dsl -t tex ./phpdocxml.dcl manual.xml # a hack around bugs in jade/pdfjadetex... mv manual.tex manual.tex.tmp sed -e '/HeadingText/,/endHeadPar/ s/_/\\137/g' -e '/HeadingText/,/endHeadPar/ s/\$/\\044/g' manual.tex.tmp manual.tex rm manual.tex.tmp jadetex manual.tex jadetex manual.tex jadetex manual.tex dvipdfm -p a4 -v manual.dvi
[PHP-DOC] cvs: phpdoc /cs/functions info.xml
jah Fri Jan 26 00:36:00 2001 EDT Modified files: /phpdoc/cs/functionsinfo.xml Log: Fixed a typo. Index: phpdoc/cs/functions/info.xml diff -u phpdoc/cs/functions/info.xml:1.2 phpdoc/cs/functions/info.xml:1.3 --- phpdoc/cs/functions/info.xml:1.2Thu Jan 25 22:39:53 2001 +++ phpdoc/cs/functions/info.xmlFri Jan 26 00:36:00 2001 @@ -940,7 +940,7 @@ èasu, skript vrátí fatální chybu. Standardní limit je 30 sekund, nebo, pokud existuje, hodnota direktivy max_execution_time definovaná v link linkend="configuration.file"konfiguraèním souboru/link. Pokud je -parameterseconds-parameter nula, neexistuje ¾ádný èasový limit. +parameterseconds/parameter nula, neexistuje ¾ádný èasový limit. /simpara simpara functionset_time_limit/function pøi svém zavolání restartuje èítaè èasu
Re: [PHP-DOC] problem with cs translation
On Fri, 26 Jan 2001, Cynic wrote: I've already found a commandline tool that seems to be perfect. Right now I'm configuring it, will try. Could you please try and build the cs docs when I convert them? Ok. I'll try to check the traffic on this list a few times during the workday, but don't be surprised if it takes a few hours after your commit before you get any response. Emacs? NT (No Thanks) - last time I tried win32 Emacs I felt like a victim of a particularly bad joke. Have to admit that I haven't yet tested it myself... -- Jouni
[PHP-DOC] cvs: phpdoc / configure.in
jah Thu Jan 25 23:36:38 2001 EDT Modified files: /phpdoc configure.in Log: Czech language support. Index: phpdoc/configure.in diff -u phpdoc/configure.in:1.49 phpdoc/configure.in:1.50 --- phpdoc/configure.in:1.49Sat Jan 20 18:03:26 2001 +++ phpdoc/configure.in Thu Jan 25 23:36:38 2001 @@ -1,4 +1,4 @@ -dnl $Id: configure.in,v 1.49 2001/01/21 02:03:26 avsm Exp $ +dnl $Id: configure.in,v 1.50 2001/01/26 07:36:38 jah Exp $ AC_INIT(global.ent) @@ -131,7 +131,7 @@ dnl localize paper size by language dnl (instead of using system-dependant default) case "$LANG" in - de|hu|ja|ko) PAPER_TYPE="A4" ;; + cs|de|hu|ja|ko) PAPER_TYPE="A4" ;; *) PAPER_TYPE="USletter" ;; esac AC_SUBST(PAPER_TYPE) @@ -176,7 +176,7 @@ case "$LANG" in ja|tw|ko) ENCODING="UTF-8";; - hu) ENCODING="ISO-8859-2";; + cs|hu) ENCODING="ISO-8859-2";; *) ENCODING="ISO-8859-1";; esac AC_SUBST(ENCODING)
Re: [PHP-DOC] cvs trouble
On Wed, 24 Jan 2001, Hojtsy Gabor wrote: Are you sure if cs is Czech. Create first a directory in the phpdoc tree on your local hard disk and then: cvs add cz You don't need an commit afterwards. yes, I'm sure. ISO codes for Czech language are ces/cze (3-letter codes) or cs (2-letter). check out http://www.w3.org/WAI/ER/IG/ert/iso639.htm Well, your TLD is .cz... I wonder where .cs belongs... Good work on the translation :) Yep, the country code is cz, but the language code is cs. Fortunately, the DocBook dsssl stylesheets also use cs, so there's no need for any dirty hacks. Cynic/Roman (don't know which one is appropriate), please fix also configure.in for your language. There are a few language-dependent things there. Most important being the character set you are using, I'd guess it to be ISO-8859-2, and as an European, your default paper size for printed version is most probably A4. -- Jouni
Re: [PHP-DOC] cvs: phpdoc / Makefile.in configure.in manual.xml.in
On Thu, 11 Jan 2001, Jim Winstead wrote: jimw Wed Jan 10 20:15:08 2001 EDT Modified files: /phpdoc Makefile.in configure.in manual.xml.in Log: clean up building from seperate directory Index: phpdoc/configure.in diff -u phpdoc/configure.in:1.44 phpdoc/configure.in:1.45 --- phpdoc/configure.in:1.44 Fri Jan 5 17:34:24 2001 +++ phpdoc/configure.in Wed Jan 10 20:15:08 2001 @@ -1,4 +1,4 @@ -dnl $Id: configure.in,v 1.44 2001/01/06 01:34:24 hirokawa Exp $ +dnl $Id: configure.in,v 1.45 2001/01/11 04:15:08 jimw Exp $ AC_INIT(global.ent) @@ -57,7 +57,7 @@ /usr/local/lib/sgml/stylesheets/nwalsh-modular \ /usr/local/lib/sgml/docbook \ /usr/local/share/sgml/docbook/dsssl/modular ; do -if test -d "$dir"; then +if test -d "$srcdir/$dir"; then DOCBOOK_HTML="$dir/html/docbook.dsl" DOCBOOK_PRINT="$dir/print/docbook.dsl" This change actually breaks everything... -- Jouni
