View Issue Details

IDProjectCategoryView StatusLast Update
0015931ScribusBuild Systempublic2019-11-13 01:34
Reporterale Assigned Tojghali  
Status closedResolutionno change required 
Product Version1.5.6.svn 
Target VersionFixed in Version 
Summary0015931: getRGBColor() should always return a valid QColor
Descriptioncurrently, every call to getRGBColor(colorName, m_doc) needs to check

if (colorName == CommonStrings::None)

it would be wise if getRGBColor() could

return QColor(Qt::transparent);

if it detects the transparent color.
TagsNo tags attached.



2019-11-08 08:31

manager   ~0047030

i've tried to find a patch for this, but failed.

despite having a name() function, ScColor does not know the "scrinbus name" of the color and the transparent color does not seem to be the same as Qt::transparent (it's probably that terrible brownish color.

could it be that it's that "security relevant" brownish color is the reason why getRGBColor() cannot detect the transparent color and it's then the main reason why the brownish color can still show up?

in the mean time, you get some IIFE... the cool trick of the day... (


2019-11-08 09:07

administrator   ~0047031

Hmmm, ScColorEngine::getRGBColor() does not take the name of the color as an argument but the ScColor itself. So if it returns something bad, then the bad thing has happened prior the call.


2019-11-08 09:09

administrator   ~0047032

Last edited: 2019-11-08 09:11

View 2 revisions

And even if we return Qt transparent, usually when calling getRGBColor(), we get the RGB values right afterwards... which are meaningless for transparent colors. So returning a transparent color will not prevent bad things to happen.


2019-11-08 09:29

manager   ~0047033

eh eh... bad things happen if you forget to check for (colorName == CommonStrings::None) before calling getRGBColor()...

at least happened to m: i did get the brownish color then...

(you can check the implementation of get rgb color in the scripter for an example of why returning Qt::transparent would improve the scribus code and avoid "stupid" errors (like mine this morning)


2019-11-13 01:31

administrator   ~0047052

Well basically CommonStrings::None and Qt::transparent are semantically different. CommonStrings::None indicates an absence of painting operation while Qt::transparent indicates painting with 0% opacity. Qt::transparent is also ambiguous from the point of the PDF transparency model. PDF transparency model always associate opacity with specific color values in order to perform color blending. In such case RGB(255, 255, 255) with 0% opacity is not equivalent with RGB(0, 0, 0) with 0% opacity. The difference of behavior could be seen when using such color in a gradient.

So returning Qt::transparent would be in fact totally arbitrary and wrong from the point of PDF transparency model. Qt::transparent must in fact not be used in any drawing operation on canvas.

As for the brownish color : it indicates the use of a default constructed ScColor. Usually you will get it when trying to get a color from the document color list using an invalid name. This brown color exactly serves its purpose: indicating that there is some brokenness in code or document.

Issue History

Date Modified Username Field Change
2019-11-08 08:25 ale New Issue
2019-11-08 08:26 ale Patch Yes => No
2019-11-08 08:31 ale Note Added: 0047030
2019-11-08 09:07 jghali Note Added: 0047031
2019-11-08 09:09 jghali Note Added: 0047032
2019-11-08 09:11 jghali Note Edited: 0047032 View Revisions
2019-11-08 09:29 ale Note Added: 0047033
2019-11-13 01:31 jghali Note Added: 0047052
2019-11-13 01:34 jghali Assigned To => jghali
2019-11-13 01:34 jghali Status new => resolved
2019-11-13 01:34 jghali Resolution open => no change required
2019-11-13 01:34 jghali Status resolved => closed