Re: [WSG] utf8 character display problem

2009-07-07 Thread Nick Roper 

Many thanks Andrew

Nick

Andrew Cunningham wrote:
Richard Ishida's i18n checker is a useful tool for this type of case. 
Available at



http://rishida.net/tools/i18nchecker/index.php



Rimantas Liubertas wrote:


Here's the issue:

We are working on a site that incorporates Russian text. It displays 
OK on
our development server, but when transferring the files to the live 
server

we get garbled output.


<…>
 
However, the same file uploaded to the live server displays the last 
menu

item incorrectly:

http://www.imperial-russian-dating.com/utf8-test.php

The file has been saved as utf8 encoded in the editor (Komodo) and then
uploaded to each server.

Any ideas ?



There are headers sent by your live server:
Connection:close
Content-Length:862
Content-Type:text/html; charset=ISO-8859-1
Date:Tue, 07 Jul 2009 16:22:43 GMT
Server:Apache/2.2.3 (CentOS)
X-Powered-By:PHP/5.1.6

Take a look at Content-Type header: it specifies charset as 
iso-8859-1. Charset

specified in HTTP has preference over charset in META. If you have
access to your
server configuration look for AddDefaultCharset directive in Apache
config. You can either
change it to UTF or comment it out.

Regards,
Rimantas
--
http://rimantas.com/


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

  




--
Nick Roper
partner
logical elements
innovative web and internet solutions
zend/php & mysql approved partner
email: nro...@logical.co.uk
phone: +44 (0)1749 676798
mobile: +44 (0)7590 538686
web: www.logical.co.uk
skype: nick.roper / +44 20 7870 9587

logical elements, 34, Chamberlain St, Wells, Somerset, BA5 2PJ, UK
---

IMPORTANT This communication is to be treated as confidential and the 
information in it may not be used or disclosed except for the purpose 
for which it has been sent. If you have reason to believe that you are 
not the intended recipient of this communication, please contact the 
sender immediately. Any views or opinions expressed in this email may 
not be those of Logical Elements.


WARNING Computer viruses can be transmitted by E-Mail. The recipient 
should check this E-Mail and any attachments for the presence of 
viruses. Logical Elements accepts no liability for any damage caused by 
any virus transmitted by this E-Mail. This E-mail and any attachments 
may not be copied or forwarded without the express permission of Logical 
Elements. In the event of any unauthorised copying or forwarding, the 
recipient will be required to indemnify Logical Elements against any 
claim for loss or damage caused by any viruses or otherwise.



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] utf8 character display problem

2009-07-07 Thread Andrew Cunningham 
Richard Ishida's i18n checker is a useful tool for this type of case. 
Available at



http://rishida.net/tools/i18nchecker/index.php



Rimantas Liubertas wrote:


Here's the issue:

We are working on a site that incorporates Russian text. It displays OK on
our development server, but when transferring the files to the live server
we get garbled output.


<…>
  

However, the same file uploaded to the live server displays the last menu
item incorrectly:

http://www.imperial-russian-dating.com/utf8-test.php

The file has been saved as utf8 encoded in the editor (Komodo) and then
uploaded to each server.

Any ideas ?



There are headers sent by your live server:
Connection:close
Content-Length:862
Content-Type:text/html; charset=ISO-8859-1
Date:Tue, 07 Jul 2009 16:22:43 GMT
Server:Apache/2.2.3 (CentOS)
X-Powered-By:PHP/5.1.6

Take a look at Content-Type header: it specifies charset as iso-8859-1. Charset
specified in HTTP has preference over charset in META. If you have
access to your
server configuration look for AddDefaultCharset directive in Apache
config. You can either
change it to UTF or comment it out.

Regards,
Rimantas
--
http://rimantas.com/


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

  


--
Andrew Cunningham
Senior Manager, Research and Development
Vicnet
State Library of Victoria
328 Swanston Street
Melbourne VIC 3000

Ph: +61-3-8664-7430
Fax: +61-3-9639-2175

Email: andr...@vicnet.net.au
Alt email: lang.supp...@gmail.com

