Re: Jumping Cursor. Was: Right-to-Left Punctuation Problem

From: Gregg Reynolds (unicode@arabink.com)
Date: Tue Aug 02 2005 - 00:23:22 CDT

  • Next message: Gregg Reynolds: "Re: Jumping Cursor. Was: Right-to-Left Punctuation Problem"

    David Starner wrote:
    > On 8/1/05, Gregg Reynolds <unicode@arabink.com> 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.

    thx,

    gregg



    This archive was generated by hypermail 2.1.5 : Tue Aug 02 2005 - 00:25:57 CDT