Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard info.c
And I wonder why do you think it is so important to show the characters like eacute; or auml; in every browser... ? For me, to show correct multibyte characters in the gpc section would make more sense. Therefore I think the best solution is to keep the best visibility in the user's native charset / encoding. phpinfo() no longer encodes accented characters to eacute; or auml;. I changed this on Wed Oct 9 10:39:39 2002 in version 1.215 of info.c. As I said before, IE and Mozilla automatically changes the font preference if no suitable glyph for a character is found on rendering. So with some charsets, specifying the face name in CSS declaration has no effect. And? Isn't that what phpinfo() does now? No charset/encoding is specified, so IE/Moz automagically changes it. Please look at the attached HTML file and the image (the file would be dropped in the list). The HTML file is encoded in UTF-8 and the image is rendered by IE5.5 . Note that the font used to render the Japanese characters are not Arial Unicode MS but MS PGothic. Hope it helps. Well, it renders nicely under Mozilla for me too. I don't understand the point though, so here are my questions: 1) what is wrong with the way phpinfo() works *right now*? 2) what could/should be changed to fix it? If I call a page with phpinfo(), and pass it a query string with encoded chars, then I do see the _GET[var] part of the info in the Japanese characters, and all the rest of the page looks fine. i.e.: http://devel.easydns.com/~cmv/.info.php?var=%E6%97%A5%E6%9C%AC%E8%AA%9E This is under Moz 1.2 on my machine. - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard info.c
Hello, If you explicitly specify a charset, then you need to encode the characters according to that character set. The problem is, that encodings such as eacute; and Auml; (which show up on the credits page), don't work under all charsets/encodings. IMO this is alreadly accomplished with mbstring or iconv extension. And I wonder why do you think it is so important to show the characters like eacute; or auml; in every browser... ? For me, to show correct multibyte characters in the gpc section would make more sense. Therefore I think the best solution is to keep the best visibility in the user's native charset / encoding. I will test it again, with the charset declaration back in, but I'm relying on people with non-Western browsers and charsets for some feedback on how the choice of charset affects the rendering of the pages. As I said before, IE and Mozilla automatically changes the font preference if no suitable glyph for a character is found on rendering. So with some charsets, specifying the face name in CSS declaration has no effect. Please look at the attached HTML file and the image (the file would be dropped in the list). The HTML file is encoded in UTF-8 and the image is rendered by IE5.5 . Note that the font used to render the Japanese characters are not Arial Unicode MS but MS PGothic. Hope it helps. Moriyoshi Koizumi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard info.c
phpinfo() no longer encodes accented characters to eacute; or auml;. I changed this on Wed Oct 9 10:39:39 2002 in version 1.215 of info.c. I'm Sorry for taking your time. I missed the recent change about phpinfo. And I reconfirmed that the entity conversion doesn't affect multibyte characters. But we shouldn't rely on the automatic encoding detection too much. Moriyoshi Koizumi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard info.c
Why did you remove the charset info? I want my charset back since it enables correct handling of the output. Everything these lines commented out by you do is telling the receiver what charset he gets. That is compareable to http charset info which will be generated by those modules also. This way you can enable mbsting or iconv with any charset you like. This has nothing to do with the other thing you did in this patch: changing behaviour of php_escape_html_entities(). I guess you did not understand what you removed? No, I do understand what I did. Every browser I tested displayed the phpinfo() page correctly when the charset was not specified ... i.e., they guessed the right charset. If you explicitly specify a charset, then you need to encode the characters according to that character set. The problem is, that encodings such as eacute; and Auml; (which show up on the credits page), don't work under all charsets/encodings. I will test it again, with the charset declaration back in, but I'm relying on people with non-Western browsers and charsets for some feedback on how the choice of charset affects the rendering of the pages. - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard info.c
At 16:24 17.10.2002, Colin Viebrock wrote: Why did you remove the charset info? I want my charset back since it enables correct handling of the output. Everything these lines commented out by you do is telling the receiver what charset he gets. That is compareable to http charset info which will be generated by those modules also. This way you can enable mbsting or iconv with any charset you like. This has nothing to do with the other thing you did in this patch: changing behaviour of php_escape_html_entities(). I guess you did not understand what you removed? No, I do understand what I did. Every browser I tested displayed the phpinfo() page correctly when the charset was not specified ... i.e., they guessed the right charset. If you explicitly specify a charset, then you need to encode the characters according to that character set. The problem is, that encodings such as eacute; and Auml; (which show up on the credits page), don't work under all charsets/encodings. We only show what we do this way. In other way we declare the charset used in the TRANSPORT LAYER. Please read w3c documentation: http://www.w3.org/TR/html401/struct/global.html#adef-http-equiv [...] META and default information The META element may be used to specify the default information for a document in the following instances: [...] · The document character encoding. The following example specifies the character encoding for a document as being ISO-8859-5 META http-equiv=Content-Type content=text/html; charset=ISO-8859-5 [...] and also the referred document: http://www.w3.org/TR/html401/charset.html#doc-char-set [...] For example, to specify that the character encoding of the current document is EUC-JP, a document should include the following META declaration: META http-equiv=Content-Type content=text/html; charset=EUC-JP The META declaration must only be used when the character encoding is organized such that ASCII-valued bytes stand for ASCII characters (at least until the META element is parsed). META declarations should appear as early as possible in the HEAD element. For cases where neither the HTTP protocol nor the META element provides information about the character encoding of a document, HTML also provides the charset attribute on several elements. By combining these mechanisms, an author can greatly improve the chances that, when the user retrieves a resource, the user agent will recognize the character encoding. To sum up, conforming user agents must observe the following priorities when determining a document's character encoding (from highest priority to lowest): 1. An HTTP charset parameter in a Content-Type field. 2. A META declaration with http-equiv set to Content-Type and a value set for charset. 3. The charset attribute set on an element that designates an external resource. [...] I will test it again, with the charset declaration back in, but I'm relying on people with non-Western browsers and charsets for some feedback on how the choice of charset affects the rendering of the pages. - Colin
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard info.c
Why did you remove the charset info?
I want my charset back since it enables correct handling of the output.
Everything these lines commented out by you do is telling the receiver
what charset he gets. That is compareable to http charset info which
will be generated by those modules also. This way you can enable
mbsting or iconv with any charset you like.
This has nothing to do with the other thing you did in this patch:
changing behaviour of php_escape_html_entities(). I guess you did
not understand what you removed?
marcus
At 16:39 09.10.2002, Colin Viebrock wrote:
cmv Wed Oct 9 10:39:40 2002 EDT
Modified files:
/php4/ext/standard info.c
Log:
no charsets, only basic entity escaping
Index: php4/ext/standard/info.c
diff -u php4/ext/standard/info.c:1.214 php4/ext/standard/info.c:1.215
--- php4/ext/standard/info.c:1.214 Sun Oct 6 13:04:10 2002
+++ php4/ext/standard/info.cWed Oct 9 10:39:39 2002
-18,7 +18,7
+--+
*/
-/* $Id: info.c,v 1.214 2002/10/06 17:04:10 rasmus Exp $ */
+/* $Id: info.c,v 1.215 2002/10/09 14:39:39 cmv Exp $ */
#include php.h
#include php_ini.h
-191,7 +191,7
PHPAPI char *php_info_html_esc(char *string TSRMLS_DC)
{
int new_len;
- return php_escape_html_entities(string, strlen(string), new_len,
1, ENT_COMPAT, NULL TSRMLS_CC);
+ return php_escape_html_entities(string, strlen(string), new_len,
0, ENT_NOQUOTES, NULL TSRMLS_CC);
}
/* }}} */
-277,6 +277,9
*/
PHPAPI void php_print_info_htmlhead(TSRMLS_D)
{
+
+/*** none of this is needed now ***
+
const char *charset = NULL;
if (SG(default_charset)) {
-303,12 +306,17
charset = US-ASCII;
}
+*** none of that is needed now ***/
+
+
PUTS(!DOCTYPE html PUBLIC \-//W3C//DTD XHTML 1.0
Transitional//EN\ \DTD/xhtml1-transitional.dtd\\n);
PUTS(html);
PUTS(head\n);
php_info_print_style();
PUTS(titlephpinfo()/title);
+/*
php_printf(meta http-equiv=\Content-Type\
content=\text/html; charset=%s\ /\n, charset);
+*/
PUTS(/head\n);
PUTS(bodycenter\n);
}
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard info.c
Wez Furlong wrote: wez Sat Oct 5 06:55:54 2002 EDT Modified files: /php4/ext/standard info.c Log: Fix Win32 build as PHP_CONFIG_FILE_SCAN_DIR is not #defined. I added PHP_CONFIG_FILE_SCAN_DIR to config.w32.h.in already. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard info.c
This is a bit too unserious IMHO.
Edin
On Sat, 07 Sep 2002 23:14:23 -
Jan Lehnardt [EMAIL PROTECTED] wrote:
jan Sat Sep 7 19:14:23 2002 EDT
Modified files:
/php4/ext/standardinfo.c
Log:
- cosmetics
Index: php4/ext/standard/info.c
diff -u php4/ext/standard/info.c:1.199 php4/ext/standard/info.c:1.200
--- php4/ext/standard/info.c:1.199Fri Sep 6 03:27:26 2002
+++ php4/ext/standard/info.c Sat Sep 7 19:14:22 2002
@@ -17,7 +17,7 @@
+
--+
*/
-/* $Id: info.c,v 1.199 2002/09/06 07:27:26 hyanantha Exp $ */
+/* $Id: info.c,v 1.200 2002/09/07 23:14:22 jan Exp $ */
#include php.h
#include php_ini.h
@@ -300,7 +300,12 @@
php_printf(titlephpinfo()/titlemeta
http-equiv=\Content-Type\ content=\text/html;
charset=%s\/head, charset); PUTS(body text=\#00\
bgcolor=\#f0f0ff\ link=\#ff\ vlink=\#ff00ff\
alink=\#ff\);
} else {
- PUTS(phpinfo()\n);
+PUTS( _ ___ \n);
+PUTS( _ __ | |__ _ __ (_)_ __ / _| ___ / /\\ \\ \n);
+PUTS(| '_ \\| '_ \\| '_ \\| | '_ \\| |_ / _ \\| | | |\n);
+PUTS(| |_) | | | | |_) | | | | | _| (_) | | | |\n);
+PUTS(| .__/|_| |_| .__/|_|_| |_|_| \\___/| | | |\n);
+PUTS(|_| |_| \\_\\/_/ \n\n);
}
if (flag PHP_INFO_GENERAL) {
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard info.c /main php_ini.c
Jan Lehnardt wrote: jan Wed Aug 28 18:31:52 2002 EDT Modified files: /php4/main php_ini.c /php4/ext/standard info.c Log: - add phpinfo() support for CLI. phpinfo() support for CLI (jan) This broke the ZTS build. After 30 minutes of TSRMLS_D/DC/C/CC additions all over the place (I had to touch every extension, fi.) I gave up, because the implementation of the feature itself is discussed on php-dev... -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard info.c
On Thu, 2002-08-29 at 01:51, Yasuo Ohgaki wrote: Marcus Börger wrote: Not that mod_apache delivering txt format info pages would be unusable but a simple phpinfo(0|1) would be better. I would like to see phpinfo(true|false) What about phpinfo(PHPINFO_OF_TEXT|PHPINFO_OF_HTML|...) This way, new output formats could be easily added. -- Timm -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard info.c
On 29 Aug 2002, Timm Friebe wrote: On Thu, 2002-08-29 at 01:51, Yasuo Ohgaki wrote: Marcus Börger wrote: Not that mod_apache delivering txt format info pages would be unusable but a simple phpinfo(0|1) would be better. I would like to see phpinfo(true|false) What about phpinfo(PHPINFO_OF_TEXT|PHPINFO_OF_HTML|...) This way, new output formats could be easily added. Sounds like a bit like overdesigning things... the current implementation (if the ZTS build is fixed) is just fine. Derick --- Did I help you? http://www.derickrethans.nl/link.php?url=giftlist Frequent ranting: http://www.derickrethans.nl/ --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard info.c /main php_ini.c
At 09:12 29.08.2002, Sebastian Bergmann wrote: Jan Lehnardt wrote: jan Wed Aug 28 18:31:52 2002 EDT Modified files: /php4/main php_ini.c /php4/ext/standard info.c Log: - add phpinfo() support for CLI. phpinfo() support for CLI (jan) This broke the ZTS build. After 30 minutes of TSRMLS_D/DC/C/CC additions all over the place (I had to touch every extension, fi.) I gave up, because the implementation of the feature itself is discussed on php-dev... Perhaps you could apply your patch to info.c and php_ini.c and perhaps the extension developers will then add the rest of the stuff themselves. The other solution would be to remove that patch what would be no good idea. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard info.c
On Thu, Aug 29, 2002 at 10:34:05AM +0200, Timm Friebe wrote : On Thu, 2002-08-29 at 01:51, Yasuo Ohgaki wrote: Marcus Börger wrote: Not that mod_apache delivering txt format info pages would be unusable but a simple phpinfo(0|1) would be better. I would like to see phpinfo(true|false) What about phpinfo(PHPINFO_OF_TEXT|PHPINFO_OF_HTML|...) This way, new output formats could be easily added. It seems you all forgot about that phpinfo() already takes one optional parameter ... So this would be phpinfo(INFO_ALL, INFO_HTML|INFO_PDF|INFO_WHATEVER); It's nice (and definitely needed for php -i for cli) but if it's worth to do has to be decided by the one who will implement it ;-) - Markus -- GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc Finally, if someone actually flying a plane is relying on a freakin' webcam to land, we're all in trouble. - A /. poster. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard info.c /mainphp_ini.c
On Thu, 29 Aug 2002, Marcus Börger wrote: Perhaps you could apply your patch to info.c and php_ini.c and perhaps the extension developers will then add the rest of the stuff themselves. The other solution would be to remove that patch what would be no good idea. Or you can just wait until the original author fixes it. Derick --- Did I help you? http://www.derickrethans.nl/link.php?url=giftlist Frequent ranting: http://www.derickrethans.nl/ --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard info.c
Jan Lehnardt wrote: jan Thu Aug 29 05:11:22 2002 EDT Modified files: /php4/ext/standard info.c Log: - fix ZTS build. thanks to edin. It builds now, yes. But the HTML output looks broken to me. FI, the Registered PHP Streams are all on one line, values for directives like auto_append_file, auto_prepend_file, ... are empty. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard info.c
Hi, On Thu, Aug 29, 2002 at 11:26:20AM +0200, Sebastian Bergmann wrote: Jan Lehnardt wrote: jan Thu Aug 29 05:11:22 2002 EDT Modified files: /php4/ext/standard info.c Log: - fix ZTS build. thanks to edin. It builds now, yes. But the HTML output looks broken to me. FI, the Registered PHP Streams are all on one line, values for directives like auto_append_file, auto_prepend_file, ... are empty. do they show up in the html version? Jan -- Q: Thank Jan? A: http://geschenke.an.dasmoped.net/ Got an old and spare laptop? Please send me a mail. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard info.c
Hi, forget my last message. If you don't specify a prepend file the value is empty, isn't it? Jan -- Q: Thank Jan? A: http://geschenke.an.dasmoped.net/ Got an old and spare laptop? Please send me a mail. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard info.c
Jan Lehnardt wrote: If you don't specify a prepend file the value is empty, isn't it? Have a look at http://www.sebastian-bergmann.de/stuff/head.htm and http://www.sebastian-bergmann.de/stuff/423rc1.htm You'll notice that the no value values are missing. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard info.c
Hi, fixed in CVS. Jan -- Q: Thank Jan? A: http://geschenke.an.dasmoped.net/ Got an old and spare laptop? Please send me a mail. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard info.c /main php_ini.c
Did i recognize this correctly: You assume html_errors=on to differentiate wehther or not to return html? Wouldn't it be better to have this beeing a parameter to all info relevant functions and settings this to 0 in case of sapi cli? marcus At 00:31 29.08.2002, you wrote: jan Wed Aug 28 18:31:52 2002 EDT Modified files: /php4/main php_ini.c /php4/ext/standard info.c Log: - add phpinfo() support for CLI. phpinfo() support for CLI (jan) -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard info.c /main php_ini.c
Hi, On Thu, Aug 29, 2002 at 12:58:52AM +0200, Marcus Börger wrote: Did i recognize this correctly: You assume html_errors=on to differentiate wehther or not to return html? what else could be the purpose of html_errors. Wouldn't it be better to have this beeing a parameter to all info relevant functions and settings this to 0 in case of sapi cli? what do you mean? -- Q: Thank Jan? A: http://geschenke.an.dasmoped.net/ Got an old and spare laptop? Please send me a mail. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard info.c /main php_ini.c
At 01:06 29.08.2002, Jan Lehnardt wrote: Hi, On Thu, Aug 29, 2002 at 12:58:52AM +0200, Marcus Börger wrote: Did i recognize this correctly: You assume html_errors=on to differentiate wehther or not to return html? what else could be the purpose of html_errors. But you could disable this in all modules and then even mod_apache will send phpinfo() in txt format. Wouldn't it be better to have this beeing a parameter to all info relevant functions and settings this to 0 in case of sapi cli? what do you mean? I thought of implementing it myself just before you wrote you're at it. And my idea was to expand all functions used for the info stuff to select the format of the output: html or txt. Not that mod_apache delivering txt format info pages would be unusable but a simple phpinfo(0|1) would be better. regards marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard info.c
Marcus Börger wrote: Not that mod_apache delivering txt format info pages would be unusable but a simple phpinfo(0|1) would be better. I would like to see phpinfo(true|false) -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard info.c
Marcus Börger wrote: Not that mod_apache delivering txt format info pages would be unusable but a simple phpinfo(0|1) would be better. I would like to see phpinfo(true|false) -1 I don't think there is a need to add an option to phpinfo(). If it's such a big deal that this patch uses html_errors (which most people have on anyway), change it to use something else instead of adding new parameters. I wouldn't personally mind if it stayed like it is in the CVS now. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard info.c
Edin Kadribasic wrote: Marcus Börger wrote: Not that mod_apache delivering txt format info pages would be unusable but a simple phpinfo(0|1) would be better. I would like to see phpinfo(true|false) -1 I don't think there is a need to add an option to phpinfo(). If it's such a big deal that this patch uses html_errors (which most people have on anyway), change it to use something else instead of adding new parameters. I wouldn't personally mind if it stayed like it is in the CVS now. Not a big deal I agree. We can do php -r print_r(ini_get_all()) or ini_set() before phpinfo(). IMO, using html_errors flag to change phpinfo() behavior is not nice, though. phpinfo() is not a error :) I prefer less php.ini settings whenever possible/without good reason. Therefore, I vote +1 for phpinfo(true|false). -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
