[PHP-DOC] #21834 [Com]: First call to imagecolorallocate() assigns background

[Brendan]

 ID:   21834
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Documentation problem
 Operating System: Win2k
 PHP Version:  4.3.0
 New Comment:

Sure thing.  Later today I'll investigate different image types, and
post the results here.

I'll also see if things are different with imagecreatetruecolor() (I
suspect they will be).


Previous Comments:


[2003-01-22 23:09:28] [EMAIL PROTECTED]

This will need some study and confirmation.  For example here is one
user comment:

"With gd 2.x, the first color allocated with imagecolorallocate()
appears to no longer be made the background color. You can use
imagefill() to set the background color."

Granted whatever behavior exists needs to be documented ... but what is
the exact behavior?  Please report further findings in this bug report
:)



[2003-01-22 22:58:54] [EMAIL PROTECTED]

I discovered from experimentation that the first call to
imagecolorallocate() for a given image, sets the background colour for
that image.

This would be worth noting in the manual page for imagecolorallocate().
 Someone has pointed it out in a user comment, but it is a fairly
important aspect of the function's behaviour, and IMO should be part of
the official documentation.

I'm using php_gd2 as bundled with PHP 4.3.0, and I've only tried PNG
images so far.  I can't say for sure if imagecolorallocate() exhibits
this same behaviour for other image types.

As an aside, the GD functionality is great.  I'm loving the idea of
creating dynamic images in my app.

May the Force be with you.




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


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

[PHP-DOC] #21834 [Opn]: First call to imagecolorallocate() assigns background

[philip]

 ID:   21834
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Documentation problem
 Operating System: Win2k
 PHP Version:  4.3.0
 New Comment:

This will need some study and confirmation.  For example here is one
user comment:

"With gd 2.x, the first color allocated with imagecolorallocate()
appears to no longer be made the background color. You can use
imagefill() to set the background color."

Granted whatever behavior exists needs to be documented ... but what is
the exact behavior?  Please report further findings in this bug report
:)


Previous Comments:


[2003-01-22 22:58:54] [EMAIL PROTECTED]

I discovered from experimentation that the first call to
imagecolorallocate() for a given image, sets the background colour for
that image.

This would be worth noting in the manual page for imagecolorallocate().
 Someone has pointed it out in a user comment, but it is a fairly
important aspect of the function's behaviour, and IMO should be part of
the official documentation.

I'm using php_gd2 as bundled with PHP 4.3.0, and I've only tried PNG
images so far.  I can't say for sure if imagecolorallocate() exhibits
this same behaviour for other image types.

As an aside, the GD functionality is great.  I'm loving the idea of
creating dynamic images in my app.

May the Force be with you.




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


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

[PHP-DOC] #21834 [NEW]: First call to imagecolorallocate() assigns background

[Brendan]

From: [EMAIL PROTECTED]
Operating system: Win2k
PHP version:  4.3.0
PHP Bug Type: Documentation problem
Bug description:  First call to imagecolorallocate() assigns background

I discovered from experimentation that the first call to
imagecolorallocate() for a given image, sets the background colour for
that image.

This would be worth noting in the manual page for imagecolorallocate(). 
Someone has pointed it out in a user comment, but it is a fairly important
aspect of the function's behaviour, and IMO should be part of the official
documentation.

I'm using php_gd2 as bundled with PHP 4.3.0, and I've only tried PNG
images so far.  I can't say for sure if imagecolorallocate() exhibits this
same behaviour for other image types.

As an aside, the GD functionality is great.  I'm loving the idea of
creating dynamic images in my app.

May the Force be with you.
-- 
Edit bug report at http://bugs.php.net/?id=21834&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21834&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=21834&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=21834&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21834&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=21834&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21834&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=21834&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21834&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21834&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=21834&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21834&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=21834&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=21834&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21834&r=gnused


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

[PHP-DOC] #21833 [Fbk]: IIS 5.0 requires additional parameters on Add Mappings Tab

[pollita]

 ID:   21833
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Documentation problem
 Operating System: Windows 2000 Server
 PHP Version:  4.3.0
 New Comment:

I have *NOT* experienced this requirement with PHP installed as a CGI
on my Win2K/IIS5.0 installation. (I just have "c:\php\php.exe" entered
in my IIS5.0 setup).

Some research needs to be done to determine when and why it is
necessary.


Previous Comments:


[2003-01-22 22:34:30] [EMAIL PROTECTED]

Is this modification specific to (required for) IIS 5 and not IIS 4? 
Even so, does adding it still allow IIS 4 to work with PHP CGI?  

This %s %s information appears in the user comments as well but needs
to be put in the manual :)



[2003-01-22 22:15:54] [EMAIL PROTECTED]

Sorry, I forgot to include URL:

http://aspn.activestate.com//ASPN/Reference/Products/ActivePerl/faq/Windows/ActivePerl-Winfaq6.html


Link: How do I configure Microsoft IIS 4.0/IIS 5.0 to support Perl



[2003-01-22 22:07:42] [EMAIL PROTECTED]



This line produced the "No input file" output
after I configured PHP on IIS 5.0 by following
each step of installation instructions (I decided
to configure PHP to work as a CGI script, not SAPI )

After several
tries I understood what the problem is. I have an
experience in Perl programming under Linux and Windows
and I remembered that Active Perl 5.6 installation
script adds not only the script name in Add/Edit Application Extension
Mapping dialog but also adds
%s %s to the end.

Quote from the ActiveState Perl installation docs:

"To run Perl as a CGI application, type the full path to Perl.exe
followed by %s %s. When a script is executed, the first %s will be
replaced by the full path to the script, and the second %s will be
replaced by the script parameters."

This applies only to CGI mode. For ISAPI mode there is no need in these
additional %s %s at the end.

So I suggest that installation guide may be
corrected like this:

--- text ---

 Windows NT/2000/XP and IIS 4 or newer and PWS 4 on NT Workstation or
W2K non server editions

--- text ---

   If you want to use the CGI binary, do the following:
   Under 'Home Directory', 'Virtual Directory', or
   'Directory', click on the 'Configuration' button,
   and then enter the App Mappings tab.

   Click Add, and in the Executable box, type:
   c:\php\php.exe %s %s (assuming that you have unzipped PHP in
c:\php\).

--- text ---

And thats it!

Here is also a URL to ActiveState website where I found the explanation
for this %s spells :-)))

Well, this is it. Everything else is working fine!

Denys Vorobyov




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


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

[PHP-DOC] #21833 [Opn->Fbk]: IIS 5.0 requires additional parameters on Add Mappings Tab

