I would try setting encoding="UTF8". I've found that this does fix problems
like this on Windows.
--Dasa
On Nov 7, 2012, at 4:20 PM, Carol Frampton <cfram...@adobe.com> wrote:
>
>
> On 11/7/12 4 :03PM, "Om" <bigosma...@gmail.com> wrote:
>
>> Removing these lines from the source-package task :
>>
>> <fixcrlf srcdir="${BUILD_DIR}/temp" eol="crlf"
>> excludes="**/*.ttf,**/*.png"/>
>>
>> <fixcrlf srcdir="${BUILD_DIR}/temp" eol="unix"
>> excludes="**/*.ttf,**/*.png"/>
>
> I've been playing with this task as well.
>
> You need this task to make the line endings match the type of the kit.
> Even if the files had native line endings, you would need this unless you
> want to make the Windows distro on a Windows system and the Mac distro on
> a Mac.
>
>
> To make the EOF match you can add fixlast="false" since the default is
> "true". This doesn't help with the encoding issue just the EOL at EOF
> issue.
>
> The task does has an encoding property you can play with. I don't have
> the garbled problem when I produce the the kits on mac so there is nothing
> for me to test.
>
> Carol
>
>
>>
>> seems to have fixed this issue for both the zip and tar.gz source kits.
>>
>> This would also fix the other issue raised on general@i.a.o about the
>> mismatch between eof eol in the src kit vs. release tag.
>>
>> The question is - what are the other repercussions of this change?
>>
>> Thanks,
>> Om
>
>