http://home.vicnet.net.au/~andrewc/
http://www.openroad.net.au
http://www.vicnet.net.au
http://www.slv.vic.gov.au



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
begin:vcard
fn:Andrew Cunningham
n:Cunningham;Andrew
org:State Library of Victoria;Vicnet
adr:;;328 Swanston Street;Melbourne;VIC;3000;Australia
email;internet:andr...@vicnet.net.au
title:Senior Manager, Research and Development
tel;work:+61-3-8664-7430
tel;fax:+61-3-9639-2175
tel;cell:0421-450-816
note;quoted-printable:Projects:=0D=0A=
	http://www.openroad.net.au/=0D=0A=
	http://www.mylanguage.gov.au/
x-mozilla-html:FALSE
url:http://www.vicnet.net.au/
version:2.1
end:vcard

Re: [WSG] Accessible websites

2009-07-07 Thread matt andrews 
2009/7/8 Dennis Lapcewich :
>
>>> Dennis Lapcewich wrote:
>>> >>> While I agree with your general sentiment, I have to say I find
>>> >>> the assertion that all people aged 35-40 or more are "for all
>>> >>> intents and purposes [...] web disabled and [...] in immediate
>>> >>> need of web accessibility" questionable, to say the least.
>>> >>>
>
> I did not write the above.  Please do not attribute to me another's comments
> in this accessibility thread.  Please make sure you attribute correctly so
> as to avoid a misquote, at best, or disingenuous intent, at worst.  My
> original comment concerned itself with a medical condition that in time,
> literally affects 100 percent of the human population.  While onset of
> presbyopia is often described in the literature in the 40s and later, it is
> not unheard of to have symptoms beginning at age 35-40.

Dennis is quite right - I wrote the quoted "While I agree with your
general sentiment..." sentence. Have to be careful with those indents
and attributions.

I stand by my comment, by the way: while I strongly agree that
accessibility is a core aspect of web design, extrapolating "it's not
unheard of to have symptoms beginning at age 35-40" to "[all people
aged 35-40 or more are] for all intents and purposes [...] web
disabled and [...] in immediate need of web accessibility" is clearly
overstating the case.  It's unnecessary, as the case for good
accessibility is very strong anyway, and only gets weakened by making
exaggerated claims.


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

[WSG] AUTO: Rachel Booth/HeadOffice/DHS is out of the office. (returning Thu 09/07/2009)

2009-07-07 Thread Rachel . Booth 

I am out of the office from Wed 08/07/2009 until Thu 09/07/2009.

For RRHACS web publishing requests, please contact the Web Services Team -
(rrhacs@dhs.vic.gov.au).  Thank you.


Note: This is an automated response to your message  "Re: [WSG] Accessible
websites" sent on 8/7/09 1:29:37.

This is the only notification you will receive while this person is away.

_
 
This email contains confidential information intended only for the person named 
above and may be subject to legal privilege. If you are not the intended 
recipient, any disclosure, copying or use of this information is prohibited. 
The Department provides no guarantee that this communication is free of virus 
or that it has not been intercepted or interfered with. If you have received 
this email in error or have any other concerns regarding its transmission, 
please notify postmas...@dhs.vic.gov.au
_



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] utf8 character display problem

2009-07-07 Thread Nick Roper 

Hi David,

Nice one - I'll give that go too.

Cheers,

Nick

David Dixon wrote:
you should also be able to add/edit a .htaccess file on the shared web 
space and add the following:


AddDefaultCharset utf-8

most hosts, even shared hosts should allow this (and it saves adding php 
headers to every page)


Thanks,

David

On 7/7/09 18:46, Nick Roper wrote:

Hey Rimantas,

I added a line of PHP code as follows:



and it works fine now.

I also installed Live Headers in FF for future debugging.

Many thanks for that.

Cheers,

Nick

Rimantas Liubertas wrote:
  

Here's the issue:

We are working on a site that incorporates Russian text. It displays OK on
our development server, but when transferring the files to the live server
we get garbled output.
  

<…>


However, the same file uploaded to the live server displays the last menu
item incorrectly:

http://www.imperial-russian-dating.com/utf8-test.php

The file has been saved as utf8 encoded in the editor (Komodo) and then
uploaded to each server.

Any ideas ?
  

There are headers sent by your live server:
Connection:close
Content-Length:862
Content-Type:text/html; charset=ISO-8859-1
Date:Tue, 07 Jul 2009 16:22:43 GMT
Server:Apache/2.2.3 (CentOS)
X-Powered-By:PHP/5.1.6