[philip]

 ID:   21833
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Documentation problem
 Operating System: Windows 2000 Server
 PHP Version:  4.3.0
 New Comment:

Is this modification specific to (required for) IIS 5 and not IIS 4? 
Even so, does adding it still allow IIS 4 to work with PHP CGI?  

This %s %s information appears in the user comments as well but needs
to be put in the manual :)


Previous Comments:


[2003-01-22 22:15:54] [EMAIL PROTECTED]

Sorry, I forgot to include URL:

http://aspn.activestate.com//ASPN/Reference/Products/ActivePerl/faq/Windows/ActivePerl-Winfaq6.html


Link: How do I configure Microsoft IIS 4.0/IIS 5.0 to support Perl



[2003-01-22 22:07:42] [EMAIL PROTECTED]



This line produced the "No input file" output
after I configured PHP on IIS 5.0 by following
each step of installation instructions (I decided
to configure PHP to work as a CGI script, not SAPI )

After several
tries I understood what the problem is. I have an
experience in Perl programming under Linux and Windows
and I remembered that Active Perl 5.6 installation
script adds not only the script name in Add/Edit Application Extension
Mapping dialog but also adds
%s %s to the end.

Quote from the ActiveState Perl installation docs:

"To run Perl as a CGI application, type the full path to Perl.exe
followed by %s %s. When a script is executed, the first %s will be
replaced by the full path to the script, and the second %s will be
replaced by the script parameters."

This applies only to CGI mode. For ISAPI mode there is no need in these
additional %s %s at the end.

So I suggest that installation guide may be
corrected like this:

--- text ---

 Windows NT/2000/XP and IIS 4 or newer and PWS 4 on NT Workstation or
W2K non server editions

--- text ---

   If you want to use the CGI binary, do the following:
   Under 'Home Directory', 'Virtual Directory', or
   'Directory', click on the 'Configuration' button,
   and then enter the App Mappings tab.

   Click Add, and in the Executable box, type:
   c:\php\php.exe %s %s (assuming that you have unzipped PHP in
c:\php\).

--- text ---

And thats it!

Here is also a URL to ActiveState website where I found the explanation
for this %s spells :-)))

Well, this is it. Everything else is working fine!

Denys Vorobyov




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


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

[PHP-DOC] #21833 [Opn]: IIS 5.0 requires additional parameters on Add Mappings Tab

[dvorobyov]

 ID:   21833
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Documentation problem
 Operating System: Windows 2000 Server
 PHP Version:  4.3.0
 New Comment:

Sorry, I forgot to include URL:

http://aspn.activestate.com//ASPN/Reference/Products/ActivePerl/faq/Windows/ActivePerl-Winfaq6.html


Link: How do I configure Microsoft IIS 4.0/IIS 5.0 to support Perl


Previous Comments:


[2003-01-22 22:07:42] [EMAIL PROTECTED]



This line produced the "No input file" output
after I configured PHP on IIS 5.0 by following
each step of installation instructions (I decided
to configure PHP to work as a CGI script, not SAPI )

After several
tries I understood what the problem is. I have an
experience in Perl programming under Linux and Windows
and I remembered that Active Perl 5.6 installation
script adds not only the script name in Add/Edit Application Extension
Mapping dialog but also adds
%s %s to the end.

Quote from the ActiveState Perl installation docs:

"To run Perl as a CGI application, type the full path to Perl.exe
followed by %s %s. When a script is executed, the first %s will be
replaced by the full path to the script, and the second %s will be
replaced by the script parameters."

This applies only to CGI mode. For ISAPI mode there is no need in these
additional %s %s at the end.

So I suggest that installation guide may be
corrected like this:

--- text ---

 Windows NT/2000/XP and IIS 4 or newer and PWS 4 on NT Workstation or
W2K non server editions

--- text ---

   If you want to use the CGI binary, do the following:
   Under 'Home Directory', 'Virtual Directory', or
   'Directory', click on the 'Configuration' button,
   and then enter the App Mappings tab.

   Click Add, and in the Executable box, type:
   c:\php\php.exe %s %s (assuming that you have unzipped PHP in
c:\php\).

--- text ---

And thats it!

Here is also a URL to ActiveState website where I found the explanation
for this %s spells :-)))

Well, this is it. Everything else is working fine!

Denys Vorobyov




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


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

[PHP-DOC] #21833 [NEW]: IIS 5.0 requires additional parameters on Add Mappings Tab

[dvorobyov]

From: [EMAIL PROTECTED]
Operating system: Windows 2000 Server
PHP version:  4.3.0
PHP Bug Type: Documentation problem
Bug description:  IIS 5.0 requires additional parameters on Add Mappings Tab



This line produced the "No input file" output
after I configured PHP on IIS 5.0 by following
each step of installation instructions (I decided
to configure PHP to work as a CGI script, not SAPI )

After several
tries I understood what the problem is. I have an
experience in Perl programming under Linux and Windows
and I remembered that Active Perl 5.6 installation
script adds not only the script name in Add/Edit Application Extension
Mapping dialog but also adds
%s %s to the end.

Quote from the ActiveState Perl installation docs:

"To run Perl as a CGI application, type the full path to Perl.exe followed
by %s %s. When a script is executed, the first %s will be replaced by the
full path to the script, and the second %s will be replaced by the script
parameters."

This applies only to CGI mode. For ISAPI mode there is no need in these
additional %s %s at the end.

So I suggest that installation guide may be
corrected like this:

--- text ---

 Windows NT/2000/XP and IIS 4 or newer and PWS 4 on NT Workstation or W2K
non server editions

--- text ---

   If you want to use the CGI binary, do the following:
   Under 'Home Directory', 'Virtual Directory', or
   'Directory', click on the 'Configuration' button,
   and then enter the App Mappings tab.

   Click Add, and in the Executable box, type:
   c:\php\php.exe %s %s (assuming that you have unzipped PHP in c:\php\).

--- text ---

And thats it!

Here is also a URL to ActiveState website where I found the explanation
for this %s spells :-)))

Well, this is it. Everything else is working fine!

Denys Vorobyov
-- 
Edit bug report at http://bugs.php.net/?id=21833&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21833&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=21833&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=21833&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21833&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=21833&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21833&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=21833&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21833&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21833&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=21833&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21833&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=21833&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=21833&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21833&r=gnused


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

[PHP-DOC] cvs: phpdoc /en/reference/pcre/functions preg-replace.xml

[Sara Golemon]

pollita Wed Jan 22 23:06:26 2003 EDT

  Modified files:  
/phpdoc/en/reference/pcre/functions preg-replace.xml 
  Log:
  Typo fixes
  
  
