[liblouis-liblouisxml] Re: [liblouis] r715 committed - the last batch of files converted to utf-8.

  • From: Timothy Lee <timothy.ty.lee@xxxxxxxxx>
  • To: liblouis-liblouisxml@xxxxxxxxxxxxx
  • Date: Wed, 04 Jul 2012 12:50:05 +0800

John,

I am on CentOS 5. I use VIM for programming purposes, and it fully support UTF-8 under xterm / gnome-terminal. I've also briefly tried nano, and that also supports UTF-8 file encoding.

However, both command line editors must be running under X Windows to gain font support for drawing non-ASCII characters.

Regards,
Timothy Lee

On 07/04/2012 06:56 AM, John J. Boyer wrote:
I'm waiting for the Europeans to come back online. It's night there now.
In case we have a consensus to use UTF-8 we can fall back to Latin-1 if
an invalid UTF-8 character sequence is encountgered. In this case there
would be a warning message.

Linux text editors are intended for use with programming languages. I'm
looking for one that can handle UTF-8.

I work at the command line because I find GUI's hard to use. There are
others who have been blind from birth who don't have this problem.
Perhaps trining would help, but I have never been able to afford it.

John B

On Tue, Jul 03, 2012 at 03:06:39PM -0700, John Gardner wrote:
Okay I'm putting in my vote for UTF8.  It is the coding I use all the time,
and it works great with all screen readers as long as we are dealing with
characters in the first Unicode sheet.  Screen readers work perfectly with
such characters, although many of them do not come by default with
pronounciation dictionaries for all characters.

It is not really relevant to the present discussion, but FYI, the trouble
for screen readers comes in pronouncing characters in higher sheets.  This
gets out of my range of expertise really fast.  The only characters that I
have ever needed to pronounce that are not in the loest sheet are math
characters that are bold, italic, Fraktur, etc.  For me, it meant that I
could not use them in LEAN Math, but this is a minor nuisance at best.

I use Notepad and Notepad++ as my text editors, and both work perfectly well
with UTF8.  I am really quite surprised to hear that there are still text
editors in use that do not do UTF8.  It is the most common coding in use in
western countries today.  UTF16 is a bit more efficient for Chinese and
other such languages, but UTF8 does work for those.

John G
-----Original Message-----
From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
[mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of John J.
Boyer
Sent: Tuesday, July 03, 2012 1:32 PM
To: liblouis-liblouisxml@xxxxxxxxxxxxx
Subject: [liblouis-liblouisxml] Re: [liblouis] r715 committed - the last
batch of files converted to utf-8.

Hi Mesar,

I would be interested to see an editor for Linux that works at the command
line and supports UTF-8 conveniently.

However, i want to see more of a consensus. So who else wants UTF-8 in the
character argument of opcodes? It might be a good idea to start a new thread
with this question.

John

On Tue, Jul 03, 2012 at 06:00:06PM +0100, Mesar Hameed wrote:
On Tue 03/07/12,11:17, John J. Boyer wrote:
I feel that it is important that the tables should be human-readable
and editable with simple text editors.
Human readable is exactly one of the cases why we should move to utf8.
\xhhhh is not really readable.
If i write the word "hello" as:

word \x0068\x0065\x006c\x006c\x006f 125-15-123-123-135

Its not really readable.
Of course "hello" here is just an example to illustrate what has to be
done for non a-zA-z languages.

unicode is now an old and established standard, and is used for the
majority of documents across the web, many simple editors support this out
of the box.
If you like we can help you to find an editor that will work with your
tools and utf8 at the same time?

I don't care that it doesn['t look pretty.
The point that Christian and I are trying to make is that \xhhhh
doesnt look very readable to us :)

It makes things easier for people who have to maintain tables after the
original author is finished with them.
That second person popping up is probably going to be another person
from that country, and will be able to read their letters using their
screenreader much easier than having to match \xhhhh representation to
individual letters.
If it was a sighted person, they are even less likely to find the \xhhhh
mapping intuative.
Finally, I don't think it is a good idea to suddenly change a way of
writing tables that has been used from the beginning.
The question is not suddenly, its a question of evolution over time to
match changing needs.
Before, most of liblouis customers were either european or american,
which were served either by ascii or latin1, but with free screenreaders
and with lower costs for accessible materials and devices, we have to
accommodate for new users.
My intention is not to be irritating, but simply expressing my view and
feeding back to the project what I get from other sources.
Remember I sit on fences, I have people wanting and regularly asking
to have braille support both in nvda and orca for their languages, so
I decided to volunteer time to liblouis because it is a worth while
project.
I am sure braille embossing in native languages or mixed language texts is
also often requested.
Our list of tasks still includes adding 21 indian languages, and as of yet
an uncounted numberof african languages.
Thanks for understanding.
Mesar
For a description of the software, to download it and links to project
pages go to http://www.abilitiessoft.com
--
John J. Boyer; President, Chief Software Developer Abilitiessoft, Inc.
http://www.abilitiessoft.com
Madison, Wisconsin USA
Developing software for people with disabilities

For a description of the software, to download it and links to project pages
go to http://www.abilitiessoft.com

For a description of the software, to download it and links to
project pages go to http://www.abilitiessoft.com

For a description of the software, to download it and links to
project pages go to http://www.abilitiessoft.com

Other related posts: