Bug report #5749

transparent polygons not rendered

Added by Bernhard Ströbl over 12 years ago. Updated over 12 years ago.

Status:Closed
Priority:Severe/Regression
Assignee:Marco Hugentobler
Category:QGIS Server
Affected QGIS version:master Regression?:No
Operating System:OpenSUSE 64 bit Easy fix?:No
Pull Request or Patch supplied:No Resolution:
Crashes QGIS or corrupts data:No Copied to github as #:15255

Description

Polygons with transparency > 0% and < 100% are not rendered
example project contains data from OSM project (tiny subset of roads and landuse). Layer landuse is included in the project twice: transparency = 0% and transparency = 32%.
regression from 1.7.4

wms_transparency.zip - test project with data (shp) included (45.6 KB) Bernhard Ströbl, 2012-06-06 05:53 AM

5749_8b.png - OSM transparent 32% overlay (120 KB) Larry Shaffer, 2012-06-06 02:40 PM

Associated revisions

Revision ee2f1bdb
Added by Jürgen Fischer over 12 years ago

Use QString::number with QDomElement::setAttribute with double/float (fixes #5749)

History

#1 Updated by Marco Hugentobler over 12 years ago

  • Assignee set to Marco Hugentobler

#2 Updated by Werner Macho over 12 years ago

not confirmed here - latest master self compiled - testfiles are displayed transparently with every value from 0 - 100

#3 Updated by Larry Shaffer over 12 years ago

Not confirmed with Mac OS X 10.6.8 (1.8_c695198). Transparency works as expected with test data.

#4 Updated by Tim Sutton over 12 years ago

Works for me on desktop. He has set the category to mapserver so I wonder if it fails only when publishing the layer via wms.

#5 Updated by Marco Hugentobler over 12 years ago

The problem is that the double alpha value in the project file has a comma instead of a dot:

 <symbols>
                    <symbol outputUnit="MM" alpha="0,6784313725490196" type="fill" name="0">

And it should be:

<symbols>
                    <symbol outputUnit="MM" alpha="0.6784313725490196" type="fill" name="0">

With that modification, it works here.

#6 Updated by Bernhard Ströbl over 12 years ago

Marco Hugentobler wrote:

The problem is that the double alpha value in the project file has a comma instead of a dot:

<symbols>
<symbol outputUnit="MM" alpha="0,6784313725490196" type="fill" name="0">

And it should be:

<symbols>
<symbol outputUnit="MM" alpha="0.6784313725490196" type="fill" name="0">

With that modification, it works here.

ok, I checked here: QGIS 1.7.4 writes a dot (alpha="0.6784313725490196") whereas 1.8 writes a comma (alpha="0,6784313725490196") this maybe because it is a German system and we use a comma instead of dot for decimalsand yes, only QGIS Server is affected

#7 Updated by Giovanni Manghi over 12 years ago

this #2104 seems also related.

#8 Updated by Marco Hugentobler over 12 years ago

and yes, only QGIS Server is affected

I have the same behaviour (alpha with comma does not work) in the desktop application. Probably it depends on your settings or locale (though mine is de_CH.UTF-8).

#9 Updated by Jürgen Fischer over 12 years ago

Marco Hugentobler wrote:

and yes, only QGIS Server is affected

I have the same behaviour (alpha with comma does not work) in the desktop application. Probably it depends on your settings or locale (though mine is de_CH.UTF-8).

are desktop and server running in different environments?

Why are we using QDomElement::setAttribute ( const QString & name, const QString & value ) with QString::number all over the place, when we just could use the version for double and/or int.

Like in https://gist.github.com/2887218 (compiles, but not tested).

#10 Updated by Bernhard Ströbl over 12 years ago

Marco Hugentobler wrote:

and yes, only QGIS Server is affected

I have the same behaviour (alpha with comma does not work) in the desktop application. Probably it depends on your settings or locale (though mine is de_CH.UTF-8).

mine is de_DE (also UTF-8)

#11 Updated by Marco Hugentobler over 12 years ago

Why are we using QDomElement::setAttribute ( const QString & name, const QString & value ) with QString::number all over the place, when we just could use the version for >double and/or int.

Because the developer was not aware there is a formating difference between these two.
But looking at the Qt documentation, I think it is better if we format numbers in the project file not according to the locale. Imagine in an international company, a person with locale de_xx prepares a project for his boss (with locale en_xx). Or someone publishes a project from the desktop to the server. So QString::number() without locale aware formating seems better to me.

#12 Updated by Jürgen Fischer over 12 years ago

Marco Hugentobler wrote:

Because the developer was not aware there is a formating difference between these two.

There isn't any, is it? The documentation clearly says that those are localized too.
So which dumb developer suggested to use QDomElement::setAttribute() for doubles? ;)

#13 Updated by Marco Hugentobler over 12 years ago

