If you speak for underlying Issues, you might refer to this?
I have stashed this change in
/main/basebmp/inc/basebmp/scanlineformats.hxx and I do not like the
existing implementation.
namespace basebmp {
/* Current implementation */
namespace Format {
static const sal_Int32 NONE = 0;
static const sal_Int32 ONE_BIT_MSB_GREY =
(sal_Int32)0x01;
static const sal_Int32 ONE_BIT_LSB_GREY =
(sal_Int32)0x02;
static const sal_Int32 ONE_BIT_MSB_PAL =
(sal_Int32)0x03;
static const sal_Int32 ONE_BIT_LSB_PAL =
(sal_Int32)0x04;
static const sal_Int32 FOUR_BIT_MSB_GREY =
(sal_Int32)0x05;
static const sal_Int32 FOUR_BIT_LSB_GREY =
(sal_Int32)0x06;
static const sal_Int32 FOUR_BIT_MSB_PAL =
(sal_Int32)0x07;
static const sal_Int32 FOUR_BIT_LSB_PAL =
(sal_Int32)0x08;
static const sal_Int32 EIGHT_BIT_PAL =
(sal_Int32)0x09;
static const sal_Int32 EIGHT_BIT_GREY =
(sal_Int32)0x0A;
static const sal_Int32 SIXTEEN_BIT_LSB_TC_MASK =
(sal_Int32)0x0B;
static const sal_Int32 SIXTEEN_BIT_MSB_TC_MASK =
(sal_Int32)0x0C;
static const sal_Int32 TWENTYFOUR_BIT_TC_MASK =
(sal_Int32)0x0D;
static const sal_Int32 THIRTYTWO_BIT_TC_MASK =
(sal_Int32)0x0E;
static const sal_Int32 THIRTYTWO_BIT_TC_MASK_ARGB =
(sal_Int32)0x0F;
static const sal_Int32 MAX =
(sal_Int32)0x0F;
}
/* what it should be
enum class Format : sal_Int32
{ NONE = 0
, ONE_BIT_MSB_GREY = 0x01
, ONE_BIT_LSB_GREY = 0x02
, ONE_BIT_MSB_PAL = 0x03
, ONE_BIT_LSB_PAL = 0x04
, FOUR_BIT_MSB_GREY = 0x05
, FOUR_BIT_LSB_GREY = 0x06
, FOUR_BIT_MSB_PAL = 0x07
, FOUR_BIT_LSB_PAL = 0x08
, EIGHT_BIT_PAL = 0x09
, EIGHT_BIT_GREY = 0x0A
, SIXTEEN_BIT_LSB_TC_MASK = 0x0B
, SIXTEEN_BIT_MSB_TC_MASK = 0x0C
, TWENTYFOUR_BIT_TC_MASK = 0x0D
, THIRTYTWO_BIT_TC_MASK = 0x0E
, THIRTYTWO_BIT_TC_MASK_ARGB = 0x0F
, MAX = 0x0F
};
*/
}
I do not feel well with the test options.
The basic Idea I wanted to go with was to write a specific test, compile
it on CentOS 6 (where old and new stuff should work.)
And make sure possible out put is the same (Blackbox testing)
Locate all Uses would be also necessary in order to check. Thats where I got
stuck on this topic.
Please note that enumn class is pretty new. So I do not know if it works on
CentOS 6. I just thought I do write the best code for me and worry about
Compiler Version issue as a later step.
Also another Idea could be to cut out the code and replace it with a general
better design. But then we need to find the user story to it. Which is a lot of
digging.
And I dont think the code is that bad on first glance.
On 05.02.2018 19:34, Don Lewis wrote:
There is at least one other place in this code that uses the
rGlyphData.ExtDataRef().meInfo to Format::NONE comparision.
I think there are some deeper problems in this code. Unfortunately
I won't have another chance to dig into it until the end of this week.
Something else to think about is how to test this code.
On 2 Feb, Peter Kovacs wrote:
It does also not compile on gcc 7.xx
So I did change the code and it compiles
if( rGlyphData.ExtDataRef().mpData != NULL )
But I think it has to be
if( rGlyphData.ExtDataRef().mpData != NULL &&
rGlyphData.ExtDataRef().mpData != Format::NONE)
You can work around this issue in gcc by setting some flags that allows
the use of Format::NONE directly. But i concider this as not so good.
All the best
Peter
On 30.01.2018 21:01, Don Lewis wrote:
When doing a build with clang 6, which defaults to c++14, I get a
compile error in SvpGlyphPeer::RemovingGlyph() in
vcl/unx/headless/svptext.cxx on this line:
if( rGlyphData.ExtDataRef().mpData != Format::NONE )
This isn't too surprising since Format::NONE is an integer and mpData is
a pointer.
There are a couple of ways that I thought of fixing this. One is to
change the right side of the comparision to NULL, the other is to change
the left side to use meInfo.
Then I used OpenGrok to dig through the code, and the only assignments
to meInfo that I found were in main/vcl/unx/generic/gdi/gcach_xpeer.cxx
and use the values from this enum:
enum { INFO_EMPTY=0, INFO_PIXMAP, INFO_XRENDER, INFO_RAWBMP,
INFO_MULTISCREEN };
This makes no sense given the other comparisions to meInfo in
svptext.cxx and the code in SvpGlyphPeer::GetGlyphBmp() starting on line
92 of that file. There is a call to rServerFont.SetExtended() that gets
the value of nBmpFormat, but that sets private member mnExtInfo in class
ServerFont in glyphcache.hxx, whereas meInfo is a struct field where the
struct is a private member of class GlyphData.
Thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
