[PHP-DOC] #14283 [Opn->Sus]: printer_create_dc - Example has errors in manual

2002-12-19 Thread iliaa
 ID:   14283
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Suspended
 Bug Type: Documentation problem
 Operating System: WinXP ger
 PHP Version:  4.0.6
 New Comment:

Appears to be an abandoned PECL extension.


Previous Comments:


[2002-05-16 21:07:46] [EMAIL PROTECTED]

The original code presented by joerglklein will not print at all for
me.  I get the same errors on both Win 98 and Win NT 4 SP4 using a
Generic Text driver as well as a printer specific driver.

I found if I put the printer_create_dc() and printer_set_option()
outside of printer_start_doc() and printer_start_page() that it did
print without most errors, but of course it didn't print correctly.



[2001-11-29 10:43:25] [EMAIL PROTECTED]

take a look at
http://www.php.net/manual/en/function.printer-create-dc.php

at first you should replace printer_endpage($handle); with
printer_end_page($handle);
his is the correct code:

01: 

Second: when I tried out this example I get an one error and one
warning:
Warning: couldn't end the page in /test.php on line 19
Fatal error: couldn't terminate print job in /test.php on line 20

When I try to open a special printer with 
$handle = printer_open("$printer");
I get these errors and warnings:
Warning: No DeviceContext created in /test.php on line 17
Warning: couldn't end the page in /test.php on line 19
Fatal error: couldn't terminate print job in /test.php on line 20

So I think there a some problems with the Device Contexts

Joerg




-- 
Edit this bug report at http://bugs.php.net/?id=14283&edit=1


-- 
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




[PHP-DOC] #21104 [NEW]: Font too small in certian areas of the manual.

2002-12-19 Thread eric
From: [EMAIL PROTECTED]
Operating system: 
PHP version:  4.2.3
PHP Bug Type: Documentation problem
Bug description:  Font too small in certian areas of the manual.

This is more of a personal request than a bug report I suppose. In the
documentation for the code examples and the constants, the size of the
font is too small. This happens when using Mozilla (or another browser
that uses the Gecko engine) and Opera. I'm running at 1600 x 1200 on a 19"
monitor, and the Opera browser was in a 1280 x 1024 resoloution. This
seems to happen more in the higher resoloutions of course. This does not
happen in Internet Explorer or on smaller resoloutions. I can imagine that
it would be rather difficult to read for someone using 1024x786 on a 15"
monitor if they are using one of the browsers listed above. I'm sure there
would be an easy fix for this, like specifying a specific font size using
CSS. Just thought I would let you guys know. :)
-- 
Edit bug report at http://bugs.php.net/?id=21104&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21104&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=21104&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=21104&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21104&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=21104&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21104&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=21104&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21104&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21104&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=21104&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21104&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=21104&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=21104&r=isapi


-- 
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DOC] Can't see build log

2002-12-19 Thread James Cox
OK,

because of the presence of phpdoc/zh (the bad checkin) it couldn't
checkout phpdoc-zh to it... so it got all hot and flustered. Same for
tw.

I have tar'ed the old zh and tw trees, and deleted them from phpdoc. zh
looks checked out now ok, so next build should see us a built (or not)
zh tree.

Thanks,

 James

On Fri, 2002-12-20 at 03:38, Dallas Thunder wrote:
> When I try to access http://www.php.net/zh/blog, I get this response:
> 
> Search Results
> Sorry, no documents matched your search for "manual/zh/build.log.gz".
> 
> If you can see Chinese build logs, would you please send it to me?  So I can
> find out what was wrong.  Thanks!
> 
> 
> "James Cox" <[EMAIL PROTECTED]> 
> :[EMAIL PROTECTED]
> > As i have said time and time again, there are build logs.
> >
> > the Chinese manual fails to build. Please consult the build log @
> > php.net or a possibly more up-to-date one @
> >
> > http://rsync.php.net/~imajes/manual/
> >
> > Thanks,
> >
> > James
> >
> > On Fri, 2002-12-20 at 02:47, Dallas Thunder wrote:
> > > Dear PHP doc members,
> > >
> > > The PHP Chinese manual is not available since Nov 19th.  When try to
> access
> > > http://www.php.net/manual/zh/, the browser address will become
> > > http://www.php.net/search.php?show=manual&pattern=manual%2Fzh%2F and
> > > displays
> > > Search Results
> > > Sorry, no documents matched your search for "manual/zh/".
> > >
> > > There's also no building log.
> > > Our Chinese translation team have checked again and again, but have no
> idea
> > > about what's going on here.  We can successfully build PHP manual in our
> own
> > > computer.
> > >
> > > Would someone please check the PHP manual tree and make Chinese manual
> > > available, many thanks!
> > >
> > >
> >
> 
> 


