Details Ticket 2129


Comment | Reply | Take | Open


Serial Number 2129
Subject d.text.freetype: bad rendering
Area bug
Queue grass
Requestors hamish_nospam@yahoo.com
Owner none
Status resolved
Last User Contact Thu Sep 25 01:10:31 2003 (5 yr ago)
Current Priority 30
Final Priority 70
Due No date assigned
Last Action Thu Sep 25 10:36:50 2003 (5 yr ago)
Created Wed Sep 24 13:31:52 2003 (5 yr ago)

Transaction History Ticket 2129


Wed, Sep 24 2003 13:31:52    Request created by guest  
Subject: d.text.freetype: bad rendering

Platform: GNU/Linux/i386
grass obtained from: Trento Italy site
grass binary for platform: Compiled from Sources
GRASS Version: 5.3-cvs & 5.0.3rc

d.text.freetype creates jumbled snow where the letters should be.

Happens on Redhat Redhat 9 & Debian/testing, both with font=luxi* and path=/a/b/c/font.ttf.
It doesn't seem to do it on Redhat 7.3 (not very much testing) with path= but
I don't have the b&h luxi fonts installed there so font= doesn't exist as an
option.

This seems to happen somewhat randomly. It will usually get at least one letter
correct though. Resizing the monitor window vertically and redrawing will make
other letters 'come in to focus' while letters that were good will frazzle. Resizing
the monitor window horizontally doesn't change the it at all. It gets it right
about 50% of the time, more when the monitor height is small, less when it is
tall.

e.g.
http://bambi.otago.ac.nz/hamish/grass/bad_freetype.png

Notice the letters are almost right, it just seems to be wrapping the right hand
side too soon and advancing the pixel buffer too much. At least it seems to be
drawing it consistently for a given monitor-window size ..
I'm not sure if the buffer is filled too wide for the drawing-rectangle or the
drawing loop is jumping to the next line too soon.

B&H Luxi is a Monospaced font, right? But that shouldn't matter.

I can't find any documentation for src/libes/raster/Raster.c  R_raster_char()
or really know how to pull apart draw_character() much more.


Making the following change makes the letters somewhat viewable on my system,
but it certainly isn't correct. (note I've removed some white space to stop the
patch line wrapping in the bug-input box)



$ cvs diff -u main.c 
Index: main.c
===================================================================
RCS file: /home/grass/grassrepository/grass/src/display/d.text.freetype/main.c,v
retrieving revision 1.41
diff -u -r1.41 main.c
--- main.c      1 Apr 2003 06:51:32 -0000       1.41
+++ main.c      24 Sep 2003 10:39:41 -0000
@@ -998,7 +998,7 @@
     for(i = start_row; i < rows; i++)
         {
             R_move_abs(rect.l + start_col, rect.t + i);
-            R_raster_char(w, 1, 0, buffer + width * i + start_col);
+            R_raster_char(w, 1, 0, buffer + (width+7) * i + start_col);
          }
 
 #ifdef FLUSH_EACH_CHAR