Index: phpdoc/en/reference/pcre/functions/preg-replace.xml
diff -u phpdoc/en/reference/pcre/functions/preg-replace.xml:1.5 
phpdoc/en/reference/pcre/functions/preg-replace.xml:1.6
--- phpdoc/en/reference/pcre/functions/preg-replace.xml:1.5 Wed Jan 22 20:04:49 
2003
+++ phpdoc/en/reference/pcre/functions/preg-replace.xml Wed Jan 22 23:06:26 2003
@@ -1,5 +1,5 @@
 
-
+
 
   

@@ -42,7 +42,7 @@
notation for your backreference.  \\11, for example,
would confuse preg_replace since it does not know whether
you want the \\1 backreference followed by a literal 
1, 
-   or the \\11 backreference followed nothing.  In this case
+   or the \\11 backreference followed by nothing.  In this case
the solution is to use \${1}1.  This creates an
isolated $1 backreference, leaving the 1
as a literal.
@@ -55,7 +55,7 @@
 http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DOC] #21816 [Asn->Csd]: preg_replace has problem with arrays

[pollita]

 ID:   21816
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Assigned
+Status:   Closed
 Bug Type: Documentation problem
 Operating System: Windows XP
 PHP Version:  4.3.0
 Assigned To:  pollita
 New Comment:

This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2003-01-22 15:30:10] [EMAIL PROTECTED]

This could be made more clear in the manual.  I'll add a note and an
example tonight.



[2003-01-22 14:52:19] [EMAIL PROTECTED]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

The replacment is done in the order the array was created, if you want
it to be done based on array keys that run an appropriate sorting
function before executing the preg_replace function.



[2003-01-22 12:14:45] [EMAIL PROTECTED]

The search strings used in the preg_replace() function are regular
expressions. "[abc]" is a regular expression which matches any of the
characters "a", "b" or "c".

Either use str_replace() to replace your strings, or learn to use
regular expressions
.



[2003-01-22 08:41:20] [EMAIL PROTECTED]

" . $string2;
echo "Result should be: Say a [betterWord0] about
[betterWord1] and [betterWord2]";

// result should be:
//Say a [betterWord0] about [betterWord1] and [betterWord2]
//
// but produces: 
//Say a [betterWord0] about [betterWord2] and [betterWord1]
//
// Seems like the order in which i build my array
// is the order for replacing...and not the index
// of $array[$index]
//
// if you add a ksort it works fine:

ksort($search,SORT_NUMERIC);
ksort($replace,SORT_NUMERIC);   
reset($search);
reset($replace);

$string3 = preg_replace($search,$replace,$string);
echo "Corrected (ksort) Result is:" . $string3;

//
// Has someone an idea, about what's happening here?
//
// just a guy addicted to php ;-)
?>



[2003-01-22 07:43:39] [EMAIL PROTECTED]

" . $string;
echo "Result should be: Say a [betterWord0] about
[betterWord1] and [betterWord2]";

// result should be:
//Say a [betterWord0] about [betterWord1] and [betterWord2]
//
// but produces: 
//Say a [betterWord0] about [betterWord2] and [betterWord1]
//
// Seems like the order in which i build my array
// is the order for replacing...and not the index
// of $array[$index]
//
//
// Has someone an idea, about what's happening here?
//
// just a guy addicted to php ;-)
?>




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


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

RE: [PHP-DOC] Suggestion for a clean PHP 5 - Manual

[Philip Olson]

On Thu, 23 Jan 2003, Timothy Hitchens (HiTCHO) wrote:
> Just a suggestion.. but what if we look at a way for the viewer of the
> manual to choose their version of PHP and then see it as it related to
> that version then the issue of PHP3 etc and removed extensions etc is
> not
> an issue anymore and the manual can grow without confusion for the
> viewer.

This suggestion has come up but implementing it is 
not going to happen.  If you come up with a sane
way to do this, let us know :)

Regards,
Philip


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

RE: [PHP-DOC] Suggestion for a clean PHP 5 - Manual

[Timothy Hitchens \(HiTCHO\)]

Just a suggestion.. but what if we look at a way for the viewer of the
manual to choose their version of PHP and then see it as it related to
that version then the issue of PHP3 etc and removed extensions etc is
not
an issue anymore and the manual can grow without confusion for the
viewer.


Timothy Hitchens (HiTCHO)
Open Source Consulting
e-mail: [EMAIL PROTECTED]

> -Original Message-
> From: Philip Olson [mailto:[EMAIL PROTECTED]] 
> Sent: Thursday, 23 January 2003 10:55 AM
> To: [EMAIL PROTECTED]
> Cc: Friedhelm Betz; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: [PHP-DOC] Suggestion for a clean PHP 5 - Manual
> 
> 
> > > - removal of outdated extensions
> > 
> > If the extension has been completely removed from the
> > source tree, then yes it should be gone from the
> > manual. Not sure if someone is keeping an archive of
> > old manuals, just in case.
> 
> I partially disagree with this.  Simply removing 
> them is not the answer.  I already stated various
> reasons why in the archives and still on my TODO
> is to adjust the RFC's on the subject (I promised
> doing this).  Look forward to a post on this subject,
> I promise it'll be good :)
> 
> An example is cybercash.  This was removed yet still
> people use it as the service still exists.  Personally
> I feel it should not have been removed but anyway
> it was.  Maybe some kind soul will put it in PECL.
> Anyway, people still use these removed extensions and
> people still link to these docs.  We still have PHP3
> notes, why would we remove functionality that 
> existed just a few PHP versions back?  I hope it's
> not because of PDF generation ;)
> 
> > If the extension is being deprecated then a note
> > should be in the manual. So in the future when it gets removed 
> > completely, it will not take people by surprise.
> 
> aspell is like this.  But really, does the php-dev
> team give any warning?  Not usually :)
> 
> > > - moving parts to PECL, the extions in question
> > 
> > That will go as fast as the restructuring of the PEAR documentation 
> > system goes. There is a new (peardoc2) structure/system, so as the 
> > extensions migrate over to PECL (ideally) the maintainer or someone 
> > from phpdoc or peardoc can do the move and (if needed) conversion.
> > 
> > For what I've seen of the peardoc2, it is not too
> > dissimilar from the old phpdoc, perhaps some of the
> > phpdoc gurus can subscribe to the peardoc list and
> > talk about reorganizing the preadoc2's PECL bits to
> > match the structure from the current phpdoc?
> 
> As discussed in the archives, this move won't be as
> easy as mv phpdoc/{ext} pear/pecl/{ext} as there are
> BC concerns with broken links being one.  But this 
> can be addressed and will.
> 
> > > - restructering (see manual.xml in RFC)
> > 
> > +1 on that one, it will make the manual more readable,
> > and better organized
> 
> Nice.  Finally bug #17164 will get closed :)
> 
> > > - spiliiting in devekopers and user manual (or
> > > whatever names we would choose)
> > 
> > I think it was "Developer" and "User". And yes +1 on
> > that.
> 
> Sounds good.  I believe the developers manual will
> remain in english only.
> 
> Regards,
> Philip
> 
> 
> -- 
> 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

