Alexander Malmberg wrote:
Adam Fedor wrote:
The art backend uses the same default, although in a different way.
Perhaps someone should change the explanation ( :-) knowing that I'll
probably have to do it).
Arguably, -back (and backend-specific) defaults shouldn't be documented
in -gui. Anyway
From: Pete French <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Subject: Re: Text drawing bug - gaps after 16th character in scaled view
Date: Wed, 02 Jul 2003 09:34:39 +0100
> studying it. Why? Because I have to get some .nfonts for Asian
>
> studying it. Why? Because I have to get some .nfonts for Asian
> characters somewhere or to
Do you have TTF fonts for these Asian fonts ? theres a very good prgram
called 'mknfonts' which will take a TTF and turn it into an nfont for
use with the ART backend. I tried it on a few Unicode fonts
Fred Kiefer wrote:
Kazunobu Kuriyama wrote:
In short, the art backend works fine.
At first I forgot to set GSFontAntiAlias to YES and, naturally,
got the same result as that of the xlib backend. After setting
the environmental variable correctly, the trouble has disappeared!
One thing to note:
Kazunobu Kuriyama wrote:
In short, the art backend works fine.
At first I forgot to set GSFontAntiAlias to YES and, naturally,
got the same result as that of the xlib backend. After setting
the environmental variable correctly, the trouble has disappeared!
One thing to note: Depending on the valu
Adam Fedor wrote:
> The art backend uses the same default, although in a different way.
> Perhaps someone should change the explanation ( :-) knowing that I'll
> probably have to do it).
Arguably, -back (and backend-specific) defaults shouldn't be documented
in -gui. Anyway, for -art:
A boolean v
Pete French wrote:
>
> > GSFontAntiAlias
> > A boolean value which defaults to NO. If set to YES and the X-Windows (sic)
> > system has the XFT extension, then the application will use anti-aliased fonts
> > as provided by the X-Windows (sigh) system.
>
> ...?!
>
> but 'art' doesnt use the X-Wi
On Tuesday, July 1, 2003, at 07:45 AM, Pete French wrote:
GSFontAntiAlias
A boolean value which defaults to NO. If set to YES and the
X-Windows (sic)
system has the XFT extension, then the application will use
anti-aliased fonts
as provided by the X-Windows (sigh) system.
...?!
but 'art' doesn
Pete French wrote:
GSFontAntiAlias
A boolean value which defaults to NO. If set to YES and the X-Windows (sic)
system has the XFT extension, then the application will use anti-aliased fonts
as provided by the X-Windows (sigh) system.
...?!
but 'art' doesnt use the X-Windows fonts does it ? So ho
> GSFontAntiAlias
> A boolean value which defaults to NO. If set to YES and the X-Windows (sic)
> system has the XFT extension, then the application will use anti-aliased fonts
> as provided by the X-Windows (sigh) system.
...?!
but 'art' doesnt use the X-Windows fonts does it ? So how can this
Pete French wrote:
At first I forgot to set GSFontAntiAlias to YES and, naturally,
got the same result as that of the xlib backend. After setting
the environmental variable correctly, the trouble has disappeared!
Now thats interesting. I didnt even know about the GSFontAntiAlias setting
and I hav
> At first I forgot to set GSFontAntiAlias to YES and, naturally,
> got the same result as that of the xlib backend. After setting
> the environmental variable correctly, the trouble has disappeared!
Now thats interesting. I didnt even know about the GSFontAntiAlias setting
and I havent touched i
Pete French wrote:
The bug still exists with the xlib backend. I am going to try the art
backend,
but before it, it seems I have to get .nfont packages. I would be happy
if you could tell me how to get them.
I cant remember where the official download places are, but you can just
grab my set f
Alexander Malmberg wrote:
The wiki has a couple of pages about this:
http://wiki.gnustep.org/index.php/back-art%20Installation
http://wiki.gnustep.org/index.php/nfont%20packages
- Alexander Malmberg
Thanks to you and Pete French, I installed the art backend.
I am going to report the result to
Fred Kiefer wrote:
[snip]
> The actual fix solves a problem on systems where
> unsigned int == unsigned short
> does not hold. I think that this is indendent of the endianess of the
> system (You rather expect it to fail on a 16 bit or 64 bit machine).
On little-endian systems with 16-bit shorts a
Alexander Malmberg wrote:
Yes, there must be a mismatch between the metrics reported by -xlib to
-gui and the actual width of the glyphs when drawn. I'm not very
familiar with -xlib's font code, but I had a quick look at it and fixed
one fairly obvious bug that would cause incorrect metrics to be r
> The bug still exists with the xlib backend. I am going to try the art
> backend,
> but before it, it seems I have to get .nfont packages. I would be happy
> if you could tell me how to get them.
I cant remember where the official download places are, but you can just
grab my set from http://t
Kazunobu Kuriyama wrote:
[snip]
> The bug still exists with the xlib backend. I am going to try the art
> backend,
> but before it, it seems I have to get .nfont packages. I would be happy
> if you could tell me how to get them.
The wiki has a couple of pages about this:
http://wiki.gnustep.org
Alexander Malmberg wrote:
>
>Yes, there must be a mismatch between the metrics reported by -xlib to
>-gui and the actual width of the glyphs when drawn. I'm not very
>familiar with -xlib's font code, but I had a quick look at it and fixed
>one fairly obvious bug that would cause incorrect metrics
Pete French wrote:
Does it mean that the GNUstep's code is changed, or that you changed the code
of your own program in accordance with the previous discussions so far?
GNUstep's code has changed over the weekend. So my unchanged code now runs
correctly.
Great! Thanks, GNUstep development team!!
Kazunobu Kuriyama wrote:
[snip]
> Sorry for interrupting your discussion. Here is an example demonstrating
> the "oddities" that I think Pete French is talking about.
>
> The program 'PanelTest' is just the second demo of Nicola Pero's tutorial.
> PanelTest.xwd is the image which I had on the scr
> Does it mean that the GNUstep's code is changed, or that you changed the code
> of your own program in accordance with the previous discussions so far?
GNUstep's code has changed over the weekend. So my unchanged code now runs
correctly.
> OK, I will. To do that, I need to reinstall freetype l
Pete French wrote:
xwd(1) and xwud(1) are the utilities accompanied with X11R6.
O.K. - just took a look at that. Ugh! Thats very wrong. Was that with
the ART backend or the XLIB one ?
That is the xlib backend. Though the image tells nothing about gaps
I've also experienced it with another progra
> xwd(1) and xwud(1) are the utilities accompanied with X11R6.
O.K. - just took a look at that. Ugh! Thats very wrong. Was that with
the ART backend or the XLIB one ?
> I tried it with a few fonts of different sizes, and got the same results.
> What is strange is that some applications display st
Pete French wrote:
The program 'PanelTest' is just the second demo of Nicola Pero's tutorial.
PanelTest.xwd is the image which I had on the screen. The system is
ix86/linux-gnu/gnu-gnu-gnu and the backend is xlib.
Whats an 'xwd' file and how do I view it ? I ran 'xv' but it gives me
garbage.
Sorr
> The program 'PanelTest' is just the second demo of Nicola Pero's tutorial.
> PanelTest.xwd is the image which I had on the screen. The system is
> ix86/linux-gnu/gnu-gnu-gnu and the backend is xlib.
Whats an 'xwd' file and how do I view it ? I ran 'xv' but it gives me
garbage.
> Although it ma
Pete French wrote:
(snip)
I don't recall seeing this, and I haven't had any reports of it before.
What do I need to do to see it?
I'll make up a test-case for you that demonstrates it. I see it when
using alert panels to pop-up error messages from things. Its a very
specific errror message w
> They are caused by differences between the width of the hinted metrics
> and the width of the scaled outlines. Eg. if you have a glyph for 'A' at
> 10 points, the real outline might have an advancement of 4.2 points, and
> the hinted outline might have an advancement 5 points. 16 'A':s in a row
>
Pete French wrote:
>
> > Then you would have many small gaps, so it wouldn't be as noticeable. It
> > would probably hurt performance, but I haven't done much benchmarking of
> > it.
>
> It might be interesting to try - arre the cumulative errors cause by
> errors in the hints or rounding errors
Hi all,
Because no one replies to the latest Pete French's letter until now,
let me say something.
I also have the same trouble as he got into. Until I read his email,
I believed that that's a kind of machine dependency problem. (I refrained
from talking about it because I had been busy to make
> Then you would have many small gaps, so it wouldn't be as noticeable. It
> would probably hurt performance, but I haven't done much benchmarking of
> it.
It might be interesting to try - arre the cumulative errors cause by
errors in the hints or rounding errors as it moves along the line ? If it
Pete French wrote:
[snip]
> > The text system currently draws glyphs in batches of (up to) 16. The
> > small gaps add up, so when the text system sets the position for the
> > 17th glyph explicitly (using the layout information), there'll be a big
> > gap.
>
> No easy way to fix that then - aside
[big snip]
O.K., that all makes sense.
> The text system currently draws glyphs in batches of (up to) 16. The
> small gaps add up, so when the text system sets the position for the
> 17th glyph explicitly (using the layout information), there'll be a big
> gap.
No easy way to fix that then - asi
Pete French wrote:
> I am trying to draw some text into a scaled view. The view has been scaled
> so that the same co-ordinates can always be used for drawing the diagram,
> no matter what the actual size of the view is.
>
> I find that if I render text of more than 16 characters then I get a gap
I am trying to draw some text into a scaled view. The view has been scaled
so that the same co-ordinates can always be used for drawing the diagram,
no matter what the actual size of the view is.
I find that if I render text of more than 16 characters then I get a gap
between the 16th and subseque
35 matches
Mail list logo