-- 
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




[PHP-DOC] Can't see build log

2002-12-19 Thread Dallas Thunder
When I try to access http://www.php.net/zh/blog, I get this response:

Search Results
Sorry, no documents matched your search for "manual/zh/build.log.gz".

If you can see Chinese build logs, would you please send it to me?  So I can
find out what was wrong.  Thanks!


"James Cox" <[EMAIL PROTECTED]> дÈëÏûÏ¢ÐÂÎÅ
:[EMAIL PROTECTED]
> As i have said time and time again, there are build logs.
>
> the Chinese manual fails to build. Please consult the build log @
> php.net or a possibly more up-to-date one @
>
> http://rsync.php.net/~imajes/manual/
>
> Thanks,
>
> James
>
> On Fri, 2002-12-20 at 02:47, Dallas Thunder wrote:
> > Dear PHP doc members,
> >
> > The PHP Chinese manual is not available since Nov 19th.  When try to
access
> > http://www.php.net/manual/zh/, the browser address will become
> > http://www.php.net/search.php?show=manual&pattern=manual%2Fzh%2F and
> > displays
> > Search Results
> > Sorry, no documents matched your search for "manual/zh/".
> >
> > There's also no building log.
> > Our Chinese translation team have checked again and again, but have no
idea
> > about what's going on here.  We can successfully build PHP manual in our
own
> > computer.
> >
> > Would someone please check the PHP manual tree and make Chinese manual
> > available, many thanks!
> >
> >
>



-- 
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




[PHP-DOC] cvs: phpdoc /en/reference/image/functions imagesetstyle.xml

2002-12-19 Thread Damien Seguy
damsThu Dec 19 22:34:54 2002 EDT

  Modified files:  
/phpdoc/en/reference/image/functionsimagesetstyle.xml 
  Log:
  fixing error in the example
  
  
Index: phpdoc/en/reference/image/functions/imagesetstyle.xml
diff -u phpdoc/en/reference/image/functions/imagesetstyle.xml:1.3 
phpdoc/en/reference/image/functions/imagesetstyle.xml:1.4
--- phpdoc/en/reference/image/functions/imagesetstyle.xml:1.3   Thu Apr 18 13:13:10 
2002
+++ phpdoc/en/reference/image/functions/imagesetstyle.xml   Thu Dec 19 22:34:54 
+2002
@@ -1,5 +1,5 @@
 
-
+
 
   

@@ -27,9 +27,8 @@
  
   imagesetstyle
   
-
+
   
  
 



-- 
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DOC] Serious request about online Chinese manual

2002-12-19 Thread Dallas Thunder
Thanks for your prompt response.  I was wondering if building fail, there
should be a previous successful one, but there's not.
And in http://rsync.php.net/~imajes/manual/, I didn't see file
"zh-bulid.log.gz".
Chinese I've mentioned is Simplified Chinese, not Traditional Chinese in
Hong Kong.
Thanks again.

"James Cox" <[EMAIL PROTECTED]> дÈëÏûÏ¢ÐÂÎÅ
:[EMAIL PROTECTED]
> As i have said time and time again, there are build logs.
>
> the Chinese manual fails to build. Please consult the build log @
> php.net or a possibly more up-to-date one @
>
> http://rsync.php.net/~imajes/manual/
>
> Thanks,
>
> James
>
> On Fri, 2002-12-20 at 02:47, Dallas Thunder wrote:
> > Dear PHP doc members,
> >
> > The PHP Chinese manual is not available since Nov 19th.  When try to
access
> > http://www.php.net/manual/zh/, the browser address will become
> > http://www.php.net/search.php?show=manual&pattern=manual%2Fzh%2F and
> > displays
> > Search Results
> > Sorry, no documents matched your search for "manual/zh/".
> >
> > There's also no building log.
> > Our Chinese translation team have checked again and again, but have no
idea
> > about what's going on here.  We can successfully build PHP manual in our
own
> > computer.
> >
> > Would someone please check the PHP manual tree and make Chinese manual
> > available, many thanks!
> >
> >
>