There isn't any, is it? The documentation clearly says that those are localized too.

I'm a bit confused. I interpreted it the way they are not localized (but I did not really test it):

"Unlike QLocale::toString(), this function does not honor the user's locale settings" (http://qt-project.org/doc/qt-4.8/qstring.html#number-2)

#14 Updated by Jürgen Fischer over 12 years ago

Marco Hugentobler wrote:

There isn't any, is it? The documentation clearly says that those are localized too.

I'm a bit confused. I interpreted it the way they are not localized (but I did not really test it):

Sorry.

My assumption was, that localization of XML attributes doesn't make any sense and therefore I (dumb me) suggested the double version of QDomElement::setAttribute. Obviously that's wrong, because its documentation (which I didn't read before) clearly says that the output is localized.

"Unlike QLocale::toString(), this function does not honor the user's locale settings" (http://qt-project.org/doc/qt-4.8/qstring.html#number-2)

Yes - of course. Ignore everything I said.

Looks like that's the actual fix:

diff --git a/src/core/symbology-ng/qgssymbollayerv2utils.cpp b/src/core/symbology-ng/qgssymbollayerv2utils.cpp
index 89074e4..38d1ad3 100644
--- a/src/core/symbology-ng/qgssymbollayerv2utils.cpp
+++ b/src/core/symbology-ng/qgssymbollayerv2utils.cpp
@@ -713,7 +713,7 @@ QDomElement QgsSymbolLayerV2Utils::saveSymbol( QString name, QgsSymbolV2* symbol
   symEl.setAttribute( "type", _nameForSymbolType( symbol->type() ) );
   symEl.setAttribute( "name", name );
   symEl.setAttribute( "outputUnit", encodeOutputUnit( symbol->outputUnit() ) );
-  symEl.setAttribute( "alpha", symbol->alpha() );
+  symEl.setAttribute( "alpha", QString::number( symbol->alpha() ) );
   QgsDebugMsg( "num layers " + QString::number( symbol->symbolLayerCount() ) );
   for ( int i = 0; i < symbol->symbolLayerCount(); i++ )
   {

#15 Updated by Jürgen Fischer over 12 years ago

Jürgen Fischer wrote:

Looks like that's the actual fix:

[...]

Um, but that's just one place. I declared the two Qt methods deprecated in qdom.h:

    Q_DECL_DEPRECATED void setAttribute(const QString& name, float value);
    Q_DECL_DEPRECATED void setAttribute(const QString& name, double value);

And https://gist.github.com/2895431 is the rather large patch that is needed to fix all the deprecation warnings:

 src/core/composer/qgscomposerarrow.cpp             |   12 +++++-----
 src/core/composer/qgscomposeritem.cpp              |   12 +++++-----
 src/core/composer/qgscomposerlegend.cpp            |    4 +-
 src/core/composer/qgscomposermap.cpp               |   22 +++++++++---------
 src/core/composer/qgscomposerpicture.cpp           |    4 +-
 src/core/composer/qgscomposerscalebar.cpp          |   14 +++++-----
 src/core/composer/qgscomposershape.cpp             |    6 ++--
 src/core/composer/qgscomposertable.cpp             |    4 +-
 src/core/composer/qgscomposition.cpp               |   10 ++++----
 src/core/qgsdiagramrendererv2.cpp                  |   24 ++++++++++----------
 src/core/qgslabel.cpp                              |   10 ++++----
 src/core/qgsmaplayer.cpp                           |    8 +++---
 src/core/qgsvectorlayer.cpp                        |    4 +-
 .../symbology-ng/qgsgraduatedsymbolrendererv2.cpp  |    4 +-
 .../symbology-ng/qgspointdisplacementrenderer.cpp  |    6 ++--
 src/core/symbology-ng/qgssymbollayerv2utils.cpp    |    2 +-
 src/gui/qgsannotationitem.cpp                      |   18 +++++++-------
 src/mapserver/qgswmsserver.cpp                     |   16 ++++++------
 .../qgsrasterterrainanalysisdialog.cpp             |    4 +-
 19 files changed, 92 insertions(+), 92 deletions(-)

Still untested. I wonder why nobody noticed so far - I suppose anyone using a localization with a comma instead of a dot should have suffered from truncation of decimal places, which using QDomElement::setAttribute(...,somedouble) to write and QDomElement::attribute(...).toDouble() to read should produce.

#16 Updated by Marco Hugentobler over 12 years ago

Thanks Jürgen, please apply the patch.

#17 Updated by Jürgen Fischer over 12 years ago

Marco Hugentobler wrote:

Thanks Jürgen, please apply the patch.

The large one or the small one? ;)

#18 Updated by Marco Hugentobler over 12 years ago

The large one

#19 Updated by Jürgen Fischer over 12 years ago

  • Status changed from Open to Closed

Also available in: Atom PDF