Symbian3/PDK/Source/GUID-9F9CE6B6-1B3D-50A6-8A94-BD391732EF2D.dita
changeset 3 46218c8b8afa
parent 1 25a17d01db0c
child 5 f345bda72bc4
--- a/Symbian3/PDK/Source/GUID-9F9CE6B6-1B3D-50A6-8A94-BD391732EF2D.dita	Thu Mar 11 15:24:26 2010 +0000
+++ b/Symbian3/PDK/Source/GUID-9F9CE6B6-1B3D-50A6-8A94-BD391732EF2D.dita	Thu Mar 11 18:02:22 2010 +0000
@@ -1,60 +1,60 @@
-<?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-9F9CE6B6-1B3D-50A6-8A94-BD391732EF2D" xml:lang="en"><title>Luminosity
-Pixel Formats</title><shortdesc>This topic provides detailed information about the supported luminosity
-pixel formats. These formats are used to represent grayscale images.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
-<section id="GUID-320B39DE-E3E7-4222-9CC9-5B4471F88710"><title>EUidPixelFormatL_1</title> <p>This format has
-1 bit per pixel. It is implicit in the code that pixel addresses within a
-byte increase from low bit to high bit. A little-endian architecture is also
-implicit, because conversions are made from pointers to byte and from pointers
-to (unsigned) int and there is an implication that pixel addresses within
-a 32-bit word also increase from low to high-order bit. </p> <fig id="GUID-7E3D8B96-2CC0-58C8-856D-21847782878E">
-<title>              Pixel address layout in memory for the EUidPixelFormatL_2
-format            </title>
-<image href="GUID-736BB5CF-0E2B-59FC-BC65-E52A7D12EC4A_d0e208297_href.png" placement="inline"/>
-</fig> <p>The equivalent UID value is {0x102858EF}. </p> </section>
-<section id="GUID-A8A6123A-5766-4993-AEDB-D069831D9064"><title>EUidPixelFormatL_2</title> <p>This format has 2 bits per pixel.
-It is implicit in the code that pixel addresses within a byte increase from
-low bit to high bit. A little-endian architecture is also implicit, because
-conversions are made from pointers to byte and from pointers to (unsigned)
-int and there is an implication that pixel addresses within a 32-bit word
-also increase from low to high-order bit. </p> <fig id="GUID-5D4C0942-42F8-5094-B376-DC4252816437">
-<title>              Pixel address layout in memory for the EUidPixelFormatL_2
-format            </title>
-<image href="GUID-CB7A54D9-C6C8-562A-8A52-4B17B37242AD_d0e208316_href.png" placement="inline"/>
-</fig> <p>The equivalent UID value is {0x102858EE}. </p> </section>
-<section id="GUID-71CFCD00-7223-40CA-8A26-205792E3E7C7"><title>EUidPixelFormatL_4</title> <p>This format has 4 bit per pixel.
-It is implicit in the code that pixel addresses within a byte increase from
-low bit to high bit. A little-endian architecture is also implicit, because
-conversions are made from pointers to byte and from pointers to (unsigned)
-int and there is an implication that pixel addresses within a 32-bit word
-also increase from low to high-order bit. </p> <fig id="GUID-6021C416-EAF0-5FAA-9181-13A0FB14D518">
-<title>              Pixel address layout in memory for the EUidPixelFormatL_4
-format            </title>
-<image href="GUID-65C997F4-3899-56B1-85DD-9425E06F128B_d0e208335_href.png" placement="inline"/>
-</fig> <p>The equivalent UID value is {0x102858ED}. </p> </section>
-<section id="GUID-719B6262-9AC5-4372-A082-36E559FE7922"><title> EUidPixelFormatL_8</title> <p>This format has 8 bit per pixel.
-A little-endian architecture is implicit in the code, because conversions
-are made from pointers to byte and pointers to (unsigned) integer and there
-is an implication that the lower-order byte of an unsigned integer has the
-physically lower address. </p> <p>8-bit per pixel color bitmaps use indexed
-look up tables and monochrome bitmaps represent the 256 levels of gray directly. </p> <fig id="GUID-7047A561-981B-56B9-BCFD-5F2E4C757B79">
-<title>              Pixel address layout in memory for the EUidPixelFormatL_8
-format            </title>
-<image href="GUID-49F16A96-083E-5928-B939-75F2D11E2BF8_d0e208357_href.png" placement="inline"/>
-</fig> <p>The equivalent UID value is {0x102858EC}. </p> </section>
-</conbody><related-links>
-<link href="GUID-7E6DDDBB-FDE2-59ED-A932-AFD4D0BAC3E3.dita"><linktext>RGB     
-           Pixel Format</linktext></link>
-<link href="GUID-D429672C-448D-5E91-ABA0-81680869D69E.dita"><linktext>YUV Pixel
-Format</linktext></link>
+<?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-9F9CE6B6-1B3D-50A6-8A94-BD391732EF2D" xml:lang="en"><title>Luminosity
+Pixel Formats</title><shortdesc>This topic provides detailed information about the supported luminosity
+pixel formats. These formats are used to represent grayscale images.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
+<section id="GUID-320B39DE-E3E7-4222-9CC9-5B4471F88710"><title>EUidPixelFormatL_1</title> <p>This format has
+1 bit per pixel. It is implicit in the code that pixel addresses within a
+byte increase from low bit to high bit. A little-endian architecture is also
+implicit, because conversions are made from pointers to byte and from pointers
+to (unsigned) int and there is an implication that pixel addresses within
+a 32-bit word also increase from low to high-order bit. </p> <fig id="GUID-7E3D8B96-2CC0-58C8-856D-21847782878E">
+<title>              Pixel address layout in memory for the EUidPixelFormatL_2
+format            </title>
+<image href="GUID-736BB5CF-0E2B-59FC-BC65-E52A7D12EC4A_d0e208297_href.png" placement="inline"/>
+</fig> <p>The equivalent UID value is {0x102858EF}. </p> </section>
+<section id="GUID-A8A6123A-5766-4993-AEDB-D069831D9064"><title>EUidPixelFormatL_2</title> <p>This format has 2 bits per pixel.
+It is implicit in the code that pixel addresses within a byte increase from
+low bit to high bit. A little-endian architecture is also implicit, because
+conversions are made from pointers to byte and from pointers to (unsigned)
+int and there is an implication that pixel addresses within a 32-bit word
+also increase from low to high-order bit. </p> <fig id="GUID-5D4C0942-42F8-5094-B376-DC4252816437">
+<title>              Pixel address layout in memory for the EUidPixelFormatL_2
+format            </title>
+<image href="GUID-CB7A54D9-C6C8-562A-8A52-4B17B37242AD_d0e208316_href.png" placement="inline"/>
+</fig> <p>The equivalent UID value is {0x102858EE}. </p> </section>
+<section id="GUID-71CFCD00-7223-40CA-8A26-205792E3E7C7"><title>EUidPixelFormatL_4</title> <p>This format has 4 bit per pixel.
+It is implicit in the code that pixel addresses within a byte increase from
+low bit to high bit. A little-endian architecture is also implicit, because
+conversions are made from pointers to byte and from pointers to (unsigned)
+int and there is an implication that pixel addresses within a 32-bit word
+also increase from low to high-order bit. </p> <fig id="GUID-6021C416-EAF0-5FAA-9181-13A0FB14D518">
+<title>              Pixel address layout in memory for the EUidPixelFormatL_4
+format            </title>
+<image href="GUID-65C997F4-3899-56B1-85DD-9425E06F128B_d0e208335_href.png" placement="inline"/>
+</fig> <p>The equivalent UID value is {0x102858ED}. </p> </section>
+<section id="GUID-719B6262-9AC5-4372-A082-36E559FE7922"><title> EUidPixelFormatL_8</title> <p>This format has 8 bit per pixel.
+A little-endian architecture is implicit in the code, because conversions
+are made from pointers to byte and pointers to (unsigned) integer and there
+is an implication that the lower-order byte of an unsigned integer has the
+physically lower address. </p> <p>8-bit per pixel color bitmaps use indexed
+look up tables and monochrome bitmaps represent the 256 levels of gray directly. </p> <fig id="GUID-7047A561-981B-56B9-BCFD-5F2E4C757B79">
+<title>              Pixel address layout in memory for the EUidPixelFormatL_8
+format            </title>
+<image href="GUID-49F16A96-083E-5928-B939-75F2D11E2BF8_d0e208357_href.png" placement="inline"/>
+</fig> <p>The equivalent UID value is {0x102858EC}. </p> </section>
+</conbody><related-links>
+<link href="GUID-7E6DDDBB-FDE2-59ED-A932-AFD4D0BAC3E3.dita"><linktext>RGB     
+           Pixel Format</linktext></link>
+<link href="GUID-D429672C-448D-5E91-ABA0-81680869D69E.dita"><linktext>YUV Pixel
+Format</linktext></link>
 </related-links></concept>
\ No newline at end of file