Take a look at Content-Type header: it specifies charset as iso-8859-1. Charset
specified in HTTP has preference over charset in META. If you have
access to your
server configuration look for AddDefaultCharset directive in Apache
config. You can either
change it to UTF or comment it out.

Regards,
Rimantas
--
http://rimantas.com/


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***





  


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***


--
Nick Roper
partner
logical elements
innovative web and internet solutions
zend/php & mysql approved partner
email: nro...@logical.co.uk
phone: +44 (0)1749 676798
mobile: +44 (0)7590 538686
web: www.logical.co.uk
skype: nick.roper / +44 20 7870 9587

logical elements, 34, Chamberlain St, Wells, Somerset, BA5 2PJ, UK
---

IMPORTANT This communication is to be treated as confidential and the 
information in it may not be used or disclosed except for the purpose 
for which it has been sent. If you have reason to believe that you are 
not the intended recipient of this communication, please contact the 
sender immediately. Any views or opinions expressed in this email may 
not be those of Logical Elements.


WARNING Computer viruses can be transmitted by E-Mail. The recipient 
should check this E-Mail and any attachments for the presence of 
viruses. Logical Elements accepts no liability for any damage caused by 
any virus transmitted by this E-Mail. This E-mail and any attachments 
may not be copied or forwarded without the express permission of Logical 
Elements. In the event of any unauthorised copying or forwarding, the 
recipient will be required to indemnify Logical Elements against any 
claim for loss or damage caused by any viruses or otherwise.



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] Accessible websites

2009-07-07 Thread Benjamin Hawkes-Lewis 

On 7/7/09 04:19, Felix Miata wrote:
> To suppose "Frozen" means anything other than frozen undersize would
> be a difficult supposition to support, as one need only peruse the web
> to see how rare frozen at or larger than default can be found. Thus,
> disrespectful (smaller than default) font sizes were and _are_ the #1
> (foundational) problem, with other font issues lagging.

Maybe. The more I read that article, the harder I find it to work out 
the form Nielsen's responses took and how he calculated the ranking. How 
important was the third of respondents who complained about contrast to 
the overall ranking of the "bad fonts" category? Is that a third of all 
respondents, or a third of the readers who complained about "bad fonts"?


I'm uncomfortable with your equation of "common" with "foundational".

>> The claims I was trying to question were:
>
>> Claim 1: Browser defaults always represent "user choice".
>
> Actual choice, of course not always.

Right, glad we agree. :)

> Safest presumption of choice, very much yes.
> Any other presumption, which is what use of non-defaults makes, is a
> poor foundation on which to build in usability and/or accessibility.

I think it's safer to build usability and accessibility on reality 
rather than "presumptions".


> This "claim 1" is addressed by the major point of Inkster article.

On the contrary, Toby argues from the position that users defaults might 
not match their preferences.


>> Claim 2: Acceptance of publisher font size suggestions is not a valid
>> "user choice".

> If by "publisher" you mean site designer,

Site publisher.

> I'm not sure I understand your claim. If you assume an actual user
> setting is not a valid choice,

No. I'm saying the actual user setting is an entirely valid choice and 
means something different than what you assume it does. The "default" 
font setting is explicitly the font size to use when the publisher 
happens not to suggest a font size. The user setting means "Please use 
the publisher's suggested font size. If they fail to suggest a font 
size, please use X" not "Please use this font size for body text on all 
webpages, although I understand most webpages will override this with 
itsy font size suggestions".


As evidence, consider the help text for these features:

Internet Explorer Help says:

"Change the colors and fonts used for webpages. Internet Explorer lets 
you pick which fonts and colors will be used to display webpages. These 
settings will only affect webpages that do not specify colors and fonts 
within the page. If you want to use your color and font choices on all 
webpages, regardless of whether they've been specified by the website 
designer, you can override website font and color settings."


Firefox Help says:

"'Default font and Size': Web pages are usually displayed in the font 
and size specified here. However, web pages can override these choices 
unless you specify otherwise in the Fonts dialog. … 'Allow pages to 
choose their own fonts, instead of my selections above': By default 
Firefox uses the fonts specified by the web page author. Disabling this 
preference will force all sites to use your default fonts instead."


http://support.mozilla.com/en-US/kb/Options+window+-+Content+panel?style_mode=inproduct#Fonts_Dialog

