5687eba49f
...which were used by ildc, which is gone since
a8485d558f "[API CHANGE] Remove deprecated idlc
and regmerge from the SDK", and have always been ignored as legacy by its
unoidl-write replacement.
This change has been carried out (making use of GNU sed extensions) with
> for i in $(git ls-files \*.idl); do sed -i -z -E -e 's/\n\n((#[^\n]*\n)+\n)*(#[^\n]*\n)+\n?/\n\n/g' -e 's/\n(#[^\n]*\n)+/\n/g' "$i"; done && git checkout extensions/source/activex/so_activex.idl odk/examples/OLE/activex/so_activex.idl
which apparently happened to do the work. (The final two files are not UNOIDL
source files.)
Change-Id: Ic9369e05d46e8f7e8a304ab01740b171b92335cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135683
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
110 lines
4.2 KiB
Text
110 lines
4.2 KiB
Text
/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
|
|
/*
|
|
* This file is part of the LibreOffice project.
|
|
*
|
|
* This Source Code Form is subject to the terms of the Mozilla Public
|
|
* License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
* file, You can obtain one at http://mozilla.org/MPL/2.0/.
|
|
*
|
|
* This file incorporates work covered by the following license notice:
|
|
*
|
|
* Licensed to the Apache Software Foundation (ASF) under one or more
|
|
* contributor license agreements. See the NOTICE file distributed
|
|
* with this work for additional information regarding copyright
|
|
* ownership. The ASF licenses this file to you under the Apache
|
|
* License, Version 2.0 (the "License"); you may not use this file
|
|
* except in compliance with the License. You may obtain a copy of
|
|
* the License at http://www.apache.org/licenses/LICENSE-2.0 .
|
|
*/
|
|
|
|
module com { module sun { module star { module rendering {
|
|
|
|
/** This structure describes the memory layout of a bitmap having
|
|
integer color channels.<p>
|
|
|
|
This structure collects all necessary information to describe the
|
|
memory layout of a bitmap having integer color channels<p>
|
|
|
|
@since OOo 2.0
|
|
*/
|
|
struct IntegerBitmapLayout
|
|
{
|
|
/** Number of scanlines for this bitmap.
|
|
|
|
This value must not be negative
|
|
*/
|
|
long ScanLines;
|
|
|
|
/** Number of data bytes per scanline.
|
|
|
|
This value must not be negative
|
|
*/
|
|
long ScanLineBytes;
|
|
|
|
/** Byte offset between the start of two consecutive scanlines.
|
|
|
|
This value is permitted to be negative, denoting a bitmap
|
|
whose content is flipped at the x axis.
|
|
*/
|
|
long ScanLineStride;
|
|
|
|
/** Byte offset between the start of two consecutive planes.
|
|
|
|
This value is permitted to be negative. If this value is zero,
|
|
the bitmap is assumed to be in chunky format, otherwise it is
|
|
assumed to be planar. The difference between chunky and
|
|
planar layout lies in the way how color channels are
|
|
interleaved. For a chunky format, all channel data for a
|
|
single pixel lies consecutively in memory. For a planar
|
|
layout, the first channel of all pixel is stored consecutive,
|
|
followed by the second channel, and so forth.<p>
|
|
*/
|
|
long PlaneStride;
|
|
|
|
/** Color space the bitmap colors shall be interpreted within.<p>
|
|
|
|
Note that the actual pixel layout is specified at the color
|
|
space. If this layout describes a palette bitmap format, this
|
|
color space describes the index format (plus maybe an extra
|
|
alpha channel). The palette itself references another color
|
|
space, which describes the layout of the palette entries.
|
|
|
|
@see XBitmapPalette
|
|
*/
|
|
XIntegerBitmapColorSpace ColorSpace;
|
|
|
|
/** This member determines whether the bitmap data are actually
|
|
indices into a color map.<p>
|
|
|
|
When set to the nil reference, the bitmap data is assumed to
|
|
contain direct color values (to be interpreted according to
|
|
the associated color space). If this member references a valid
|
|
palette, one of the pixel components as returned by the color
|
|
space referenced from the #ColorSpace is
|
|
required to be of type
|
|
ColorComponentTag::INDEX. That component is
|
|
then used to index the palette.<p>
|
|
*/
|
|
XBitmapPalette Palette;
|
|
|
|
/** This member determines the bit order (only relevant if a pixel
|
|
uses less than 8 bits, of course).<p>
|
|
|
|
When `TRUE`, this member denotes that the leftmost pixel from
|
|
an 8 bit amount of pixel data consists of the bits starting
|
|
with the most significant bit. When `FALSE`, it's starting
|
|
with the least significant bit.<p>
|
|
|
|
Example: for a 1bpp bitmap, each pixel is represented by
|
|
exactly one bit. If this member is `TRUE`, the first pixel is
|
|
the MSB of the first byte, and the eighth pixel is the LSB of
|
|
the first byte. If this member is `FALSE`, it's just the
|
|
opposite.
|
|
*/
|
|
boolean IsMsbFirst;
|
|
|
|
};
|
|
|
|
}; }; }; };
|
|
|
|
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
|