-
Jan-Marek Glogowski yazdı
BitmapColor itself is kept to distingish the Color usage as part of a color palette, which continues to store the offset in the blue value. The original special mbIndex handling is long gone since commit 1fefdd6f ("Alpha channel in BitmapColor - change bIndex to alpha"), so there is no data difference. This also results in the following changes: * now has a basic_ostream<charT, traits>& operator<< (that was my actual starting point... for an other bug fix) * there is a minimal difference for GetLiminance BGR(29,151,76) => BGR(28,151,77) * no more return values for Merge and Invert (previously returning *this) * replaces all GetBlueOrIndex with GetIndex This leaves one "problematic" part: the GetColorError handling. At first glance it should probably be virtual. The Color variant is less strict then the BitmapColor one - for whatever reason. BitmapColor is always used to search for the best match in a Palette. Currently I'm simply leaving both variants. Would be nice to have an explict for functions here. Change-Id: I251ba3024a1d60f2a9d9fde9cd0a60f08e8322a7 Reviewed-on: https://gerrit.libreoffice.org/72181 Tested-by: Jenkins Reviewed-by:
Tomaž Vajngerl <quikee@gmail.com> Reviewed-by:
Jan-Marek Glogowski <glogow@fbihome.de>
c34bb163
Adı |
Son kayıt (commit)
|
Son güncelleme |
---|---|---|
.. | ||
GraphicLoader.cxx | ||
GraphicObject.cxx | ||
GraphicObject2.cxx | ||
Manager.cxx | ||
UnoGraphic.cxx | ||
UnoGraphicDescriptor.cxx | ||
UnoGraphicObject.cxx | ||
UnoGraphicProvider.cxx | ||
UnoGraphicTransformer.cxx | ||
grfattr.cxx |