Safari Help says:

"'Standard font and Fixed-width font': To change the fonts used in 
webpages that don’t specify their own fonts, click the Select buttons 
and choose the font you want."


Opera Help says:

"'Fonts and colors'. Not all Web pages clearly specify styling for all 
page elements. These settings let you choose how such elements should be 
displayed; which fonts and colors to use, and whether links should be 
underlined."


http://help.opera.com/Mac/9.64/en/webpages.html

The Opera Help text is the most explicit that these settings are fallbacks.

> Most are personal computers. By definition they come with
> personalizability built in. The vendors have provided for the
> clueless, and everyone else, usable defaults. Authors should defer
> to the clueful, not the clueless. Doing otherwise is an affirmative
> designer choice for chaos outside their own microcosms. The clueless
> who are overwhelmed by their cluelessness can generally acquire clues.

I think it's dangerous to ignore "clueless" users when building for 
usability and accessibility since:


1. The majority of users seem pretty "clueless".
2. Cognitive disabilities could contribute to effective computer 
"cluelessness".


Also, given that setting default font sizes does not make body text that 
size on much, if not most, of the web, I'd expect "clueful" users who 
wanted that size to set a minimum size, reject publisher font size 
suggestions, or reject publisher style suggestions entire.


> People make choices to serve their interests. It's in everyone's best
> interest to respect others and their choices. It's my puter. I set the
> settings according to my needs. Web pages can accommodate and re

Re: [WSG] utf8 character display problem

2009-07-07 Thread David Dixon 
you should also be able to add/edit a .htaccess file on the shared web 
space and add the following:


AddDefaultCharset utf-8

most hosts, even shared hosts should allow this (and it saves adding php 
headers to every page)


Thanks,

David

On 7/7/09 18:46, Nick Roper wrote:

Hey Rimantas,

I added a line of PHP code as follows:



and it works fine now.

I also installed Live Headers in FF for future debugging.

Many thanks for that.

Cheers,

Nick

Rimantas Liubertas wrote:
   

Here's the issue:

We are working on a site that incorporates Russian text. It displays OK on
our development server, but when transferring the files to the live server
we get garbled output.
   

<…>
 

However, the same file uploaded to the live server displays the last menu
item incorrectly:

http://www.imperial-russian-dating.com/utf8-test.php

The file has been saved as utf8 encoded in the editor (Komodo) and then
uploaded to each server.

Any ideas ?
   

There are headers sent by your live server:
Connection:close
Content-Length:862
Content-Type:text/html; charset=ISO-8859-1
Date:Tue, 07 Jul 2009 16:22:43 GMT
Server:Apache/2.2.3 (CentOS)
X-Powered-By:PHP/5.1.6

Take a look at Content-Type header: it specifies charset as iso-8859-1. Charset
specified in HTTP has preference over charset in META. If you have
access to your
server configuration look for AddDefaultCharset directive in Apache
config. You can either
change it to UTF or comment it out.

Regards,
Rimantas
--
http://rimantas.com/


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***


 


   



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] utf8 character display problem

2009-07-07 Thread Nick Roper 

Hey Rimantas,

I added a line of PHP code as follows:



and it works fine now.

I also installed Live Headers in FF for future debugging.

Many thanks for that.

Cheers,

Nick

Rimantas Liubertas wrote:

Here's the issue:

We are working on a site that incorporates Russian text. It displays OK on
our development server, but when transferring the files to the live server
we get garbled output.

<…>

However, the same file uploaded to the live server displays the last menu
item incorrectly:

http://www.imperial-russian-dating.com/utf8-test.php

The file has been saved as utf8 encoded in the editor (Komodo) and then
uploaded to each server.

Any ideas ?


There are headers sent by your live server:
Connection:close
Content-Length:862
Content-Type:text/html; charset=ISO-8859-1
Date:Tue, 07 Jul 2009 16:22:43 GMT
Server:Apache/2.2.3 (CentOS)
X-Powered-By:PHP/5.1.6

Take a look at Content-Type header: it specifies charset as iso-8859-1. Charset
specified in HTTP has preference over charset in META. If you have
access to your
server configuration look for AddDefaultCharset directive in Apache
config. You can either
change it to UTF or comment it out.

Regards,
Rimantas
--
http://rimantas.com/


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***




