--- a/Symbian3/PDK/Source/GUID-763A2636-D448-5353-9E31-F61FE7EB39DA.dita	Tue Mar 30 11:42:04 2010 +0100
+++ b/Symbian3/PDK/Source/GUID-763A2636-D448-5353-9E31-F61FE7EB39DA.dita	Tue Mar 30 11:56:28 2010 +0100
@@ -1,38 +1,38 @@
-<?xml version="1.0" encoding="utf-8"?>
-<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
-<!-- This component and the accompanying materials are made available under the terms of the License 
-"Eclipse Public License v1.0" which accompanies this distribution, 
-and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
-<!-- Initial Contributors:
-    Nokia Corporation - initial contribution.
-Contributors: 
--->
-<!DOCTYPE concept
-  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
-<concept id="GUID-763A2636-D448-5353-9E31-F61FE7EB39DA" xml:lang="en"><title>Flat
-or segmented buffer?</title><shortdesc>Describes the occasions you should choose a flat buffer and when
-to choose a segmented buffers.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
-<p>The choice between using an array implemented with a flat buffer against
-using an array implemented with a segmented buffer depends on the characteristics
-of the application.</p>
-<p>Choose a flat buffer:</p>
-<ul>
-<li id="GUID-0FC7D827-EA67-598C-8DE6-91860661DA7C"><p>if efficiency in transforming
-between buffer position and memory address is very important.</p> </li>
-<li id="GUID-73802049-15D7-550A-8093-87BF3CA2E387"><p>if the re-allocations
-needed to extend the buffer are sufficiently rare that they do not cause intolerable
-amounts of data copying or heap fragmentation.</p> </li>
-<li id="GUID-2129EE71-7859-5B77-91FD-F036348C92D6"><p>if there is an upper
-bound on the size limit and can reserve sufficient room before inserting elements.</p> </li>
-</ul>
-<p>Choose a segmented buffer:</p>
-<ul>
-<li id="GUID-912802E0-C66D-56F1-9977-6B04BFD833AC"><p>to minimise the heap
-thrashing and copying that can be associated with reallocating
-a single flat buffer.</p> </li>
-<li id="GUID-CE5DB4C3-BC72-5D09-B55A-552D08CB8EF6"><p>if the performance of
-frequent insertions and deletions is a concern. This can be better with segmented
-buffers, because not all data after the insertion/deletion point needs to
-be shuffled to complete the operation.</p> </li>
-</ul>
+<?xml version="1.0" encoding="utf-8"?>
+<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
+<!-- This component and the accompanying materials are made available under the terms of the License 
+"Eclipse Public License v1.0" which accompanies this distribution, 
+and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
+<!-- Initial Contributors:
+    Nokia Corporation - initial contribution.
+Contributors: 
+-->
+<!DOCTYPE concept
+  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
+<concept id="GUID-763A2636-D448-5353-9E31-F61FE7EB39DA" xml:lang="en"><title>Flat
+or segmented buffer?</title><shortdesc>Describes the occasions you should choose a flat buffer and when
+to choose a segmented buffers.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
+<p>The choice between using an array implemented with a flat buffer against
+using an array implemented with a segmented buffer depends on the characteristics
+of the application.</p>
+<p>Choose a flat buffer:</p>
+<ul>
+<li id="GUID-0FC7D827-EA67-598C-8DE6-91860661DA7C"><p>if efficiency in transforming
+between buffer position and memory address is very important.</p> </li>
+<li id="GUID-73802049-15D7-550A-8093-87BF3CA2E387"><p>if the re-allocations
+needed to extend the buffer are sufficiently rare that they do not cause intolerable
+amounts of data copying or heap fragmentation.</p> </li>
+<li id="GUID-2129EE71-7859-5B77-91FD-F036348C92D6"><p>if there is an upper
+bound on the size limit and can reserve sufficient room before inserting elements.</p> </li>
+</ul>
+<p>Choose a segmented buffer:</p>
+<ul>
+<li id="GUID-912802E0-C66D-56F1-9977-6B04BFD833AC"><p>to minimise the heap
+thrashing and copying that can be associated with reallocating
+a single flat buffer.</p> </li>
+<li id="GUID-CE5DB4C3-BC72-5D09-B55A-552D08CB8EF6"><p>if the performance of
+frequent insertions and deletions is a concern. This can be better with segmented
+buffers, because not all data after the insertion/deletion point needs to
+be shuffled to complete the operation.</p> </li>
+</ul>
 </conbody></concept>
\ No newline at end of file