Re: [PHP-DOC] Suggestion for a clean PHP 5 - Manual

[Philip Olson]

> > - removal of outdated extensions
> 
> If the extension has been completely removed from the
> source tree, then yes it should be gone from the
> manual. Not sure if someone is keeping an archive of
> old manuals, just in case.

I partially disagree with this.  Simply removing 
them is not the answer.  I already stated various
reasons why in the archives and still on my TODO
is to adjust the RFC's on the subject (I promised
doing this).  Look forward to a post on this subject,
I promise it'll be good :)

An example is cybercash.  This was removed yet still
people use it as the service still exists.  Personally
I feel it should not have been removed but anyway
it was.  Maybe some kind soul will put it in PECL.
Anyway, people still use these removed extensions and
people still link to these docs.  We still have PHP3
notes, why would we remove functionality that 
existed just a few PHP versions back?  I hope it's
not because of PDF generation ;)

> If the extension is being deprecated then a note
> should be in the manual. So in the future when it gets
> removed completely, it will not take people by
> surprise.

aspell is like this.  But really, does the php-dev
team give any warning?  Not usually :)

> > - moving parts to PECL, the extions in question
> 
> That will go as fast as the restructuring of the PEAR
> documentation system goes. There is a new (peardoc2)
> structure/system, so as the extensions migrate over to
> PECL (ideally) the maintainer or someone from phpdoc
> or peardoc can do the move and (if needed) conversion.
> 
> For what I've seen of the peardoc2, it is not too
> dissimilar from the old phpdoc, perhaps some of the
> phpdoc gurus can subscribe to the peardoc list and
> talk about reorganizing the preadoc2's PECL bits to
> match the structure from the current phpdoc?

As discussed in the archives, this move won't be as
easy as mv phpdoc/{ext} pear/pecl/{ext} as there are
BC concerns with broken links being one.  But this 
can be addressed and will.

> > - restructering (see manual.xml in RFC)
> 
> +1 on that one, it will make the manual more readable,
> and better organized

Nice.  Finally bug #17164 will get closed :)

> > - spiliiting in devekopers and user manual (or
> > whatever names we would choose)
> 
> I think it was "Developer" and "User". And yes +1 on
> that.

Sounds good.  I believe the developers manual will
remain in english only.

Regards,
Philip


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

Re: [PHP-DOC] Suggestion for a clean PHP 5 - Manual

[Jesus M. Castagnetto]

(Crossposting to pear-doc)

-1 on forking to a PHP5 only manual. As Philip already
mentioned is not a good idea, whereas the User -
Developer separation does make sense.

--- Friedhelm Betz <[EMAIL PROTECTED]> wrote:
[...snip...]
> - removal of outdated extensions

If the extension has been completely removed from the
source tree, then yes it should be gone from the
manual. Not sure if someone is keeping an archive of
old manuals, just in case.

If the extension is being deprecated then a note
should be in the manual. So in the future when it gets
removed completely, it will not take people by
surprise.

> - moving parts to PECL, the extions in question

That will go as fast as the restructuring of the PEAR
documentation system goes. There is a new (peardoc2)
structure/system, so as the extensions migrate over to
PECL (ideally) the maintainer or someone from phpdoc
or peardoc can do the move and (if needed)
conversion.

For what I've seen of the peardoc2, it is not too
dissimilar from the old phpdoc, perhaps some of the
phpdoc gurus can subscribe to the peardoc list and
talk about reorganizing the preadoc2's PECL bits to
match the structure from the current phpdoc?

> - restructering (see manual.xml in RFC)

+1 on that one, it will make the manual more readable,
and better organized

> - spiliiting in devekopers and user manual (or
> whatever names we would choose)

I think it was "Developer" and "User". And yes +1 on
that.


=
--- Jesus M. Castagnetto <[EMAIL PROTECTED]>

__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

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

Re: [PHP-DOC] Suggestion for a clean PHP 5 - Manual

[Jesus M. Castagnetto]

(Crossposting to pear-doc)

-1 on forking to a PHP5 only manual. As Philip already
mentioned is not a good idea, whereas the User -
Developer separation does make sense.

--- Friedhelm Betz <[EMAIL PROTECTED]> wrote:
[...snip...]
> - removal of outdated extensions

If the extension has been completely removed from the
source tree, then yes it should be gone from the
manual. Not sure if someone is keeping an archive of
old manuals, just in case.

If the extension is being deprecated then a note
should be in the manual. So in the future when it gets
removed completely, it will not take people by
surprise.

> - moving parts to PECL, the extions in question

That will go as fast as the restructuring of the PEAR
documentation system goes. There is a new (peardoc2)
structure/system, so as the extensions migrate over to
PECL (ideally) the maintainer or someone from phpdoc
or peardoc can do the move and (if needed) conversion.

For what I've seen of the peardoc2, it is not too
dissimilar from the old phpdoc, perhaps some of the
phpdoc gurus can subscribe to the peardoc list and
talk about reorganizing the preadoc2's PECL bits to
match the structure from the current phpdoc?

> - restructering (see manual.xml in RFC)

+1 on that one, it will make the manual more readable,
and better organized

> - spiliiting in devekopers and user manual (or
> whatever names we would choose)

I think it was "Developer" and "User". And yes +1 on
that.


=
--- Jesus M. Castagnetto <[EMAIL PROTECTED]>

__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

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

Re: [PHP-DOC] Suggestion for a clean PHP 5 - Manual

[Friedhelm Betz]

> Regarding PHP 3 specific information, this indeed should be
> moved but not simply deleted.  History is good.  Another idea
> would be to move all PHP 3 specific information into a PHP 3
> section and where the information was, point to it instead.  So
> something like:
>
>   php3 note
>
> This would replace the explanation with a link to the explanation
> in the PHP 3 specific section.  A section that once created will
> never need to be touched.  And I bet there are still a few PHP 3
> users out there :)

+1 

Friedhelm

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

Re: [PHP-DOC] Suggestion for a clean PHP 5 - Manual

[Friedhelm Betz]