--
Nick Roper
partner
logical elements
innovative web and internet solutions
zend/php & mysql approved partner
email: nro...@logical.co.uk
phone: +44 (0)1749 676798
mobile: +44 (0)7590 538686
web: www.logical.co.uk
skype: nick.roper / +44 20 7870 9587

logical elements, 34, Chamberlain St, Wells, Somerset, BA5 2PJ, UK
---

IMPORTANT This communication is to be treated as confidential and the 
information in it may not be used or disclosed except for the purpose 
for which it has been sent. If you have reason to believe that you are 
not the intended recipient of this communication, please contact the 
sender immediately. Any views or opinions expressed in this email may 
not be those of Logical Elements.


WARNING Computer viruses can be transmitted by E-Mail. The recipient 
should check this E-Mail and any attachments for the presence of 
viruses. Logical Elements accepts no liability for any damage caused by 
any virus transmitted by this E-Mail. This E-mail and any attachments 
may not be copied or forwarded without the express permission of Logical 
Elements. In the event of any unauthorised copying or forwarding, the 
recipient will be required to indemnify Logical Elements against any 
claim for loss or damage caused by any viruses or otherwise.



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] utf8 character display problem

2009-07-07 Thread Nick Roper 

Hi Rimantas,

Ah, very useful to know, many thanks for that. The problem is that the 
site is on a shared server, so we may not be able to edit the Apache 
config file, but maybe I can use PHP to send a header instead?


Regards,

Nick

Rimantas Liubertas wrote:

Here's the issue:

We are working on a site that incorporates Russian text. It displays OK on
our development server, but when transferring the files to the live server
we get garbled output.

<…>

However, the same file uploaded to the live server displays the last menu
item incorrectly:

http://www.imperial-russian-dating.com/utf8-test.php

The file has been saved as utf8 encoded in the editor (Komodo) and then
uploaded to each server.

Any ideas ?


There are headers sent by your live server:
Connection:close
Content-Length:862
Content-Type:text/html; charset=ISO-8859-1
Date:Tue, 07 Jul 2009 16:22:43 GMT
Server:Apache/2.2.3 (CentOS)
X-Powered-By:PHP/5.1.6

Take a look at Content-Type header: it specifies charset as iso-8859-1. Charset
specified in HTTP has preference over charset in META. If you have
access to your
server configuration look for AddDefaultCharset directive in Apache
config. You can either
change it to UTF or comment it out.

Regards,
Rimantas
--
http://rimantas.com/


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***




--
Nick Roper
partner
logical elements
innovative web and internet solutions
zend/php & mysql approved partner
email: nro...@logical.co.uk
phone: +44 (0)1749 676798
mobile: +44 (0)7590 538686
web: www.logical.co.uk
skype: nick.roper / +44 20 7870 9587

logical elements, 34, Chamberlain St, Wells, Somerset, BA5 2PJ, UK
---

IMPORTANT This communication is to be treated as confidential and the 
information in it may not be used or disclosed except for the purpose 
for which it has been sent. If you have reason to believe that you are 
not the intended recipient of this communication, please contact the 
sender immediately. Any views or opinions expressed in this email may 
not be those of Logical Elements.


WARNING Computer viruses can be transmitted by E-Mail. The recipient 
should check this E-Mail and any attachments for the presence of 
viruses. Logical Elements accepts no liability for any damage caused by 
any virus transmitted by this E-Mail. This E-mail and any attachments 
may not be copied or forwarded without the express permission of Logical 
Elements. In the event of any unauthorised copying or forwarding, the 
recipient will be required to indemnify Logical Elements against any 
claim for loss or damage caused by any viruses or otherwise.



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] utf8 character display problem

2009-07-07 Thread Rimantas Liubertas 
> Here's the issue:
>
> We are working on a site that incorporates Russian text. It displays OK on
> our development server, but when transferring the files to the live server
> we get garbled output.
<…>
> However, the same file uploaded to the live server displays the last menu
> item incorrectly:
>
> http://www.imperial-russian-dating.com/utf8-test.php
>
> The file has been saved as utf8 encoded in the editor (Komodo) and then
> uploaded to each server.
>
> Any ideas ?

