View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0015931 | Scribus | Build System | public | 2019-11-08 08:25 | 2019-11-13 01:34 |
Reporter | ale | Assigned To | jghali | ||
Priority | normal | Severity | minor | Reproducibility | N/A |
Status | closed | Resolution | no change required | ||
Product Version | 1.5.6.svn | ||||
Summary | 0015931: getRGBColor() should always return a valid QColor | ||||
Description | currently, 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. | ||||
Tags | No tags attached. | ||||
Patch | No | ||||
|
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... (https://www.bfilipek.com/2016/11/iife-for-complex-initialization.html). |
|
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. |
|
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. |
|
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) |
|
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. |
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 | |
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 |