strange char translation from intel to ppc

[Bernard Devlin]

That's an interesting idea.  But it was transferred as binary over ftp, so I
would expect that to mean that the ftp process did no translation.  I
believe it is transferring as ascii over ftp where the 'return' character is
translated by ftp.  I can't think of any reason why an ftp program should
translate the ascii chars that represent 'group separator' and 'file
separator'.  They have no particular meaning for Unix vs Windows (unlike the
'return' character).  AFAIK the way I'm using these characters (as safe
delimiters which will not occur anywhere within normal text) is precisely
how they should be used.  And the description of the bug I referred to (read
the first test where the user displays the bug), certainly seems to make
more sense.

I just cross-checked, and even when it is zipped before transfer, it's the
same problem.

I'm not sure if one should attribute the bug to Rev or to Apple though.

Bernard

On Thu, Oct 9, 2008 at 12:21 AM, Bob Sneidar <bobs at twft.com> wrote:

> Are you sure this is a Rev bug? I seem to recall from the original post
> that the stack was transferred over ftp or some other internet file
> transfer. Did you try to zip it before sending it?
>
> I know some forms of file transfers can corrupt a file when sent over the
> internet. It is far less prevalent than it used to be, but that is why
> encoding was originally used. Files were converted to internet friendly
> characters because internet routers were originally only designed to pass
> text based files.
>
> Bob Sneidar
> IT Manager
> Logos Management
> Calvary Chapel CM
>
>
> On Oct 8, 2008, at 3:39 PM, Bernard Devlin wrote:
>
>  Looks like it was bugzilla'd a few years ago:
>> http://quality.runrev.com/qacenter/show_bug.cgi?id=3681
>>
>> It's a pity it doesn't work as I'd kinda come to rely on those unused
>> ascii
>> characters as delimiters.
>>
>> Bernard
>>
>> On Wed, Oct 8, 2008 at 11:32 PM, Bernard Devlin <bdrunrev at gmail.com>
>> wrote:
>>
>>  When I want to refer to these non-printable characters in script I use
>>> numToChar.  The place where they got changed was in actual text stored as
>>> custom properties.
>>>
>>> I'm not sure if this should be marked as a bug.  I can understand if my
>>> original characters had ascii values above 127 that macToIso and isoToMac
>>> might be necessary, but not when the character values are below 127.
>>>
>>> Bernard
>>>
>>>
>>>
>>>  _______________________________________________
>> use-revolution mailing list
>> use-revolution at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
>>
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>