There are headers sent by your live server:
Connection:close
Content-Length:862
Content-Type:text/html; charset=ISO-8859-1
Date:Tue, 07 Jul 2009 16:22:43 GMT
Server:Apache/2.2.3 (CentOS)
X-Powered-By:PHP/5.1.6

Take a look at Content-Type header: it specifies charset as iso-8859-1. Charset
specified in HTTP has preference over charset in META. If you have
access to your
server configuration look for AddDefaultCharset directive in Apache
config. You can either
change it to UTF or comment it out.

Regards,
Rimantas
--
http://rimantas.com/


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

[WSG] utf8 character display problem

2009-07-07 Thread Nick Roper 

Hi All,

Not sure if this is the correct group to post this to, so feel free to 
point me elsewhere.


Here's the issue:

We are working on a site that incorporates Russian text. It displays OK 
on our development server, but when transferring the files to the live 
server we get garbled output.


For example, the following test file on the development server 
incorporates Russian text into a menu:


http://dev.logical.co.uk/imperial-russian-beta/utf8-test.php

However, the same file uploaded to the live server displays the last 
menu item incorrectly:


http://www.imperial-russian-dating.com/utf8-test.php

The file has been saved as utf8 encoded in the editor (Komodo) and then 
uploaded to each server.


Any ideas ?

Thanks,

Nick



--
Nick Roper
partner
logical elements

logical elements, 34, Chamberlain St, Wells, Somerset, BA5 2PJ, UK
---




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] Accessible websites

2009-07-07 Thread Dennis Lapcewich 
>> Dennis Lapcewich wrote:
>> >>> While I agree with your general sentiment, I have to say I find
>> >>> the assertion that all people aged 35-40 or more are "for all
>> >>> intents and purposes [...] web disabled and [...] in immediate
>> >>> need of web accessibility" questionable, to say the least.
>> >>> 

I did not write the above.  Please do not attribute to me another's 
comments in this accessibility thread.  Please make sure you attribute 
correctly so as to avoid a misquote, at best, or disingenuous intent, at 
worst.  My original comment concerned itself with a medical condition that 
in time, literally affects 100 percent of the human population.  While 
onset of presbyopia is often described in the literature in the 40s and 
later, it is not unheard of to have symptoms beginning at age 35-40.  A 
physical inability to focus on near objects is a legitimate disability. 
Bear in mind that addressing web accessibility is not as simple as 
reviewing server stats or talking with a few folks and deciding 
accordingly.  Web accessibility is a human condition life change that will 
eventually affect everyone.  Whatever technical approaches a web developer 
chooses to implement still remains with the developer, for now.


Dennis Lapcewich
US Forest Service Webmaster
DRM Civil Rights POC
Pacific Northwest Region - Vancouver, WA
360.891.5024 - Voice | 360.891.5045 - Fax
dlapcew...@fs.fed.us

"People who say it cannot be done should not interrupt those who are doing 
it." -- George Bernard Shaw

??where conflicting interests must be reconciled, the question will always 
be decided from the standpoint of the greatest good of the greatest number 
in the long run.? --Gifford Pinchot, Chief Forester, 1905 






***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

RE: [WSG] font size - was [ Accessible websites]

2009-07-07 Thread Chris F.A. Johnson 

On Tue, 7 Jul 2009, Mario Theodorou wrote:


Try using font-size:0.8em this is a better method for font-size
accessibility


Which will be too small for me (and many other people) to read comfortably.



-Original Message-
From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On
Behalf Of designer
Sent: 07 July 2009 12:20
To: wsg@webstandardsgroup.org
Subject: [WSG] font size - was [ Accessible websites]

I've been reading (and trying to learn from) the discussions on
accessibility and particularly font size. I have never had any success at
using ways other than pixels. When I read:

http://informationarchitects.jp/100e2r/?v=4

I agreed with the author that the text size looked OK (he uses Georgia), so
I tried knocking up a simple test/template and I found that Verdana 'looks'
much bigger than Georgia, and Arial slightly smaller than Georgia. I also
found that firefox was different to Safara, these two in turn being
different to IE and Opera.  IE7 looked huge and clumsy!  See for yourself:

http://www.betasite.fsnet.co.uk/gam/fontstyle.html

So, whilst the idea of text at 100% sounds reasonable, I always get a mixed
bag of results. I feel as a designer(suggester), that I cannot possibly
allow something I've done to look laughably clumsy in some browsers.
Contrary to the idea that users want to choose there own settings, my
experience is that very very few even know they can do it, let alone want to