Hi Thomas,
>
> P.S. Other questions like this will follow, like:
>
> Since we aren't able to build a pdf-version due to a lack of resources:
> Why don't we make the FAQ an extra document (esp. for 'bundled' builds
> like chm, pdf, bightml, ... - I've never read a book where chap. 43
> describes the same thing like chap. 3, just with a question as title ;)?

Hmm, IMHO it would be "technical" difficult as there are crosslinks to the 
manual. Could be solved indeed, but IMHO it would make much more sense to 
clean up the existing manul:

- removal of outdated extensions
- moving parts to PECL, the extions in question
- restructering (see manual.xml in RFC)
- spiliiting in devekopers and user manual (or whatever names we would choose)

Regards

Friedhelm



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

[PHP-DOC] #20601 [Opn->Csd]: A simple syntax parse error

[philip]

 ID:   20601
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Documentation problem
 Operating System: Windows ME
 PHP Version:  4.3.0RC1
 Assigned To:  philip
 New Comment:

Thanks for the report, the documentation has been updated here:
http://cvs.php.net/cvs.php/phpdoc/en/language/types.xml

On a related note, this may end up not being a parse error in the
future.  The documentation will be updated once a verdict is made on
bug #21820 so hold tight :)


Previous Comments:


[2002-12-17 10:51:18] [EMAIL PROTECTED]

Sort of.  This is a feature I was not aware of in PHP and imho is sort
of a bug :)  

As it turns out, constants are only seen in strings if:

a) It's an array key
b) {braces} are around the array

So for example, NO E_NOTICE is generated from "a $arr[foo]"  but "a
{$arr[foo]}" does!  And btw, "a {foo}" does not look for the constant
foo.

And because multidimensional arrays inside strings require {braces}
this is an important point.  IMHO this behavior of constants inside
strings is inconsistent and I'm writing php-dev now! :)



[2002-12-17 10:37:35] [EMAIL PROTECTED]

Philip, please do not change that part of the documentation. **It is
correct!**.

Try with this script:



For the first echo line, a NOTICE error is
echoed out... So the documentation is correct. It may not be clear
enough, but it is correct, the example is right.



[2002-12-05 13:49:27] [EMAIL PROTECTED]

As it turns out, the string docs are wrong and contain the following in
the example:


// This is wrong for the same reason
// as $foo[bar] is wrong outside a string. 
echo "This is wrong: {$arr[foo][3]}";


I'll rewrite this part of the documention too.  $foo[bar] is perfectly
fine inside strings, CONSTANTS aren't seen in strings.  Anyway, this
will be further explained with a more specific example too.  And a faq
entry :)  This question comes up waaay too much these days.



[2002-12-05 13:26:22] [EMAIL PROTECTED]

The string type description includes a lengthy explanation of this
AFAIK.



[2002-12-04 19:03:14] [EMAIL PROTECTED]

Btw, this happens when you do:

print "a foo $bar['blah'] eh";

Don't do that.  You can do either:

print "a foo {$bar['blah']} eh";
print "a foo $bar[blah] eh";
print "a foo " . $bar['blah'] . " eh";

But when outside of strings always quote your keys:

print $bar[blah];   // bad
print $bar['blah']; // good

Unless of course you defined blah as a constant earlier.  Anyway I'm
making a faq out of this question and marking as a doc bug because this
question comes up a lot especially since 4.1.0 (autoglobals) and 4.2.0
(register_globals default change).



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/20601

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


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

[PHP-DOC] cvs: phpdoc /en/language types.xml

[Philip Olson]

philip  Wed Jan 22 18:55:57 2003 EDT

  Modified files:  
/phpdoc/en/language types.xml 
  Log:
  Expanded string and array information including many example updates, many
  more manual links, and a little cleanup.  Added a decent amount of information 
  on using arrays within strings and further explained $foo[bar].  This also closes 
bug #20601
  
  
Index: phpdoc/en/language/types.xml
diff -u phpdoc/en/language/types.xml:1.105 phpdoc/en/language/types.xml:1.106
--- phpdoc/en/language/types.xml:1.105  Tue Jan 21 02:27:50 2003
+++ phpdoc/en/language/types.xmlWed Jan 22 18:55:56 2003
@@ -1,5 +1,5 @@
 
-
+
  
   Types
 
@@ -667,16 +667,25 @@
 

@@ -847,7 +856,8 @@
  Variable parsing
  
   When a string is specified in double quotes or with
-  heredoc, variables are parsed within it.
+  heredoc, variables are 
+  parsed within it. 
  
  
   There are two types of syntax, a 
@@ -856,7 +866,8 @@
   complex
   one.
   The simple syntax is the most common and convenient, it provides a way
-  to parse a variable, an array value, or an object property.
+  to parse a variable, an array value, or an 
+  object property.
  
  
   The complex syntax was introduced in PHP 4, and can be recognised
@@ -879,14 +890,15 @@
 echo "$beer's taste is great"; // works, "'" is an invalid character for varnames
 echo "He drank some $beers";   // won't work, 's' is a valid character for varnames
 echo "He drank some ${beer}s"; // works
+echo "He drank some {$beer}s"; // works
 ?>
 ]]>

   
   
-   Similarly, you can also have an array index or an object
-   property parsed. With array indices, the closing square bracket
-   (]) marks the end of the index. For
+   Similarly, you can also have an array index or an 
+   object property parsed. With array indices, the closing square 
+   bracket (]) marks the end of the index. For
object properties the same rules apply as to simple variables,
though with object properties there doesn't exist a trick like
the one with variables.
@@ -901,11 +913,32 @@

 
@@ -994,6 +1048,9 @@
 $str = 'This is a test.';
 $first = $str{0};
 
+// Get the third character of a string
+$third = $str{2};
+
 // Get the last character of a string.
 $str = 'This is still a test.';
 $last = $str{strlen($str)-1}; 
@@ -1045,36 +1102,41 @@
  is automatically done in the scope of an expression for you where a
  string is needed. This happens when you use the echo
  or print functions, or when you compare a variable
- value to a string.
+ value to a string.  Reading the manual sections on Types and Type Juggling will make
+ the following clearer.  See also settype.
 
 
 
- A boolean &true; value is converted to the string "1",
+ A boolean &true; value is converted to the string 
+"1",
  the &false; value is represented as "" (empty string).
  This way you can convert back and forth between boolean and string values.
 
  
- An integer or a floating point number is converted to a string
- representing the number with its digits (includig the exponent part
- for floating point numbers).
+ An integer or a floating point number (float) 
+ is converted to a string representing the number with its digits
+ (including the exponent part for floating point numbers).
 
 
  Arrays are always converted to the string "Array",
