[reportlab-users] blurry (dithered) lines + font height, descent etc.
Robin Becker
reportlab-users@reportlab.com
Wed, 23 Oct 2002 17:42:01 +0100
In article <011a01c27a9f$f0963600$0300a8c0@mike1>, Michael Steuer
<mike@awakened-lands.com> writes
.........
>Would it be much effort on your side to add that flag?
we use art_rgb_svp_alpha()
I thought the way to do this is via the alphagamma . Normally the colour
is determined by the winding number (hopefully in [0,1]) and the alpha
value. I suppose you intend that there is some threshold fraction of
colour that causes a switch so if the composition ends up>.5 we assume
full colour. Trouble is the alphagamma in art_rgb_svp_alpha seems to be
unreferenced.
from the libart docs
void art_rgb_svp_alpha (const ArtSVP *svp,
int x0,
int y0,
int x1,
int y1,
art_u32 rgba,
art_u8 *buf,
int rowstride,
ArtAlphaGamma *alphagamma);
Renders the shape specified with svp over the buf RGB buffer. x1 - x0
specifies the width, and y1 - y0 specifies the height, of the rectangle
rendered. The new pixels are stored starting at the first byte of buf.
Thus, the x0 and y0 parameters specify an offset within svp, and may be
tweaked as a way of doing integer-pixel translations without fiddling
with svp itself.
The rgba argument specifies the color for the rendering. Pixels of
entirely 0 winding number are left untouched. Pixels of entirely 1
winding number have the color rgba composited over them (ie, are
replaced by the red, green, blue components of rgba if the alpha
component is 0xff). Pixels of intermediate coverage are interpolated
according to the rule in alphagamma, or default to linear if alphagamma
is NULL.
svp : The source sorted vector path.
x0 : Left coordinate of destination rectangle.
y0 : Top coordinate of destination rectangle.
x1 : Right coordinate of destination rectangle.
y1 : Bottom coordinate of destination rectangle.
rgba : Color in 0xRRGGBBAA format.
buf : Destination RGB buffer.
rowstride : Rowstride of buf buffer.
alphagamma : ArtAlphaGamma for gamma-correcting the compositing.
>
>I think I'll have a look at _renderPM.c and see if I can adjust it for myself.
....... when you register a font I think that the ascent and descent are
parsed from the afm file for T1 files at least and end up in the
EmbeddedType1Face instance. I'm not sure what happens for the newer TTF
stuff.
>
>Yes, I found _fontdata.ascent_descent, but that is only for standard fonts and I
>was hoping that there would be some way to obtain that information like it is
>possible for "stringWidth". What about the font height, though?
>
>Thanks for your help so far.
>
>Cheers,
>
>Mike.
.......
--
Robin Becker