be bothered!  Is there a way around this, which provides a more consistent
interface AND maintains user choice for those who want it?


--
   Chris F.A. Johnson  
   ===
   Author:
   Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] font size - was [ Accessible websites]

2009-07-07 Thread designer 

Hi Nick,

- Original Message - 
From: "Nick Fitzsimons" 

To: 
Sent: Tuesday, July 07, 2009 12:47 PM
Subject: Re: [WSG] font size - was [ Accessible websites]

Different fonts have different sized letter forms; _of course_ they
look different. Look up x-height
 for starters.

Verdana not only has a larger x-height than Georgia or Arial, it also
has wider letters; that is why the Verdana sample occupies seven
lines, while the Georgia and Arial samples only occupy six. Using the
MeasureIt plugin for Firefox, I find that six lines occupies exactly
the same amount of vertical space in all three fonts, which is what
one would expect given that they have the same font-size and
line-height. It's just that Verdana doesn't fit as many letters into
the same space widthways, and so runs on to an extra line.

If you expect all typefaces to occupy the exact same space
letter-for-letter then you're going to have to turn your back on
hundreds of years of typographical history. Using only monospaced
fonts will give roughly the effect you desire ;-)

Regards,

Nick.
--
Nick Fitzsimons
http://www.nickfitz.co.uk/


Precisely!  Of course I don't expect all fonts to be the same, which is why 
selecting 100% text doesn't work - some are way too big!


Bob 





***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

RE: [WSG] font size - was [ Accessible websites]

2009-07-07 Thread Mario Theodorou 
Try using font-size:0.8em this is a better method for font-size
accessibility




-Original Message-
From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On
Behalf Of designer
Sent: 07 July 2009 12:20
To: wsg@webstandardsgroup.org
Subject: [WSG] font size - was [ Accessible websites]

I've been reading (and trying to learn from) the discussions on 
accessibility and particularly font size. I have never had any success at 
using ways other than pixels. When I read:

 http://informationarchitects.jp/100e2r/?v=4

I agreed with the author that the text size looked OK (he uses Georgia), so 
I tried knocking up a simple test/template and I found that Verdana 'looks' 
much bigger than Georgia, and Arial slightly smaller than Georgia. I also 
found that firefox was different to Safara, these two in turn being 
different to IE and Opera.  IE7 looked huge and clumsy!  See for yourself:

 http://www.betasite.fsnet.co.uk/gam/fontstyle.html

So, whilst the idea of text at 100% sounds reasonable, I always get a mixed 
bag of results. I feel as a designer(suggester), that I cannot possibly 
allow something I've done to look laughably clumsy in some browsers. 
Contrary to the idea that users want to choose there own settings, my 
experience is that very very few even know they can do it, let alone want to

be bothered!  Is there a way around this, which provides a more consistent 
interface AND maintains user choice for those who want it?

Thanks,

Bob







***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***


__
This email has been scanned by Netintelligence
http://www.netintelligence.com/email



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] font size - was [ Accessible websites]

2009-07-07 Thread Nick Fitzsimons 
2009/7/7 designer :
> I've been reading (and trying to learn from) the discussions on
> accessibility and particularly font size. I have never had any success at
> using ways other than pixels. When I read:
>
> http://informationarchitects.jp/100e2r/?v=4
>
> I agreed with the author that the text size looked OK (he uses Georgia), so
> I tried knocking up a simple test/template and I found that Verdana 'looks'
> much bigger than Georgia, and Arial slightly smaller than Georgia. I also
> found that firefox was different to Safara, these two in turn being
> different to IE and Opera.  IE7 looked huge and clumsy!  See for yourself:
>
> http://www.betasite.fsnet.co.uk/gam/fontstyle.html
>
> So, whilst the idea of text at 100% sounds reasonable, I always get a mixed
> bag of results. I feel as a designer(suggester), that I cannot possibly
> allow something I've done to look laughably clumsy in some browsers.
> Contrary to the idea that users want to choose there own settings, my
> experience is that very very few even know they can do it, let alone want to
> be bothered!  Is there a way around this, which provides a more consistent
> interface AND maintains user choice for those who want it?
>