-- 
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DOC] Serious request about online Chinese manual

2002-12-19 Thread James Cox
As i have said time and time again, there are build logs.

the Chinese manual fails to build. Please consult the build log @
php.net or a possibly more up-to-date one @

http://rsync.php.net/~imajes/manual/

Thanks,

James

On Fri, 2002-12-20 at 02:47, Dallas Thunder wrote:
> Dear PHP doc members,
> 
> The PHP Chinese manual is not available since Nov 19th.  When try to access
> http://www.php.net/manual/zh/, the browser address will become
> http://www.php.net/search.php?show=manual&pattern=manual%2Fzh%2F and
> displays
> Search Results
> Sorry, no documents matched your search for "manual/zh/".
> 
> There's also no building log.
> Our Chinese translation team have checked again and again, but have no idea
> about what's going on here.  We can successfully build PHP manual in our own
> computer.
> 
> Would someone please check the PHP manual tree and make Chinese manual
> available, many thanks!
> 
> 


-- 
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




[PHP-DOC] Serious request about online Chinese manual

2002-12-19 Thread Dallas Thunder
Dear PHP doc members,

The PHP Chinese manual is not available since Nov 19th.  When try to access
http://www.php.net/manual/zh/, the browser address will become
http://www.php.net/search.php?show=manual&pattern=manual%2Fzh%2F and
displays
Search Results
Sorry, no documents matched your search for "manual/zh/".

There's also no building log.
Our Chinese translation team have checked again and again, but have no idea
about what's going on here.  We can successfully build PHP manual in our own
computer.

Would someone please check the PHP manual tree and make Chinese manual
available, many thanks!



-- 
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




[PHP-DOC] #20888 [Asn->Sus]: Installation instructions for Apache CGI mode missing/misleading

2002-12-19 Thread betz
 ID:  20888
 Updated by:  [EMAIL PROTECTED]
 Reported By: [EMAIL PROTECTED]
-Status:  Assigned
+Status:  Suspended
 Bug Type:Documentation problem
 PHP Version: 4.3.0RC2
 Assigned To: betz
 New Comment:

Until a descision is made by the developers of PHP about the names of
the binaries this bug will be suspended.


Previous Comments:


[2002-12-09 04:25:47] [EMAIL PROTECTED]

Thanks for your report. I am on the way to update the docs.
They will show up soon on the website.



[2002-12-08 15:29:14] [EMAIL PROTECTED]

I tried installing 4.3.0RC2 in CGI mode for Apache, following the
documentation at

http://www.php.net/manual/en/install.commandline.php

Result: one hour wasted. Reason: the page does not contain any hint as
to what directives need to be added to the httpd.conf to enable
processing of *.php files by the interpreter. There is a user-provided
docnote which handles this, suggesting to use something like this:

AddType application/x-httpd-php .php4
ScriptAlias /php4/ "/home/king/php-4.1.2/"
Action application/x-httpd-php /php4/php

Unfortunately, this is dangerously outdated: you must use
/php4/php-cgi, not /php4/php. Failing to do so results in the very
difficult to debug "Premature end of script headers" message in
server's error log. That "php-cgi" thing is mentioned NOWHERE on the
CGI installation page - I only managed to solve it through advice on
IRC.




-- 
Edit this bug report at http://bugs.php.net/?id=20888&edit=1


-- 
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




[PHP-DOC] #19423 [Com]: Problem with extension_dir in PHP.ini

2002-12-19 Thread nico
 ID:   19423
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: Documentation problem
 Operating System: Windows 9x/NT/ME/2000/XP
 PHP Version:  4.2.3
 New Comment:

All the suggested solutions don't work in my case, I'm not shure, what
it means if a bug has the status closed, but it is obviously not fixed.
The phpinfo() shows the correct path for the extension_dir like it does
for session_data etc. but the errormessage "can't load dynamic library
-  modul not found", remains the same.


Previous Comments:


[2002-10-15 16:04:06] [EMAIL PROTECTED]

I have had this trouble for 3 days and now I found the problem.

I just moved php.ini from c:\winnt\system32 to c:\winnt and it worked.

I hope this information is usefull.



[2002-10-15 13:11:05] [EMAIL PROTECTED]

I'm running Win2k & IIS and I've been having the same damn problem. 
Dumping everything plus the kitchen sink, dll-wise into %system32%
fixed this issue for me, as well.  Good call, cdfisher!!  :-)