??
Hamish
Wed, Sep 24 2003 14:24:41    Mail sent by neteler@itc.it  
Return-Path <neteler@itc.it>
Delivered-To grass-bugs@lists.intevation.de
Date Wed, 24 Sep 2003 14:24:27 +0200
From Markus Neteler <neteler@itc.it>
To Request Tracker <grass-bugs@intevation.de>
Cc grass5@grass.itc.it
Subject Re: [GRASS5] [bug #2129] (grass) d.text.freetype: bad rendering
Message-ID <20030924142427.C2876@itc.it>
Mail-Followup-To Request Tracker <grass-bugs@intevation.de>, grass5@grass.itc.it
References <20030924113152.7F15113BBD@lists.intevation.de>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
User-Agent Mutt/1.2.5.1i
In-Reply-To <20030924113152.7F15113BBD@lists.intevation.de>; from grass-bugs@intevation.de on Wed, Sep 24, 2003 at 01:31:52PM +0200
X-Spam-Status No, hits=-4.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MUTT version=2.55
X-Spam-Level
X-Spam-Checker-Version SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
On Wed, Sep 24, 2003 at 01:31:52PM +0200, Request Tracker wrote:
[...]
> I can't find any documentation for src/libes/raster/Raster.c
> R_raster_char() or really know how to pull apart draw_character() much
> more.

Right now I have sumbitted the first bunch of doxygen-style
function documentation to
src/libes/raster/

Unfortunately R_raster_char() remains undocumented. Whomever
knows what it is doing, please add the documentation into
src/libes/raster/Raster.c
(above is another function which demonstrates how to do that).

Markus

PS: More doxygen-style function documentation to be submitted soon.


Wed, Sep 24 2003 17:33:36    Comments added by hbowman  
More info:

It seems to go bad when "j" is one less than it should be:

j = (width + 7) / 8;

a resize & redraw and the j is smaller on the letters that go bad from when
they drew properly.

Had a stab in the dark at doing floating math then rounding j to the nearest
integer but that didn't work.



shrug
Hamish
Thu, Sep 25 2003 01:10:31    Mail sent by glynn.clements@virgin.net  
Return-Path <glynn.clements@virgin.net>
Delivered-To grass-bugs@lists.intevation.de
From Glynn Clements <glynn.clements@virgin.net>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
Message-ID <16242.7272.938033.591447@cerise.nosuchdomain.co.uk>
Date Wed, 24 Sep 2003 23:36:24 +0100
To Request Tracker <grass-bugs@intevation.de>
Cc grass5@grass.itc.it
Subject Re: [GRASS5] [bug #2129] (grass) d.text.freetype: bad rendering
In-Reply-To <20030924113152.7F15113BBD@lists.intevation.de>
References <20030924113152.7F15113BBD@lists.intevation.de>
X-Mailer VM 7.07 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid
X-Spam-Status No, hits=0.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_DSBL, RCVD_IN_UNCONFIRMED_DSBL,REFERENCES,REPLY_WITH_QUOTES version=2.55
X-Spam-Level
X-Spam-Checker-Version SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Request Tracker wrote:

> I can't find any documentation for src/libes/raster/Raster.c
> R_raster_char() or really know how to pull apart draw_character() much
> more.

R_raster_char() simply sends its arguments to the driver, preceded by
the RASTER_CHAR opcode; the actual work is done by the driver.

However, the net effect is to perform a raster drawing operation.

int R_raster_char(int num, int nrows, int withzero, unsigned char *ras);

"num" is the number of columns.

"nrows" is the number of rows to be drawn, all of which are identical
(this is used for vertical scaling).

"withzero" should be true (non-zero) if zero pixels are to be drawn in
colour zero, false (zero) if they are to be transparent (i.e. not
drawn).

"ras" should point to "num" bytes of data, which constitute the pixels
for a single row of a raster image.

The result is that a rectangular area of width "num" and height
"nrows", with its top-left corner at the current position, is filled
with "nrows" copies of the data pointed to by "ras".

Example: if you wanted to draw a byte-per-pixel image, you would use:

	unsigned char image[HEIGHT][WIDTH];

	for (y = 0; y < HEIGHT; y++)
	{
		R_move_abs(x_left, y_top + y);
		R_raster_char(WIDTH, 1, 1, image[y]);
	}

Looking at the d.text.freetype source code, it appears to be guessing
the pitch[1] of the rendered bitmap from the width, rather than
reading it from the FT_Bitmap structure. That would certainly explain
your symptoms, although there may be other problems.

[1] The number of bytes between the start of one row and the next.

Basically, draw_character() uses FT_Render_Glyph() to render the glyph
as a bitmap (1-bit-per-pixel); it then expands the image to
1-byte-per-pixel, and uses R_raster_char() to draw it.

The most likely mode of failure is that the conversion is wrong,
probably because it's making certain assumptions about the layout of
the bitmap data which turn out to be incorrect (at least, for you; the
minimal testing which I did worked, and presumably the same applies to
Huidae).

Actually fixing this will require reading the FreeType documentation
rather than trial-and-error.

-- 
Glynn Clements <glynn.clements@virgin.net>


Thu, Sep 25 2003 03:16:20    Mail sent by hamish_nospam@yahoo.com  
Return-Path <hamish_nospam@yahoo.com>
Delivered-To grass-bugs@lists.intevation.de
Date Thu, 25 Sep 2003 13:15:32 +1200
From Hamish <hamish_nospam@yahoo.com>
To "Glynn Clements" <glynn.clements@virgin.net>
Cc grass-bugs@intevation.de, grass5@grass.itc.it
Subject Re: [GRASS5] [bug #2129] (grass) d.text.freetype: bad rendering
Message-Id <20030925131532.6a9906c6.hamish_nospam@yahoo.com>
In-Reply-To <16242.7272.938033.591447@cerise.nosuchdomain.co.uk>
References <20030924113152.7F15113BBD@lists.intevation.de> <16242.7272.938033.591447@cerise.nosuchdomain.co.uk>
X-Mailer Sylpheed version 0.7.4 (GTK+ 1.2.10; i386-debian-linux-gnu)
Mime-Version 1.0
Content-Type text/plain; charset=US-ASCII
Content-Transfer-Encoding 7bit
X-scanner scanned by Inflex 1.0.12.7
X-Spam-Status No, hits=0.3 required=5.0 tests=FORGED_YAHOO_RCVD,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES version=2.55
X-Spam-Level
X-Spam-Checker-Version SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
> Looking at the d.text.freetype source code, it appears to be guessing
> the pitch[1] of the rendered bitmap from the width, rather than
> reading it from the FT_Bitmap structure. That would certainly explain
> your symptoms, although there may be other problems.
> 
> [1] The number of bytes between the start of one row and the next.
...
> The most likely mode of failure is that the conversion is wrong,
> probably because it's making certain assumptions about the layout of
> the bitmap data which turn out to be incorrect (at least, for you; the
> minimal testing which I did worked, and presumably the same applies to
> Huidae).
> 
> Actually fixing this will require reading the FreeType documentation
> rather than trial-and-error.


You're correct, it is the pitch.

The line should be j = face->glyph->bitmap.pitch;

I wonder if the remaining (7 ... % 8) etc in the bitwise algebra that
follows is damaging the crispness of the characters..

Anyway it seems to work with any TrueType font I have sitting around on
my system using the path=/a/b/c/fontname.ttf option.

The freetype documentation is actually extraordinarily good, and I
think it would not be all that hard to get libfreetype's anti-aliasing
or some crude alpha-blending to work if anyone felt so inclined.

What's the feeling on changing the meaning of parameters for 5.3?
d.text.freetype has a -p flag which changes the east_north= location-
setting option to use window-pixel coordinates instead. I'd prefer to
change this to mean "percent" not "pixel" or add an at= option like
d.barscale to set position as a percentage of the screen width/height.
Having all three -p, e_n=, and at= seems a bit crowded, but maybe
preferred?


thanks,
Hamish


Thu, Sep 25 2003 08:11:11    Comments added by hbowman  
Ok, it is fixed in CVS.

One other little buglette to check out before closing this. (sometimes text
renders left off the screen)


Hamish
Thu, Sep 25 2003 10:36:51    Status changed to resolved by hbowman  
Thu, Sep 25 2003 10:36:50    Comments added by hbowman  
Everything seems to be in order.


Hamish
Comment | Reply | Take | Open

You are currently authenticated as guest.
[Show Configuration] [Login as another user]

Users Guide - Mail Commands - Homepage of RequestTracker 1.0.7 - list any request