Different fonts have different sized letter forms; _of course_ they
look different. Look up x-height
 for starters.

Verdana not only has a larger x-height than Georgia or Arial, it also
has wider letters; that is why the Verdana sample occupies seven
lines, while the Georgia and Arial samples only occupy six. Using the
MeasureIt plugin for Firefox, I find that six lines occupies exactly
the same amount of vertical space in all three fonts, which is what
one would expect given that they have the same font-size and
line-height. It's just that Verdana doesn't fit as many letters into
the same space widthways, and so runs on to an extra line.

If you expect all typefaces to occupy the exact same space
letter-for-letter then you're going to have to turn your back on
hundreds of years of typographical history. Using only monospaced
fonts will give roughly the effect you desire ;-)

Regards,

Nick.
-- 
Nick Fitzsimons
http://www.nickfitz.co.uk/


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] font size - was [ Accessible websites]

2009-07-07 Thread hariharan k 
Hi,

check the link you will find the soln :)

http://news.softpedia.com/news/Safari-Font-Rendering-Scares-Windows-Users-57815.shtml
http://www.joelonsoftware.com/items/2007/06/12.html

regards,
- hariharan k -

On Tue, Jul 7, 2009 at 4:58 PM, Rimantas Liubertas wrote:

> > I've been reading (and trying to learn from) the discussions on
> > accessibility and particularly font size. I have never had any success at
> > using ways other than pixels.
> <…>
> > So, whilst the idea of text at 100% sounds reasonable, I always get a
> mixed
> > bag of results. I feel as a designer(suggester), that I cannot possibly
> > allow something I've done to look laughably clumsy in some browsers.
> > Contrary to the idea that users want to choose there own settings, my
> > experience is that very very few even know they can do it, let alone want
> to
> > be bothered!  Is there a way around this, which provides a more
> consistent
> > interface AND maintains user choice for those who want it?
>
> Idea about respecting "users' choice" is plain bullshit, this kind of
> meaningless
> discussions were going there for six years or so, and they lead to nowhere.
> Best way is to ignore them. And him.
>
>
> Regards,
> Rimantas
> --
> http://rimantas.com/
>
>
> ***
> List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
> Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
> Help: memberh...@webstandardsgroup.org
> ***
>
>


-- 
Hariharan. K
Web Designer


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] font size - was [ Accessible websites]

2009-07-07 Thread Rimantas Liubertas 
> I've been reading (and trying to learn from) the discussions on
> accessibility and particularly font size. I have never had any success at
> using ways other than pixels.
<…>
> So, whilst the idea of text at 100% sounds reasonable, I always get a mixed
> bag of results. I feel as a designer(suggester), that I cannot possibly
> allow something I've done to look laughably clumsy in some browsers.
> Contrary to the idea that users want to choose there own settings, my
> experience is that very very few even know they can do it, let alone want to
> be bothered!  Is there a way around this, which provides a more consistent
> interface AND maintains user choice for those who want it?

Idea about respecting "users' choice" is plain bullshit, this kind of
meaningless
discussions were going there for six years or so, and they lead to nowhere.
Best way is to ignore them. And him.


Regards,
Rimantas
--
http://rimantas.com/


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

[WSG] font size - was [ Accessible websites]

2009-07-07 Thread designer 
I've been reading (and trying to learn from) the discussions on 
accessibility and particularly font size. I have never had any success at 
using ways other than pixels. When I read:


http://informationarchitects.jp/100e2r/?v=4

I agreed with the author that the text size looked OK (he uses Georgia), so 
I tried knocking up a simple test/template and I found that Verdana 'looks' 
much bigger than Georgia, and Arial slightly smaller than Georgia. I also 
found that firefox was different to Safara, these two in turn being 
different to IE and Opera.  IE7 looked huge and clumsy!  See for yourself:


http://www.betasite.fsnet.co.uk/gam/fontstyle.html

So, whilst the idea of text at 100% sounds reasonable, I always get a mixed 
bag of results. I feel as a designer(suggester), that I cannot possibly 
allow something I've done to look laughably clumsy in some browsers. 
Contrary to the idea that users want to choose there own settings, my 
experience is that very very few even know they can do it, let alone want to 
be bothered!  Is there a way around this, which provides a more consistent 
interface AND maintains user choice for those who want it?


Thanks,

Bob







***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***