- so you cannot dump out the contents of an array with echo
- or print to see what is inside them. See the information
- below for more tips.
+ so you cannot dump out the contents of an array with 
+ echo or print to see what is inside 
+ them.  To view one element, you'd do something like 
+ echo $arr['foo'].  See below for tips on dumping/viewing the 
+ entire contents.
 
 
  Objects are always converted to the string "Object".
- If you would like to print out the member variable values of an object
- for debugging reasons, read the paragraphs below. If you would
- like to find out the class name of which an object is an instance of,
- use get_class.  
+ If you would like to print out the member variable values of an 
+ object for debugging reasons, read the paragraphs 
+ below. If you would like to find out the class name of which an object 
+ is an instance of, use get_class.
 
 
  Resources are always converted to strings with the structure
  "Resource id #1" where 1 is
- the unique number of the resource assigned by PHP during runtime.
+ the unique number of the resource assigned by PHP during runtime.
  If you would like to get the type of the resource, use
  get_resource_type.
 
@@ -1123,14 +1185,14 @@
  
 
  
@@ -1212,7 +1274,10 @@

 

@@ -1234,7 +1299,11 @@

 

@@ -1244,7 +1313

RE: [PHP-DOC] Suggestion for a clean PHP 5 - Manual

[Philip Olson]

On Thu, 23 Jan 2003, Timothy Hitchens (HiTCHO) wrote:

> A quick question why can't we build a PDF version I could put some
> resources into this if needed and I agree with a branch for a PHP5
> clean manual for the future.

Okay, spend time on an automated build of a full PHP manual
built into PDF format.  Ask Hartmut and Goba for details
on the current problems.

As I already stated, I strongly disagree with a new branch
for a PHP 5 manual.

Regards,
Philip


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

Re: [PHP-DOC] Suggestion for a clean PHP 5 - Manual

[Philip Olson]

On Wed, 22 Jan 2003, [ISO-8859-1] Thomas Schöfbeck wrote:
> Hi there,
> 
> looking at the current - esp. for newbies sometimes confusing - manual, 
> where several old info and even functions simply disappeared, but 
> several exlanations and even whole chapters (like 'Migrating from PHP/FI 
> 2 to PHP 3') for PHP 3 still exist, etc., one thought came into my mind:
> 
> Why not take the chance of the intro of PHP 5 and branch the existing 
> manual (still provide the last built version for download), take out all 
> the php 3 chapters (and step by step the old info) to have a clean - 
> structured - manaul explicitly for php 5 just with the differences to 
> the last php 4 version?

PHP 4 isn't much different than PHP 5.  Forking the manual this
way sounds like a lot of needless work.  I'm -1 on this idea as
it doesn't seem useful.  But maybe I'm misunderstanding you.

Regarding PHP 3 specific information, this indeed should be
moved but not simply deleted.  History is good.  Another idea 
would be to move all PHP 3 specific information into a PHP 3 
section and where the information was, point to it instead.  So 
something like:

  php3 note

This would replace the explanation with a link to the explanation 
in the PHP 3 specific section.  A section that once created will 
never need to be touched.  And I bet there are still a few PHP 3 
users out there :)

> P.S. Other questions like this will follow, like:
> 
> Since we aren't able to build a pdf-version due to a lack of resources: 
> Why don't we make the FAQ an extra document (esp. for 'bundled' builds 
> like chm, pdf, bightml, ... - I've never read a book where chap. 43 
> describes the same thing like chap. 3, just with a question as title ;)?

I see no need to split up the manual like this.  The only
split that makes sense is the developmental manual from
the users manual.  Anything else I disagree with.  The
faq is small and barely affects the overall size of the
PHP manual.  And, information overlap is small but it's 
similar information presented in a different more verbose
way.  The faq should remain in the manual as is.

Decisions should never be based off whether or not a PDF can
be created.  Eventually someone will come up with an idea
to make it work nomatter what size the manual becomes.

Regards,
Philip


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

[PHP-DOC] cvs: phpdoc / .cvsignore

[Friedhelm Betz]

betzWed Jan 22 18:07:55 2003 EDT

  Modified files:  
/phpdoc .cvsignore 
  Log:
  version independant exclusion of autoconfs cache
  
Index: phpdoc/.cvsignore
diff -u phpdoc/.cvsignore:1.35 phpdoc/.cvsignore:1.36
--- phpdoc/.cvsignore:1.35  Wed Jul 17 11:59:35 2002
+++ phpdoc/.cvsignore   Wed Jan 22 18:07:54 2003
@@ -37,4 +37,4 @@
 chmonly.xml
 installpart.xml
 reserved.constants.xml
-autom4te.cache
+autom4te-*



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

RE: [PHP-DOC] Suggestion for a clean PHP 5 - Manual

[Timothy Hitchens \(HiTCHO\)]

A quick question why can't we build a PDF version I could put some
resources into this if needed and I agree with a branch for a PHP5
clean manual for the future.


Timothy Hitchens (HiTCHO)
Open Source Consulting
e-mail: [EMAIL PROTECTED]

> -Original Message-
> From: Thomas Schöfbeck [mailto:[EMAIL PROTECTED]] 
> Sent: Thursday, 23 January 2003 8:48 AM
> To: [EMAIL PROTECTED]
> Subject: [PHP-DOC] Suggestion for a clean PHP 5 - Manual
> 
> 
> Hi there,
> 
> looking at the current - esp. for newbies sometimes confusing 
> - manual, 
> where several old info and even functions simply disappeared, but 
> several exlanations and even whole chapters (like 'Migrating 
> from PHP/FI 
> 2 to PHP 3') for PHP 3 still exist, etc., one thought came 
> into my mind:
> 
> Why not take the chance of the intro of PHP 5 and branch the existing 
> manual (still provide the last built version for download), 
> take out all 
> the php 3 chapters (and step by step the old info) to have a clean - 
> structured - manaul explicitly for php 5 just with the differences to 
> the last php 4 version?
> 
> Thomas
> 
> P.S. Other questions like this will follow, like:
> 
> Since we aren't able to build a pdf-version due to a lack of 
> resources: 
> Why don't we make the FAQ an extra document (esp. for 
> 'bundled' builds 
> like chm, pdf, bightml, ... - I've never read a book where chap. 43 
> describes the same thing like chap. 3, just with a question 
> as title ;)?
> 
> 
> -- 
> 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

[PHP-DOC] Suggestion for a clean PHP 5 - Manual

[Thomas Schöfbeck]

Hi there,