Part of my problem was actually reading the instructions that came with
all these distributions.  (Stupid me.)  For instance, the Gingerall
folks tell you to rename whatever dll you get from expat to expat.dll. 
Even though I think they were referring to some old release that had
the version number in its name, it's easy to apply this overbroad rule
to the libexpat.dll library that expat's releasing now.  

Anyway, what worked for me was this:

In PHP.ini:
-Extensions_dir=
-Remove the ";" from in front of "extension=php_xslt.dll"

Then dump ALL the necessary dll's in %system32% without altering any
file names. 

(ie, iconv.dll, js32.dll, libexpat.dll,php_xslt.dll, php4ts.dll and of
course
sablot.dll.)



[2002-10-05 00:14:19] [EMAIL PROTECTED]

The only thing I noiced you didn't do was what [EMAIL PROTECTED] said he
tried and worked.  That was to put a single backslash \ after the
directory name.  I haven't tried this, but here is what worked for me:
extension_dir=
Uncomment the php_xslt extension.
Place all these files in either the %SYSTEM% or %SYSTEM32% Directory:
iconv.dll, js32.dll, libexpat.dll,php_xslt.dll, php4ts.dll and of
course sablot.dll.

The js32 is only needed if the expat version has been compiled with the
JavaScript extension.  Unless you have all the files in the system
directory, you will continue to get errors when loading that point to
your tail.  In other words they mean nothing except failure and unless
you use a tool such as Dependency Walker to open the php_xslt.dll, you
will become frustrated fast.  I saved all these files to a separate
directory when I first installed xslt on my development system, then
just copied them over to my production server and was up in no time!  I
hope I didn't forget any of them, but if I did, just search this site
for it and you will find many people who have used it (and the URL, I
have forgotton it) successfully.  I am writing a Content Management
system using XSLT as my chief means of XML processing, transformation
and search engine.  I really like using it to build snipets of PHP
logic that use XSLT to generate HTML or XML.  It's much more flexible
than writing my own parser routines and objects, and the XSL languange
is highly flexible.  I have even worked out some datetime math with it.
 It could use some help in the extension department for that one! 
Anyway, have fun at work!

Curtis



[2002-10-04 15:07:16] [EMAIL PROTECTED]

Well, since I thought I might have something miss installed, I've gone
ahead and re-started my Win2000 Server installation.

I'm back to the same problem however. Any directory I specify for the
extension dll, won't work. I've tried, d:\php\extensions,
d:\php\\extensions\, d:\\php\\extensions, d:\\php\exetensions\\,
d:/php/extensions, d://php//extensions,
d://php/extensions/, d://php//extensions//

I've attempted as well to move the dll into the system 32 directory,
and in the same directory has the php.exe file. No luck.

Below are my specifications:

Server: Dell Power App 120 Server, SCSI hard drives.
OS: Window 2000 Server running IIS 5
PHP: Version 4.2.3 running ISAP installation

Php ini file : c:\WINNT\php.ini
Php directory : d:\php
Extension directory : d:\php\extensions

Note: I've installed this same version on 6 other Win2000 clients (Pro
and Server) with IIS 5, and have not run into this problem before. The
only main difference is that its a Power App Server, with SCSI drives.



[2002-09-27 12:34:01] [EMAIL PROTECTED]

Should be mentioned in the manuel...

Derick

--

Re: [PHP-DOC] Problem with the revcheck page

2002-12-19 Thread Thomas Schöfbeck
Hi all,

I can't see any differences in the behavior of "../" between cgi- and 
cli-version (at least on my win-box, and I would wonder if it is on 
Linux, and if, somebody should report it to qa), but it seems to be the 
old story of currentdir, workdir, etc. on the different machines.

If I'm right, the call from the makefile
"PHPDOCDIR=$(srcdir) $(PHP) -c $(scriptdir) -f $(scriptdir)/revcheck.php 
$(LANGDIR) > revcheck.html"
sets an environment-variable before it calls revcheck (But I'm not an 
expert on *nixes).

In this case, a fix for the generating machine should be to change the 
lines 93-98 in revcheck.php with:

if (isset($_ENV['PHPDOCDIR']) && is_dir($_ENV['PHPDOCDIR']))
  $DOCDIR = $_ENV['PHPDOCDIR']."/";  // run via make
else
  $DOCDIR = "../"; //run directly from script-dir

