From: Gregg Reynolds (email@example.com)
Date: Tue Aug 02 2005 - 00:23:22 CDT
David Starner wrote:
> On 8/1/05, Gregg Reynolds <firstname.lastname@example.org> wrote:
>>I don't see that. First of all, 3-RTL and 3-LTR are not the same
>>character. They look alike, and they are classified as numbers, but
>>that's all. The new 3-RTL is just another Unicode character with
>>various properties, just like any other.
> I've heard all sorts of complaints that groff made manpages use new
> dashes (that are "just another Unicode character with various
> properties") instead of the good old ASCII hyphen-minus. I don't think
> even many new manpage writers are clearly making the distinction
> between the hyphen-minus and the Unicode hyphen. The various short
> dashes are a pain; unless you're a typesetter, one hyphen-minus is all
> you ever use or know to use, and they confuse people.
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.
> 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. 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. This happens all
the time anyway, when you try to view text that uses codepoints
unsupported by your font. Not a bug, just a configuration issue. Now
if legacy app X learns about foo, then it will know how to manage it.
If you try to paste digits from legacy X to new X, new X knows the
semantics of the chars, so it need not reverse the order, though it may
need to reverse the display order.
> Most calculator writers probably don't think
> for a moment about the locale; they're just ASCII digits. What happens
> when you can't type in the name of the files you just downloaded, or
> someone else can't enter the name of the files you just uploaded
> because the wrong digits are used?
Isn't there a presumption that the user will just hit the number keys
and the software will do the right thing? Again, this is no different
than receiving a file with, say, a Thai filename when your local
software doesn't support Thai. It's no different than the annoyances we
have today with multilingual software. Software that supports
English/latinate chars is under no requirement to understand Thai
strings; nor should it be required to understand RTL digits. If it
receives them it should display a big blank box. The characters would
just be there for the users who need them.
This archive was generated by hypermail 2.1.5 : Tue Aug 02 2005 - 00:25:57 CDT