- From: Michael A. Puls II <shadow2531@gmail.com>
- Date: Thu, 11 Mar 2010 03:52:17 -0500
- To: "Eric Uhrhane" <ericu@google.com>
- Cc: public-device-apis@w3.org
On Wed, 10 Mar 2010 21:29:11 -0500, Eric Uhrhane <ericu@google.com> wrote: > On Tue, Mar 9, 2010 at 11:53 PM, Michael A. Puls II > <shadow2531@gmail.com> wrote: >> On Tue, 09 Mar 2010 21:51:28 -0500, Eric Uhrhane <ericu@google.com> >> wrote: >> >>> I've rolled in the feedback so far. I've left the line endings as an >>> open issue for now. >> >> What about doing like C does for writing files. You have text translated >> mode (the default) and binary mode. Binary mode writes things as-is and >> translated mode converts newlines to the platform format. >> >> With that said, I would think that the mode would be something you set >> before using write() on FileWriter, and not something append() does when >> building the blob. > > As the ending translation is only relevant to text, it makes sense to > keep it where the text conversion happens. You could append a mixture > of text and binary data to a Blob; if you then wanted to translate the > line endings only on the text portion, there would be no way to sort > it out without excessive bookkeeping under the covers. Yeh, you can do that in C by opening a file in binary mode, writing to it and reopening it in text translated + append mode and writing to it again etc. But, yeh, I see. You want to always write() in binary and just have the blob be like a stream buffer (that's written when you call write()) where the translation happens (if desired) when adding to the buffer. That's fine. So, then, it'd be like this: var bb = new BlobBuilder(); bb.append("string representing binary data"); bb.endings = "native"; bb.append("text with newlines translated to native format"); bb.endings = "transparent"; bb.append("another string representing binary data"); bb.endings = "lf"; bb.append("text with newlines translated to \\n"); bb.endings = "cr"; bb.append("string representing binary data with newlines converted to \\r"); Or, if 'endings' is dropped: function toNixNewline(s) { return s.replace(/\r\n|\r/g, "\n"); } function toWin32Newline(s) { return s.replace(/\r\n|\r|\n/g, "\r\n"); } function toNativeNewlines(s) { var pf = navigator.platform.toLowerCase(); return pf == "win32" ? toWin32Newline(s) : toNixNewline(s); } var bb = new BlobBuilder(); bb.append("string representing binary data"); bb.append(toNativeNewline("text with newlines translated to native format")); bb.append("another string representing binary data"); bb.append(toNixNewline("text with newlines translated to \\n")); I personally like the 'endings' way. That way, the code that does the translating is handled natively. Native code might be able to handle that more efficiently. And, the native code might be able to detect that native newline format easier. (I also wish FileReader tranlated newlines to \n.) As for translating newlines, <http://unicode.org/standard/reports/tr13/tr13-5.html> may be relevant. -- Michael
Received on Thursday, 11 March 2010 08:52:52 UTC