Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard css.c
On Wed, 2002-10-09 at 09:35, Yasuo Ohgaki wrote: Colin Viebrock wrote: I really think the best solution (not perfect, but best) is to specify some fonts so the pages look nice, and hard code in the ISO-8859-1 font hard code in the ISO-8859-1 font means assuming ISO 8859-1 and use ISO 8859-1 type face by converting chars to entities? Take a look at this page, for example. http://czyborra.com/charsets/iso8859.html Do you see converting text to entity assuming ISO 8859-1 breaks not only multibyte encoding but also other ISO 8859 encoding? I'm well aware of that I'm suggesting to make phpinfo() non XHTML, since it is more useful if it is not confirm XHTML perfectly. If use of HTML entities are preferred, only text that needs HTML entities should use entities. e.g. Names. Isn't using entities for names or like enough? Please no automatic entity conversion assuming ISO 8859-1. Thanks. A bit late, but I'd like to throw in my .02EUR. When dealing with multiple languages, the only reasonable charset to support internally is Unicode, encoded in utf-8. Now, while MSIE supports utf-8, it doesn't sent the Accept-Encoding header. NS4 is AFAIK the only browser that explicitly announces being able to handle utf-8 in the request, but it's not a big issue to figure out if the user agent is from a browser that can deal with utf-8. The real solution would be using iconv on the output buffer to change the utf-8 to whatever charset the browser prefers, or if iconv is not available, try converting to 8859-1 and replace characters that don't fit to ?. IMHO this is the only thing that will work for everyone. - Stig -- Stig Sæther Bakken, Fast Search Transfer ASA, Trondheim, Norway http://pear.php.net/wishlist.php/ssb -- 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 css.c
At 01:40 02.11.2002, Stig S. Bakken wrote: On Wed, 2002-10-09 at 09:35, Yasuo Ohgaki wrote: Colin Viebrock wrote: I really think the best solution (not perfect, but best) is to specify some fonts so the pages look nice, and hard code in the ISO-8859-1 font hard code in the ISO-8859-1 font means assuming ISO 8859-1 and use ISO 8859-1 type face by converting chars to entities? Take a look at this page, for example. http://czyborra.com/charsets/iso8859.html Do you see converting text to entity assuming ISO 8859-1 breaks not only multibyte encoding but also other ISO 8859 encoding? I'm well aware of that I'm suggesting to make phpinfo() non XHTML, since it is more useful if it is not confirm XHTML perfectly. If use of HTML entities are preferred, only text that needs HTML entities should use entities. e.g. Names. Isn't using entities for names or like enough? Please no automatic entity conversion assuming ISO 8859-1. Thanks. A bit late, but I'd like to throw in my .02EUR. When dealing with multiple languages, the only reasonable charset to support internally is Unicode, encoded in utf-8. Now, while MSIE supports utf-8, it doesn't sent the Accept-Encoding header. NS4 is AFAIK the only browser that explicitly announces being able to handle utf-8 in the request, but it's not a big issue to figure out if the user agent is from a browser that can deal with utf-8. The real solution would be using iconv on the output buffer to change the utf-8 to whatever charset the browser prefers, or if iconv is not available, try converting to 8859-1 and replace characters that don't fit to ?. IMHO this is the only thing that will work for everyone. Since mbstring is better integrated in php i HOPE that will be done by mbstring (and it is not even dependant on another library). 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 css.c
Hi, Although I have no font problem differently to yasuo, (Actually I have got Arial Unicode MT) but I've experienced character encoding problem since your recent patch on ext/standard/info.c. How come you concluded that part is unnecesary? I really think the best solution (not perfect, but best) is to specify some fonts so the pages look nice, and hard code in the ISO-8859-1 font. I think it would not be the best solution, but just the last one of best solutions we could choose. AFAIK, IE and Mozilla automatically substitute the font when a character being displayed is not a part of the font which has been determined best for the specified encoding after HTML(or XML) parsing, even if that character is described in HTML entity form. I think there is few browsers that may have CSS font/encoding related problem. But I don't see XHTML conformance could be a good reason to discard the support for encodings other than ISO-8859-1... Hmm, I could say there are actually many users in Japan who use phpinfo() to check if the proper value have been submitted by the browser in the proper encoding... Yet I have to say it's always problematic because of the lack of commonly accepted specification for the encoding(not about url-encoding) used in url-embedded (namely I mean GET method) queries. Regards, 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 css.c
On Wed, 9 Oct 2002, Yasuo Ohgaki wrote: Colin Viebrock wrote: This is getting a little more complicated than I think is necessary. There are two issues here, I think: a) Fonts. Some people didn't like Arial, so I reverted to letter the browser decide. Some people didn't like that, and they'd like the font specifications back in. This will simply break output under some browser. It's more important to show info, but show a little nicely on some systems while printing garages on some systems. If anyone prefer any specific font, they should use their own CSS. For once I agree with yasuo here :) phpinfo() doesn't need to look pretty, it's for _debug_ output. Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- 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 css.c
On 10/09/02, Yasuo Ohgaki [EMAIL PROTECTED] wrote: AFAIK, there is no Arial that includes CJK. Arial Unicode MS (that 22MB TTF you'll find in \windows\fonts) seems to do a good job of including virtually all characters known to man. BTW: Colin - there is a bug report about phpinfo() - you are not efree()ing your htmlentities()-ed strings and that causes a load avg. of 2 when PHP shuts down and cleans up and warns about it 380+ times :-) The bug report is titled something like php causes a load avg of 2. --Wez. -- 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 css.c
At 08:34 9-10-2002, Derick Rethans wrote: For once I agree with yasuo here :) phpinfo() doesn't need to look pretty, it's for _debug_ output. Which means it needs to be as clear as possible. Formatting it for readibility is a plus - you don't want output that's hard to read, as you're already debugging. But if this breaks stuff for a certain charset/encoding/fontspec combination, than it should be removed, for the very same reason, as it's not readable. [ I just wish, W3C and browser vendors would get on the same page for once, sigh ] Met vriendelijke groeten / With kind regards, Webmaster IDG.nl Melvyn Sopacua -- 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 css.c
Wez Furlong wrote: On 10/09/02, Yasuo Ohgaki [EMAIL PROTECTED] wrote: AFAIK, there is no Arial that includes CJK. Arial Unicode MS (that 22MB TTF you'll find in \windows\fonts) seems to do a good job of including virtually all characters known to man. Hmm... I don't have it under my W2k. MS Japan should provide it :) -- Yasuo Ohgaki -- 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 css.c
Log: don't define fonts ... use the browser defaults Reason being? Yasuo Ohgaki's post earlier today said: First problem, CSS should not contain specific font name. Otherwise, characters may be broken under some browsers when font does not have type faces needed. Although, to be honest, I think his problem is more with the character set that is being sent with phpinfo pages. I'm guessing he has a Japanese version of Arial, that's missing some of the characters like eactue; etc.. Since the page is probably outputting charset=shift-JIS or whatever, the page looks broken. I'm waiting to hear a response from him on this issue, which might affect my changes to the css page. The definitions end in generic font families. There's no shame in defining a __readable__ __preference__. Especially Andale Mono, since it is one of the few monotype fonts, that has a readable difference between the l and a 1 and the O and 0. I've seen more people fiddling with their fonts, because they're pretty than because they're readable. Docs should aim to be readable. Agreed. Which is why the default fonts on people's browsers should be set to be readable already, no? Also, some people have emailed suggesting I remove them because of the CSS styling that they apply themselves to the phpinfo() output, using their own font defs. What's more problematic in the css code below, is the 75% default on td/th. If you nest that, the inner td, is 75% of 75% of the body. But there is no nesting of tables in phpinfo()'s output. - 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 css.c
At 00:28 9-10-2002, Colin Viebrock wrote: Log: don't define fonts ... use the browser defaults Reason being? Yasuo Ohgaki's post earlier today said: First problem, CSS should not contain specific font name. Otherwise, characters may be broken under some browsers when font does not have type faces needed. I've had this discussion with respect to the euro-sign also. Apparently, there are 2 different standards, which define different places for the euro sign in fonts - one on the 'international currency' glyph, and the 'microsoft' way, in unicode, with an OS-hack for non-unicode fonts. [1] I lack the specifics right now, but can look them up if you're interested. Although, to be honest, I think his problem is more with the character set that is being sent with phpinfo pages. I'm guessing he has a Japanese version of Arial, that's missing some of the characters like eactue; etc.. Since the page is probably outputting charset=shift-JIS or whatever, the page looks broken. Agreed, as [1] is a problem with the font implementation and should be taken up with the vendor of either the font or the OS. 'The web' cannot be held responsible for how the browser interprets euro; (or a charset header and bytes from a different one for that matter). I'm waiting to hear a response from him on this issue, which might affect my changes to the css page. The definitions end in generic font families. There's no shame in defining a __readable__ __preference__. Especially Andale Mono, since it is one of the few monotype fonts, that has a readable difference between the l and a 1 and the O and 0. I've seen more people fiddling with their fonts, because they're pretty than because they're readable. Docs should aim to be readable. Agreed. Which is why the default fonts on people's browsers should be set to be readable already, no? For a sysadmin yes. For a designer (large group of new users, since articles on flash+php seem to emerge everywhere) that's questionable :-) The CSS mechanism was however designed to express preferences and fallback. Also, some people have emailed suggesting I remove them because of the CSS styling that they apply themselves to the phpinfo() output, using their own font defs. Ehm - that is what user-defined stylesheets on the client are for. And settings like 'always use my fonts'. But anyway - not worth a long discussion - just a tiny bit worried about bogusing bug reports like 'phpinfo page suddenly looks weird'. And it's already much better than deprecated font-tags :-) What's more problematic in the css code below, is the 75% default on td/th. If you nest that, the inner td, is 75% of 75% of the body. But there is no nesting of tables in phpinfo()'s output. yet :-) - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php Met vriendelijke groeten / With kind regards, Webmaster IDG.nl Melvyn Sopacua -- 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 css.c
Colin Viebrock wrote: I'm waiting to hear a response from him on this issue, which might affect my changes to the css page. You forgot to disable automatic char to entities conversion e.g. Followings cannot be Japanese text obviously Ccedil;macr; 9middot;icirc; 9AElig;uuml; middot;icirc;Iacute;Euml;AElig;uuml; This is EUC-JP text output from phpinfo(), btw. -- Yasuo Ohgaki -- 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 css.c
Colin Viebrock wrote: Yasuo Ohgaki's post earlier today said: First problem, CSS should not contain specific font name. Otherwise, characters may be broken under some browsers when font does not have type faces needed. Although, to be honest, I think his problem is more with the character set that is being sent with phpinfo pages. I'm guessing he has a It is well known font issue. Some browser won't try to use other fonts when font specified is missing type faces. If you really would like to list specific font, list CJK and other fonts first then western fonts. Anyway, you have been resolved this. Japanese version of Arial, that's missing some of the characters like eactue; etc.. Since the page is probably outputting charset=shift-JIS or whatever, the page looks broken. AFAIK, there is no Arial that includes CJK. -- Yasuo Ohgaki -- 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 css.c
This is getting a little more complicated than I think is necessary. There are two issues here, I think: a) Fonts. Some people didn't like Arial, so I reverted to letter the browser decide. Some people didn't like that, and they'd like the font specifications back in. I'm going to add the font specifications back in again. I like Arial, personally, but I will put Verdana as the first font. This is in keeping with the look of php.net anyway, so I can justify it. There is nothing stopping anyone from specifying use my own fonts in their browsers. b) Charsets. I don't pretend to know what the charset deciding code in ext/standard/info.c is trying to do. I guess it's looking to see if your browser supports multi-byte charsets, or what encoding you prefer ... and then defaulting to US-ASCII if nothing else works. Seemed reasonable to me. I suppose, what Yasuo has pointed out, is that some (many? all?) multibyte fonts or versions of those fonts don't support the HTML entity encoding that is used on some of the phpinfo() pages ... mainly people's names in the credits pages, but also any or or that show up in other data. These need to be encoded *somehow* if the page is to be XHTML compatible, and I'm not about to implement utf8_encode() in C. :) I don't know what the solution to this is. My instinct is to ask why don't we just hardcode the pages to use US-ASCII, or ISO-8859-1? Would this not solve the charset issues? - 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 css.c
Colin Viebrock wrote: This is getting a little more complicated than I think is necessary. There are two issues here, I think: a) Fonts. Some people didn't like Arial, so I reverted to letter the browser decide. Some people didn't like that, and they'd like the font specifications back in. This will simply break output under some browser. It's more important to show info, but show a little nicely on some systems while printing garages on some systems. If anyone prefer any specific font, they should use their own CSS. I don't know what the solution to this is. My instinct is to ask why don't we just hardcode the pages to use US-ASCII, or ISO-8859-1? Would this not solve the charset issues? No. Why you bother? Letting browser decide is more feasible and most importantly, it works. If you are not certain how to make phpinfo() work under most environment, I can help. -- Yasuo Ohgaki -- 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 css.c
a) Fonts. Some people didn't like Arial, so I reverted to letter the browser decide. Some people didn't like that, and they'd like the font specifications back in. This will simply break output under some browser. It's more important to show info, but show a little nicely on some systems while printing garages on some systems. But the old phpinfo() specified fonts, so are you saying it was broken then too? If anyone prefer any specific font, they should use their own CSS. But I bet 99% of the people will have versions of either Arial or Verdana or Helvetica that *will* work. Why not make life easier for the majority, since the 1% is going to have to specify their own font anyway? I don't know what the solution to this is. My instinct is to ask why don't we just hardcode the pages to use US-ASCII, or ISO-8859-1? Would this not solve the charset issues? No. Why you bother? Letting browser decide is more feasible and most importantly, it works. Okay ... so don't output the charset meta tag at all? If you are not certain how to make phpinfo() work under most environment, I can help. If you can make it work under most environment *and* look good (i.e. as much like it used to, sans-serif fonts and all), then great! CVS is a wonderful thing. :) - 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 css.c
Colin Viebrock wrote: a) Fonts. Some people didn't like Arial, so I reverted to letter the browser decide. Some people didn't like that, and they'd like the font specifications back in. This will simply break output under some browser. It's more important to show info, but show a little nicely on some systems while printing garages on some systems. But the old phpinfo() specified fonts, so are you saying it was broken then too? Yes and No. It works withh my browser, but I just happen to know some browsers do not like it. Let's be more conservative. I don't know what the solution to this is. My instinct is to ask why don't we just hardcode the pages to use US-ASCII, or ISO-8859-1? Would this not solve the charset issues? No. Why you bother? Letting browser decide is more feasible and most importantly, it works. Okay ... so don't output the charset meta tag at all? That's better. And you must not try to convert chars to entities. This is the worst thing... Text cannot be read even with HTML sources. -- Yasuo Ohgaki -- 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 css.c
Yes and No. It works withh my browser, but I just happen to know some browsers do not like it. Let's be more conservative. I'd rather have a nice looking page that works on 99% of the browsers, than a not-so-nice looking one that works on 100%. Okay ... so don't output the charset meta tag at all? That's better. And you must not try to convert chars to entities. This is the worst thing... Text cannot be read even with HTML sources. But the characters need to be converted. It isn't valid XHTML if we don't specify a charset. Testing on Mozilla, if I have a document that contains: Hello Theacute;o, welcome to my Straße! This only renders completely properly if the charset is ISO-8859-1. HTML entities render in UTF-8 and US-ASCII, but the ß does not. Even using the character set your emails to me come in (ISO-2022-JP) renders the HTML entities correctly, but fails on the un-encoded character. I really think the best solution (not perfect, but best) is to specify some fonts so the pages look nice, and hard code in the ISO-8859-1 font. - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
