From: David Starner (firstname.lastname@example.org)
Date: Tue Aug 02 2005 - 13:45:55 CDT
On 8/2/05, Gregg Reynolds <email@example.com> wrote:
> Ok, but that's an implementation issue. Processes are not required to
> support any particular set of characters; if groff supports a bunch
> goofy typesetting dashes, some people will like it, some won't and will
> either move to software that only allows hyphen-minus or will customize
> their environment to get rid of the annoyance. So that isn't an
> argument against having multiple dash-like characters.
A system that has multiple Unicode characters that are percieved as
one causes frustration in users, even users that know about the
problem. Why is that not an argument against needless duplication of
In any case, your complaint is an implementation issue. Programs can
handle Bidi on input however they like; it's only on storage that they
have to get it right.
> > How many bugs are we going to hear about because you can't cut and
> > paste numbers from one program and paste them into a spreadsheet or
> > calculator and it work?
> No different from any other new character.
No, it is different. Because they are Arabic digits, people will
expect them to work as Arabic digits where Arabic digits have always
worked. Programmers will have to deal with many complaints about this
not working right, because no one but Unicode geeks will understand
that there are two independent, completely different, sets of Arabic
> Suppose you have legacy
> application X and new app X with special enzymes to understand new
> character foo. Now you want to cut a text run from new X including a
> foo character and paste it into legacy X. What is legacy X to do with
> foo? IMO, it should typeset a "not found" character.
No, it shouldn't; it should reach into the new fonts and pull out the
> Isn't there a presumption that the user will just hit the number keys
> and the software will do the right thing?
Presume all you like, but it's not magic. Why do you think that if the
programmers won't do BiDi, that they'll jump up to support your new
> Again, this is no different
> than receiving a file with, say, a Thai filename when your local
> software doesn't support Thai.
It is different; my keyboard supports Arabic digits, I'm typing in
Arabic digits, why the hell is it telling me file not found?
This archive was generated by hypermail 2.1.5 : Tue Aug 02 2005 - 13:46:44 CDT