No, I think there are consistency problems with what members of the
object are used for what purpose.
On 5 Feb, Peter Kovacs wrote:
> 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
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_I
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
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 s
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 pointe