NOTE: Under Win and Cygwin you need the above isset(), because 
is_dir($not_set_var) returns true, and PHPDOCDIR=$(srcdir) doesn't set a 
Win-env-var for the php.exe.

So it's not a perfect solution, but it should work.

Would be great if somebody could check it on *nix (the best would the 
generating machine) before it gets committed (and changed again ;-).

So far my 2 cents,
Thomas


Gabor Hojtsy wrote:
As far as I have seen Friedhelm committed a fix to solve
this problem [it is because of the CGI/CLI differences]... 

Goba


The same to pt_BR

Fernando

Martin Samesch escreveu:



Hi,

http://www.php.net/manual/de/revcheck.html.gz tells me that "The de
language code is not valid".

Is it broken?

Martin





--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




[PHP-DOC] Re: Bug #21086 [Opn]: imagepolygon syntax description

2002-12-19 Thread Stefan Hinz
Pierre,

> The word 'vertex' is correct, a polygon own a minimum amount of 3
> verteces (which represent 3 carthesians coordonates, points).
> A more 'userfriendly' word should be added, but this is correct.

Thanks for answering so soon. Of course, you're right. What I was to say
is that the PHP documentation should be as clear and userfriendly as PHP
itself.

Regards,
--
  Stefan Hinz <[EMAIL PROTECTED]>
  Geschäftsführer / CEO iConnect GmbH 
  Heesestr. 6, 12169 Berlin (Germany)
  Tel: +49 30 7970948-0  Fax: +49 30 7970948-3


- Original Message -
From: "PHP Bug Database" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, December 19, 2002 2:30 AM
Subject: Bug #21086 [Opn]: imagepolygon syntax description


> ATTENTION! Do NOT reply to this email!
> To reply, use the web interface found at
> http://bugs.php.net/?id=21086&edit=2
>
>
>  ID:   21086
>  Updated by:   [EMAIL PROTECTED]
>  Reported By:  [EMAIL PROTECTED]
>  Status:   Open
>  Bug Type: Documentation problem
>  Operating System: N/A
>  PHP Version:  4.2.3
>  New Comment:
>
> The word 'vertex' is correct, a polygon own a minimum amount of 3
> verteces (which represent 3 carthesians coordonates, points).
>
> A more 'userfriendly' word should be added, but this is correct.
>
> pierre
>
>
> Previous Comments:
> --
--
>
> [2002-12-18 16:02:41] [EMAIL PROTECTED]
>
> IS:
> int imagepolygon ( int im, array points, int num_points, int col) ...
> num_points is the total number of vertices.
> SHOULD BE:
> int imagepolygon ( int im, array points, int num_points, int col) ...
> num_points is the total number of points, divided by 2.
> If this is not considered a bug, it's pretty misleading at least.
> HTH.
>
>
> --
--
>
>


-- 
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




[PHP-DOC] cvs: phpdoc /en/reference/session reference.xml /entities global.ent

2002-12-19 Thread Sascha Schumann
sas Thu Dec 19 07:44:07 2002 EDT

  Modified files:  
/phpdoc/entitiesglobal.ent 
/phpdoc/en/reference/sessionreference.xml 
  Log:
  Add link to newly released session fixation paper
  
  
Index: phpdoc/entities/global.ent
diff -u phpdoc/entities/global.ent:1.65 phpdoc/entities/global.ent:1.66
--- phpdoc/entities/global.ent:1.65 Wed Dec 18 02:27:37 2002
+++ phpdoc/entities/global.ent  Thu Dec 19 07:44:07 2002
@@ -1,6 +1,6 @@
 
+
  
   Session handling functions
   Sessions
@@ -58,6 +58,9 @@


 Sessions and security
+
+ External links: Session fixation
+
 
  The session module cannot guarantee that the information you store
  in a session is only viewed by the user who created the session. You need



-- 
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DOC] Problem with the revcheck page

2002-12-19 Thread Gabor Hojtsy
As far as I have seen Friedhelm committed a fix to solve
this problem [it is because of the CGI/CLI differences]... 

Goba

> The same to pt_BR
> 
> Fernando
> 
> Martin Samesch escreveu:
> 
> >Hi,
> >
> >http://www.php.net/manual/de/revcheck.html.gz tells me that "The de
> >language code is not valid".
> >
> >Is it broken?
> >
> >Martin
> >
> >
> >  
> >
> 
> 
> 
> -- 
> PHP Documentation Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 



-- 
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php