looking at the current - esp. for newbies sometimes confusing - manual, 
where several old info and even functions simply disappeared, but 
several exlanations and even whole chapters (like 'Migrating from PHP/FI 
2 to PHP 3') for PHP 3 still exist, etc., one thought came into my mind:

Why not take the chance of the intro of PHP 5 and branch the existing 
manual (still provide the last built version for download), take out all 
the php 3 chapters (and step by step the old info) to have a clean - 
structured - manaul explicitly for php 5 just with the differences to 
the last php 4 version?

Thomas

P.S. Other questions like this will follow, like:

Since we aren't able to build a pdf-version due to a lack of resources: 
Why don't we make the FAQ an extra document (esp. for 'bundled' builds 
like chm, pdf, bightml, ... - I've never read a book where chap. 43 
describes the same thing like chap. 3, just with a question as title ;)?


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

[PHP-DOC] cvs: phpdoc /en/reference/strings/functions wordwrap.xml

[Thomas Schoefbeck]

tom Wed Jan 22 16:42:05 2003 EDT

  Modified files:  
/phpdoc/en/reference/strings/functions  wordwrap.xml 
  Log:
  corr. example
  
Index: phpdoc/en/reference/strings/functions/wordwrap.xml
diff -u phpdoc/en/reference/strings/functions/wordwrap.xml:1.2 
phpdoc/en/reference/strings/functions/wordwrap.xml:1.3
--- phpdoc/en/reference/strings/functions/wordwrap.xml:1.2  Wed Apr 17 02:44:24 
2002
+++ phpdoc/en/reference/strings/functions/wordwrap.xml  Wed Jan 22 16:42:05 2003
@@ -1,5 +1,5 @@
 
-
+
 
   

@@ -60,8 +60,9 @@
  
   
 
   
  
@@ -86,9 +87,9 @@
  
   
 
   



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

[PHP-DOC] cvs: phpdoc /en/reference/strings/functions substr.xml

[Thomas Schoefbeck]

tom Wed Jan 22 16:38:26 2003 EDT

  Modified files:  
/phpdoc/en/reference/strings/functions  substr.xml 
  Log:
  closed open bracket
  
Index: phpdoc/en/reference/strings/functions/substr.xml
diff -u phpdoc/en/reference/strings/functions/substr.xml:1.5 
phpdoc/en/reference/strings/functions/substr.xml:1.6
--- phpdoc/en/reference/strings/functions/substr.xml:1.5Sun Jan 12 03:06:40 
2003
+++ phpdoc/en/reference/strings/functions/substr.xmlWed Jan 22 16:38:26 2003
@@ -1,5 +1,5 @@
 
-
+
 
   

@@ -49,7 +49,8 @@
 
  If start is negative, the returned string
  will start at the start'th character
- from the end of string.
+ from the end of string.
+
 
  Using a negative start
  
@@ -66,7 +67,7 @@
  If length is given and is positive, the string
  returned will contain at most length characters
  beginning from start (depending on the length of
- string. If string is less
+ string). If string is less
  than start characters long, &false; will be
  returned.
 



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

[PHP-DOC] cvs: phpdoc /en/reference/strings/functions sscanf.xml

[Thomas Schoefbeck]

tom Wed Jan 22 16:37:34 2003 EDT

  Modified files:  
/phpdoc/en/reference/strings/functions  sscanf.xml 
  Log:
  typo
  
Index: phpdoc/en/reference/strings/functions/sscanf.xml
diff -u phpdoc/en/reference/strings/functions/sscanf.xml:1.4 
phpdoc/en/reference/strings/functions/sscanf.xml:1.5
--- phpdoc/en/reference/strings/functions/sscanf.xml:1.4Sat Jul 27 00:07:06 
2002
+++ phpdoc/en/reference/strings/functions/sscanf.xmlWed Jan 22 16:37:33 2003
@@ -1,5 +1,5 @@
 
-
+
 
   

@@ -26,7 +26,7 @@
 
 
  Any whitespace in the format string matches any whitespace in the input
- string. This means that even a tab \n in the format string can match a
+ string. This means that even a tab \t in the format string can match a
  single space character in the input string.
 
 



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

[PHP-DOC] #21816 [Bgs->Asn]: preg_replace has problem with arrays

[pollita]

 ID:   21816
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Bogus
+Status:   Assigned
-Bug Type: *Regular Expressions
+Bug Type: Documentation problem
 Operating System: Windows XP
 PHP Version:  4.3.0
-Assigned To:  
+Assigned To:  pollita
 New Comment:

This could be made more clear in the manual.  I'll add a note and an
example tonight.


Previous Comments:


[2003-01-22 14:52:19] [EMAIL PROTECTED]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

The replacment is done in the order the array was created, if you want
it to be done based on array keys that run an appropriate sorting
function before executing the preg_replace function.



[2003-01-22 12:14:45] [EMAIL PROTECTED]

The search strings used in the preg_replace() function are regular
expressions. "[abc]" is a regular expression which matches any of the
characters "a", "b" or "c".

Either use str_replace() to replace your strings, or learn to use
regular expressions
.



[2003-01-22 08:41:20] [EMAIL PROTECTED]

" . $string2;
echo "Result should be: Say a [betterWord0] about
[betterWord1] and [betterWord2]";

// result should be:
//Say a [betterWord0] about [betterWord1] and [betterWord2]
//
// but produces: 
//Say a [betterWord0] about [betterWord2] and [betterWord1]
//
// Seems like the order in which i build my array
// is the order for replacing...and not the index
// of $array[$index]
//
// if you add a ksort it works fine:

ksort($search,SORT_NUMERIC);
ksort($replace,SORT_NUMERIC);   
reset($search);
reset($replace);

$string3 = preg_replace($search,$replace,$string);
echo "Corrected (ksort) Result is:" . $string3;

//
// Has someone an idea, about what's happening here?
//
// just a guy addicted to php ;-)
?>



[2003-01-22 07:43:39] [EMAIL PROTECTED]

" . $string;
echo "Result should be: Say a [betterWord0] about
[betterWord1] and [betterWord2]";

// result should be:
//Say a [betterWord0] about [betterWord1] and [betterWord2]
//
// but produces: 
//Say a [betterWord0] about [betterWord2] and [betterWord1]
//
// Seems like the order in which i build my array
// is the order for replacing...and not the index
// of $array[$index]
//
//
// Has someone an idea, about what's happening here?
//
// just a guy addicted to php ;-)
?>




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


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

Re: [PHP-DOC] session_start()

[Philip Olson]

