Update ooo320-m1
[ooovba.git] / offapi / com / sun / star / rendering / IntegerBitmapLayout.idl
blob4c1d508e24ba8818a4cb572e6e3b8727ae425ad0
1 /*************************************************************************
3 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
4 *
5 * Copyright 2008 by Sun Microsystems, Inc.
7 * OpenOffice.org - a multi-platform office productivity suite
9 * $RCSfile: IntegerBitmapLayout.idl,v $
10 * $Revision: 1.8 $
12 * This file is part of OpenOffice.org.
14 * OpenOffice.org is free software: you can redistribute it and/or modify
15 * it under the terms of the GNU Lesser General Public License version 3
16 * only, as published by the Free Software Foundation.
18 * OpenOffice.org is distributed in the hope that it will be useful,
19 * but WITHOUT ANY WARRANTY; without even the implied warranty of
20 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
21 * GNU Lesser General Public License version 3 for more details
22 * (a copy is included in the LICENSE file that accompanied this code).
24 * You should have received a copy of the GNU Lesser General Public License
25 * version 3 along with OpenOffice.org. If not, see
26 * <http://www.openoffice.org/license.html>
27 * for a copy of the LGPLv3 License.
29 ************************************************************************/
30 #ifndef __com_sun_star_rendering_IntegerBitmapLayout_idl__
31 #define __com_sun_star_rendering_IntegerBitmapLayout_idl__
33 #ifndef __com_sun_star_rendering_XIntegerBitmapColorSpace_idl__
34 #include <com/sun/star/rendering/XIntegerBitmapColorSpace.idl>
35 #endif
36 #ifndef __com_sun_star_rendering_XBitmapPalette_idl__
37 #include <com/sun/star/rendering/XBitmapPalette.idl>
38 #endif
40 module com { module sun { module star { module rendering {
42 /** This structure describes the memory layout of a bitmap having
43 integer color channels.<p>
45 This structure collects all necessary information to describe the
46 memory layout of a bitmap having integer color channels<p>
48 @since OOo 2.0.0
50 struct IntegerBitmapLayout
52 /** Number of scanlines for this bitmap.
54 This value must not be negative
56 long ScanLines;
58 /** Number of data bytes per scanline.
60 This value must not be negative
62 long ScanLineBytes;
64 /** Byte offset between the start of two consecutive scanlines.
66 This value is permitted to be negative, denoting a bitmap
67 whose content is flipped at the x axis.
69 long ScanLineStride;
71 /** Byte offset between the start of two consecutive planes.
73 This value is permitted to be negative. If this value is zero,
74 the bitmap is assumed to be in chunky format, otherwise it is
75 assumed to be planar. The difference between chunky and
76 planar layout lies in the way how color channels are
77 interleaved. For a chunky format, all channel data for a
78 single pixel lies consecutively in memory. For a planar
79 layout, the first channel of all pixel is stored consecutive,
80 followed by the second channel, and so forth.<p>
82 long PlaneStride;
84 /** Color space the bitmap colors shall be interpreted within.<p>
86 Note that the actual pixel layout is specified at the color
87 space. If this layout describes a palette bitmap format, this
88 color space describes the index format (plus maybe an extra
89 alpha channel). The palette itself references another color
90 space, which describes the layout of the palette entries.
92 @see XBitmapPalette
94 XIntegerBitmapColorSpace ColorSpace;
96 /** This member determines whether the bitmap data are actually
97 indices into a color map.<p>
99 When set to the nil reference, the bitmap data is assumed to
100 contain direct color values (to be interpreted according to
101 the associated color space). If this member references a valid
102 palette, one of the pixel components as returned by the color
103 space referenced from the <member>ColorSpace</member> is
104 required to be of type
105 <member>ColorComponentTag::INDEX</member>. That component is
106 then used to index the palette.<p>
108 XBitmapPalette Palette;
110 /** This member determines the bit order (only relevant if a pixel
111 uses less than 8 bits, of course).<p>
113 When <TRUE/>, this member denotes that the leftmost pixel from
114 an 8 bit amount of pixel data consists of the bits starting
115 with the most significant bit. When <FALSE/>, it's starting
116 with the least significant bit.<p>
118 Example: for a 1bpp bitmap, each pixel is represented by
119 exactly one bit. If this member is <TRUE/>, the first pixel is
120 the MSB of the first byte, and the eighth pixel is the LSB of
121 the first byte. If this member is <FALSE/>, it's just the
122 opposite.
124 boolean IsMsbFirst;
128 }; }; }; };
130 #endif