Bug 77841

Summary: kdesktop: drop shadow on desktop icon text is incomplete
Product: kdesktop Reporter: Dominique Devriese <devriese>
Component: generalAssignee: David Faure <faure>
Status: CLOSED UNMAINTAINED    
Severity: normal CC: ana, finex
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Debian testing   
OS: Linux   
Latest Commit: Version Fixed In:
Attachments: Proposed patch

Description Dominique Devriese 2004-03-17 16:27:32 UTC
Version:            (using KDE KDE 3.2.1)
Installed from:    Debian testing/unstable Packages

Note: this is a forward of the following Debian bug report:
http://bugs.debian.org/238227

The original report follows:
  This will seem unbelievably petty, but once you notice it it may bug 
  you. :)

  The drop shadow on fonts used on the desktop is incomplete. It seems
  that text is rendered in 8 positions around the original position to
  create a broad outline, but not in the center of the original
  position. The result is that if you use a font that has a 1-pixel
  period, it makes a hollow box for the shadow instead of a solid
  box. There is no way that shadow would match the period.
Comment 1 Dominique Devriese 2004-03-17 16:28:26 UTC
Created attachment 5251 [details]
Proposed patch

I think this patch is the proper fix.
Comment 2 David Faure 2004-03-17 22:05:13 UTC
----------  Forwarded Message  ----------

Subject: Re: Fwd: [Bug 77841] kdesktop: drop shadow on desktop icon text is incomplete
Date: Wednesday 17 March 2004 19:29
From: Laur Ivan <laurivan@eircom.net>
To: David Faure <faure@kde.org>

On Wednesday 17 March 2004 17:13, you wrote:
> Can you comment on this patch?

Hi,

I had the specific pixel omitted as there are cases when it creates rather 
visible alasing. The case I tried to avoid is of anti-aliased font with all 
qGray(pixel) == 255 and a 3-pixel wide shadow. If you get the shadow only, 
the difference between pixels belonging to the character and adjacent pixels 
is quite high when you include 3*qGray(pixel) as the adjacent pixels will 
constantly miss that. This is reflected quite well in a character's diagonal 
strokes when the shadow is displaced 1+1pixels. The original character would 
be:
   #
  #
 #
# 

and with shadow:
   #
  #.
 #.S.
#.S.
.S.
S.
.

where S are the pixels associated to the character's pixels and "." are the 
faded pixels adjacent to S.

IMO it's more a matter of taste than a bug :). Also, the patch involves 
changing the multiplier setting.. which is quite unpleasant for people who 
have customised their own shadow in the days of 3.1.x and are using that..

However, the patch makes the algorithm 100% accurate. If you decide to put it 
in, the 3.0 factor should be changed to something according to a gaussian 
distribution in relation to the 1.0 and 2.0 factors.

Cheers,

Laur



-------------------------------------------------------

Comment 3 Dominique Devriese 2004-03-18 00:21:23 UTC
David Faure writes:

> However, the patch makes the algorithm 100% accurate. If you decide
> to put it in, the 3.0 factor should be changed to something
> according to a gaussian distribution in relation to the 1.0 and 2.0
> factors.

I am going to leave this decision at your discretion.  I haven't read
about or worked with graphics stuff enough to be able to do it.
Please let me know what you decide, though, so I know what to do with
the debian bug about this.

cheers
domi

Comment 4 FiNeX 2008-12-10 02:06:51 UTC
Kdesktop is no more mantained. Fortunatly this bug seems not to be valid for KDE 4. Please reopen if this bug is not a kdesktop one (and it is not solved) or it can be reproduced on KDE 4.
Comment 5 FiNeX 2009-01-02 20:27:32 UTC
Bug closed. Kdesktop is no more mantained.