>Hi
>
> I was reading the manual of session_start() at
> http://www.php.net/manual/en/function.session-start.php
> 
> But there's something strange to me. I find the following text in the 
> first paragraph:
> 
> session_start() creates a session (or resumes the current one based on 
> the session id being passed via a GET variable or a cookie).
> 
> It it really right that the session id can only be passed via GET 
> parameters? What about to post the session id?
> Maybe there's a documentation problem.

Thank you, the documentation has been updated.
http://cvs.php.net/cvs.php/phpdoc/en/reference/session/functions/session-start.xml

Regards,
Philip


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

[PHP-DOC] cvs: phpdoc /en/chapters install.solaris.xml

[Derick Rethans]

derick  Wed Jan 22 13:37:34 2003 EDT

  Modified files:  
/phpdoc/en/chapters install.solaris.xml 
  Log:
  - Add GNU sed as requirement
  
  
Index: phpdoc/en/chapters/install.solaris.xml
diff -u phpdoc/en/chapters/install.solaris.xml:1.1 
phpdoc/en/chapters/install.solaris.xml:1.2
--- phpdoc/en/chapters/install.solaris.xml:1.1  Wed Jan  9 18:52:08 2002
+++ phpdoc/en/chapters/install.solaris.xml  Wed Jan 22 13:37:33 2003
@@ -1,5 +1,5 @@
 
-
+
 
  Unix/Solaris installs
  
@@ -62,6 +62,11 @@
   tar
  
 
+
+ 
+  GNU sed
+ 
+

 In addition, you will need to install (and possibly compile) any
 additional software specific to your configuration, such as Oracle
@@ -96,4 +101,4 @@
 vim600: syn=xml fen fdm=syntax fdl=2 si
 vim: et tw=78 syn=sgml
 vi: ts=1 sw=1
--->
\ No newline at end of file
+-->



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

[PHP-DOC] cvs: phpdoc /en/reference/session/functions session-start.xml

[Philip Olson]

philip  Wed Jan 22 13:34:59 2003 EDT

  Modified files:  
/phpdoc/en/reference/session/functions  session-start.xml 
  Log:
  Closing concern brought up by Oliver Hinckel.  session gets id from request 
  data, not just get or cookie.
  
  
Index: phpdoc/en/reference/session/functions/session-start.xml
diff -u phpdoc/en/reference/session/functions/session-start.xml:1.3 
phpdoc/en/reference/session/functions/session-start.xml:1.4
--- phpdoc/en/reference/session/functions/session-start.xml:1.3 Mon Sep 16 16:42:35 
2002
+++ phpdoc/en/reference/session/functions/session-start.xml Wed Jan 22 13:34:59 
+2003
@@ -1,5 +1,5 @@
 
-
+
 
   

@@ -13,9 +13,9 @@
   
  
 
- session_start creates a session (or resumes
- the current one based on the session id being passed via a GET
- variable or a cookie).
+ session_start creates a session or resumes
+ the current one based on the current session id that's being 
+ passed via a request, such as GET, POST, or a cookie.
 
 
  If you want to use a named session, you must call



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

[PHP-DOC] session_start()

[Oliver Hinckel]

Hi,

I was reading the manual of session_start() at
http://www.php.net/manual/en/function.session-start.php

But there's something strange to me. I find the following text in the 
first paragraph:

session_start() creates a session (or resumes the current one based on 
the session id being passed via a GET variable or a cookie).

It it really right that the session id can only be passed via GET 
parameters? What about to post the session id?
Maybe there's a documentation problem.

Greetings
Oliver


--
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 imagettftext.xml

[Damien Seguy]

damsWed Jan 22 07:11:52 2003 EDT

  Modified files:  
/phpdoc/en/reference/image/functionsimagettftext.xml 
  Log:
  black is black!
  
Index: phpdoc/en/reference/image/functions/imagettftext.xml
diff -u phpdoc/en/reference/image/functions/imagettftext.xml:1.4 
phpdoc/en/reference/image/functions/imagettftext.xml:1.5
--- phpdoc/en/reference/image/functions/imagettftext.xml:1.4Wed Jan 22 07:06:29 
2003
+++ phpdoc/en/reference/image/functions/imagettftext.xmlWed Jan 22 07:11:52 
+2003
@@ -1,5 +1,5 @@
 
-
+
 
   

@@ -77,11 +77,11 @@
 http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Damien Seguy]

damsWed Jan 22 07:06:29 2003 EDT

  Modified files:  
/phpdoc/en/reference/image/functionsimagettftext.xml 
  Log:
  die, GIF, die!
  
Index: phpdoc/en/reference/image/functions/imagettftext.xml
diff -u phpdoc/en/reference/image/functions/imagettftext.xml:1.3 
phpdoc/en/reference/image/functions/imagettftext.xml:1.4
--- phpdoc/en/reference/image/functions/imagettftext.xml:1.3Thu Apr 18 13:13:10 
2002
+++ phpdoc/en/reference/image/functions/imagettftext.xmlWed Jan 22 07:06:29 
+2003
@@ -1,5 +1,5 @@
 
-
+
 
   

@@ -8,17 +8,17 @@


 Description
- 
-  arrayimagettftext
-  resourceimage
-  intsize
-  intangle
-  intx
-  inty
-  intcol
-  stringfontfile
-  stringtext
- 
+
+ arrayimagettftext
+ resourceim
+ intsize
+ intangle
+ intx
+ inty
+ intcol
+ stringfontfile
+ stringtext
+
 
  imagettftext draws the string
  text in the image identified by
@@ -29,7 +29,7 @@
  fontfile. Depending on which version of the GD
  library that PHP is using, when fontfile does not
  begin with a leading '/',  '.ttf' will be appended to the filename and
- the the library will attempt to search for that filename along a
+ the library will attempt to search for that filename along a
  library-defined font path.
 
 
@@ -40,17 +40,17 @@
  y define the upper-right corner of the first character.
 
 
- Angle is in degrees, with 0 degrees being
+ angle is in degrees, with 0 degrees being
  left-to-right reading text (3 o'clock direction), and higher
  values representing a counter-clockwise rotation.  (i.e., a value
  of 90 would result in bottom-to-top reading text).
 
 
- Fontfile is the path to the TrueType font
+ fontfile is the path to the TrueType font
  you wish to use.
 
 
- Text is the text string which may include
+ text is the text string which may include
  UTF-8 character sequences (of the form: {) to access
  characters in a font beyond the first 255.
 
@@ -71,17 +71,20 @@
  This example script will produce a black GIF 400x30 pixels, with
  the words "Testing..."  in white in the font Arial.
  
-  imagettftext
+  imagettftext example
   
 
   



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