Stefan Küng <tortoisesvn_at_gmail.com> schreef op 30/05/2011 18:53:06:
> On 30.05.2011 14:28, Jan Keirse wrote:
> > Jan Keirse<jan.keirse_at_tvh.be> schreef op 30/05/2011 13:01:55:
> >> While I can work around it (just add an empty line)
> > Turns out this is not a complete workaround, if I add the empty line
> > files to be committed are not checked by default. The only sollution
> > remove the byte order mark manually.
> Instead of removing it, why not just write the file without it?
I tried but could not find a way. I'm using a 4GL language, with build in
support for UTF-16 but no way to control the BOM:
OUTPUT TO VALUE(cPathFile) CONVERT TARGET "UTF-16".
FOR EACH ttfile:
PUT UNFORMATTED ttfile.path + "~n".
END. /* ttfile */
The first statement causes the output to be in UTF-16 instead of plain
ASCII, but there's no way to say it should not write the BOM.
Implementing the workaround is easy:
COPY-LOB FROM FILE cPathFile TO mFile.
COPY-LOB FROM mFile STARTING AT 3 TO FILE cPathFile.
SET-SIZE(mFile) = 0.
Because of the small size of these files the overhead will be negligeable
and I can live with this sollution but I just think that it would be
better if tortoiseproc would detect this BOM character because it is
allowed to be there according to the unicode specs and so others may
encounter the same issue (or the docs on automating tortoiseproc could
mention there should be no BOM if this would require a complex code
Software quality & Systems: Software Engineer
**** DISCLAIMER ****
"This message is delivered to all addressees subject to the conditions
set forth in the attached disclaimer, which is an integral part of this
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2011-05-31 09:04:05 CEST