Rendering of fixed-width fonts
I recently posted about how the Art backend renders the supposedly fixed-width "VeraSansMono-Roman" in a non-fixed width way. For reference, here is the shot of size 12 showing a regular grid rendering on the bottom: <> The problem is not, apparently Art's; if you run FreeType's own rendering test (I think called 'ftstring' or something like that), the result is the same as the top row above. Digging further, [NSFont -widthOfString] reports that 'm' in size 12 is width of 6.0 while all other characters are 7.0. (Super-simple test program attached.) This information comes from the "advancement" info in the font. At different sizes, other characters besides 'm' are the "odd ones out". So now to the questions. First, I can't find any reference to this on the web. Is everyone rendering this font character-by-character manually? Leaving the question of what's happening in Gnome/Gtk aside, if I render in GNUstep using a call to DPSmoveto() followed by DPSshow() for every character, the problem goes away. It looks like this is what Terminal.app does. Surprisingly, on Art this is actually reasonably fast, but on Xlib performance is unacceptable. This leads to the next question -- is it possible to detect at runtime whether you are running under Art or Xlib? (So as to change rendering strategies.) Is there any more efficient way to render with regular spacing than repeated calls to moveto and show? Sllightly OT, there are no DPS commands on OS X, right? You have to use the Quartz functions, which all start with "CG"? (The API does not look as clean as DPS, but hopefully it grows on one?) Finally, does anyone have an opinion on whether a fixed-width font should have different advancements like VeraSansMono? Is this a bug in the font? None of the fonts I've tried under Xlib have the problem, and FreeMono under Art lacks the problem. I haven't seen the issue with any fonts on OS X. But the Vera fonts are supposed to be good, and look nice, so why does the monospace one have this problem? testFontWidth.m Description: Binary data thanks, Adrian ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Rendering of fixed-width fonts
On Mar 15, 2005, at 7:33 AM, Adrian Robert wrote:
This leads to the next question -- is it possible to detect at runtime
whether you are running under Art or Xlib? (So as to change rendering
strategies.)
In a way, yes. You can check for the backend contexts, like this:
if (GSClassFromName("ARTContext") != nil)
...
Is there any more efficient way to render with regular spacing than
repeated calls to moveto and show?
Try DPSxyshow and variants.
Sllightly OT, there are no DPS commands on OS X, right? You have to
use the Quartz functions, which all start with "CG"? (The API does
not look as clean as DPS, but hopefully it grows on one?)
Yes.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Rendering of fixed-width fonts
Adrian Robert wrote: First, I can't find any reference to this on the web. Is everyone rendering this font character-by-character manually? Leaving the question of what's happening in Gnome/Gtk aside, if I render in GNUstep using a call to DPSmoveto() followed by DPSshow() for every character, the problem goes away. It looks like this is what Terminal.app does. Surprisingly, on Art this is actually reasonably fast, but on Xlib performance is unacceptable. Which version of xlib is that slow? The standard one or the one using AA fonts? For the later I still have a patch lying around that should speed it up a lot, but I never had reason to dig in that. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Rendering of fixed-width fonts
On Mar 15, 2005, at 5:53 PM, Fred Kiefer wrote: Adrian Robert wrote: First, I can't find any reference to this on the web. Is everyone rendering this font character-by-character manually? Leaving the question of what's happening in Gnome/Gtk aside, if I render in GNUstep using a call to DPSmoveto() followed by DPSshow() for every character, the problem goes away. It looks like this is what Terminal.app does. Surprisingly, on Art this is actually reasonably fast, but on Xlib performance is unacceptable. Which version of xlib is that slow? The standard one or the one using AA fonts? For the later I still have a patch lying around that should speed it up a lot, but I never had reason to dig in that. AA. If you send the patch my way I'll test it and fiddle with it if need be. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Rendering of fixed-width fonts
On 2005-03-15 12:38:44 -0500 Adam Fedor <[EMAIL PROTECTED]> wrote:
On Mar 15, 2005, at 7:33 AM, Adrian Robert wrote:
This leads to the next question -- is it possible to detect at
runtime
whether you are running under Art or Xlib? (So as to change
rendering
strategies.)
In a way, yes. You can check for the backend contexts, like this:
if (GSClassFromName("ARTContext") != nil)
Thanks.
Is there any more efficient way to render with regular spacing than
repeated calls to moveto and show?
Try DPSxyshow and variants.
Ah. Attached is a patch implementing these functions in back-art. ;-)
It modifies the existing DPSshow implementation to handle DPSxyshow,
DPSxshow, and DPSyshow. Partial support is there for DPSwidthshow.
Right now I just patched ftfont-old.m since that's what I'm using
(freetype-2.1.2), and anyway this patch needs some feedback.
For one thing, I don't check the 'size' argument when deltas are
provided. I don't know where people are finding DPS documentation
that goes into this sort of detail, but the postscript docs I read
said an error is generated if 'size' isn't the same as the text
length. Should I check and throw an exception?
For another, I'm not sure when the y advancement should be used. I
guess even the Japanese are mostly writing horizontally now, at
least on computers? ;-)
Index: Source/art/ARTContext.m
===
RCS file: /cvsroot/gnustep/gnustep/core/back/Source/art/ARTContext.m,v
retrieving revision 1.27
diff -a -u -r1.27 ARTContext.m
--- Source/art/ARTContext.m 20 Jan 2005 21:35:23 - 1.27
+++ Source/art/ARTContext.m 16 Mar 2005 04:07:00 -
@@ -235,6 +235,7 @@
: (wi->has_alpha? wi->alpha + clip_x0 + clip_y0 * wi->sx : NULL) : wi->sx
color: fill_color[0]:fill_color[1]:fill_color[2]:fill_color[3]
transform: ctm
+deltas: NULL : 0 : 0
drawinfo: &DI];
UPDATE_UNBUFFERED
}
@@ -262,9 +263,11 @@
drawString: s
at: x:y
to: clip_x0:clip_y0:clip_x1:clip_y1 : CLIP_DATA : wi->bytes_per_line
+ : (wi->has_alpha? wi->alpha + clip_x0 + clip_y0 * wi->sx : NULL) : wi->sx
color: fill_color[0]:fill_color[1]:fill_color[2]:fill_color[3]
transform: ctm
-deltas: numarray : size : 1];
+deltas: numarray : size : 1
+drawinfo: &DI];
UPDATE_UNBUFFERED
}
@@ -286,9 +289,11 @@
drawString: s
at: x:y
to: clip_x0:clip_y0:clip_x1:clip_y1 : CLIP_DATA : wi->bytes_per_line
+ : (wi->has_alpha? wi->alpha + clip_x0 + clip_y0 * wi->sx : NULL) : wi->sx
color: fill_color[0]:fill_color[1]:fill_color[2]:fill_color[3]
transform: ctm
-deltas: numarray : size : 3];
+deltas: numarray : size : 3
+drawinfo: &DI];
UPDATE_UNBUFFERED
}
@@ -310,9 +315,11 @@
drawString: s
at: x:y
to: clip_x0:clip_y0:clip_x1:clip_y1 : CLIP_DATA : wi->bytes_per_line
+ : (wi->has_alpha? wi->alpha + clip_x0 + clip_y0 * wi->sx : NULL) : wi->sx
color: fill_color[0]:fill_color[1]:fill_color[2]:fill_color[3]
transform: ctm
-deltas: numarray : size : 2];
+deltas: numarray : size : 2
+drawinfo: &DI];
UPDATE_UNBUFFERED
}
Index: Source/art/ftfont.h
===
RCS file: /cvsroot/gnustep/gnustep/core/back/Source/art/ftfont.h,v
retrieving revision 1.6
diff -a -u -r1.6 ftfont.h
--- Source/art/ftfont.h 29 Feb 2004 20:45:05 - 1.6
+++ Source/art/ftfont.h 16 Mar 2005 04:08:31 -
@@ -34,6 +34,7 @@
color: (unsigned char)r : (unsigned char)g : (unsigned char)b
: (unsigned char)alpha
transform: (NSAffineTransform *)transform
+ deltas: (const float *)delta_data : (int)delta_size : (int)delta_flags
drawinfo: (struct draw_info_s *)di;
-(void) drawGlyphs: (const NSGlyph *)glyphs : (int)length
@@ -55,14 +56,6 @@
transform: (NSAffineTransform *)transform
drawinfo: (struct draw_info_s *)di;
-/* TODO: see if this is really necessary */
--(void) drawString: (const char *)s
- at: (int)x:(int)y
- to: (int)x0:(int)y0:(int)x1:(int)y1:(unsigned char *)buf:(int)bpl
- color:(unsigned char)r:(unsigned char)g:(unsigned char)b:(unsigned char)alpha
- transform: (NSAffineTransform *)transform
- deltas: (const float *)delta_data : (int)delta_size : (int)delta_flags;
-
-(void) outlineString: (const char *)s
at: (float)x : (float)y
gstate: (void *)func_param;
Index: Source/art/ftfont-old.m
===
RCS file: /cvsroot/gnustep/gnustep/core/back/Source/art/ftfont-old.m,v
retrieving revision 1.1
diff -a -u -r1.1 ftfont-old.m
--- Source/art/ftfont-old.m 11 Jan 2005 15:02:29 - 1.1
+++ Source/art/ftfont-old.m 16 Mar 2005 04:08:32 -
@@ -874,17 +874,12 @@
/* TODO: the current point probably needs updating after drawing is done */
--(void) drawString: (const char *)s
- at: (int)x:(int)y
- to: (int)x0:(int)y0:(int)x1:(int)y1:(unsigned char *)buf:(int)bpl
- color:(unsigned char)r:(unsigned char)g:(unsigned char
Re: Rendering of fixed-width fonts
On Mar 15, 2005, at 9:57 PM, Adrian Robert wrote: Ah. Attached is a patch implementing these functions in back-art. ;-) It modifies the existing DPSshow implementation to handle DPSxyshow, DPSxshow, and DPSyshow. Partial support is there for DPSwidthshow. Right now I just patched ftfont-old.m since that's what I'm using (freetype-2.1.2), and anyway this patch needs some feedback. Well, I may have led you astray. I think we were trying to make these functions obsolete. Although, I'm not sure why now. If you find they make a big speed improvement, I suppose we could reconsider ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Rendering of fixed-width fonts
On Tue, 15 Mar 2005 22:12:02 -0700, Adam Fedor <[EMAIL PROTECTED]> wrote: > > On Mar 15, 2005, at 9:57 PM, Adrian Robert wrote: > > > > Ah. Attached is a patch implementing these functions in back-art. ;-) > > > > It modifies the existing DPSshow implementation to handle DPSxyshow, > > DPSxshow, and DPSyshow. Partial support is there for DPSwidthshow. > > Right now I just patched ftfont-old.m since that's what I'm using > > (freetype-2.1.2), and anyway this patch needs some feedback. > > > > > Well, I may have led you astray. I think we were trying to make these > functions obsolete. Although, I'm not sure why now. If you find they > make a big speed improvement, I suppose we could reconsider Hmmm, I didn't know any attempt to make DPS functions obsolete so I keep using them a lot :( BTW, it seems PSops still working on OSX last time I tried them on jaguar, but they are buggy and I have no idea about panther. -- __ Banlu Kemiyatorn / /\ \ Free Software Yogi | / \ | -_-~-_-~-_-~-_-~-_-~-_-~-_-~-_ | /\ | QSTORAD, Qing Shan Tian Xia \/ \/ 136 Nivesana 7, Jangwattana 14 QingShanLaksi, Bangkok, Thailand 10210 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Rendering of fixed-width fonts
On Tue, 15 Mar 2005 23:57:45 -0500, Adrian Robert <[EMAIL PROTECTED]> wrote: > For another, I'm not sure when the y advancement should be used. I > guess even the Japanese are mostly writing horizontally now, at > least on computers? ;-) I have seen a *lot* of japanese text in the field of publishing that use vertical layout. http://www.w3.org/TR/css3-text/ -- __ Banlu Kemiyatorn / /\ \ Free Software Yogi | / \ | -_-~-_-~-_-~-_-~-_-~-_-~-_-~-_ | /\ | QSTORAD, Qing Shan Tian Xia \/ \/ 136 Nivesana 7, Jangwattana 14 QingShanLaksi, Bangkok, Thailand 10210 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Rendering of fixed-width fonts
On Tue, 15 Mar 2005 09:33:08 -0500, Adrian Robert
<[EMAIL PROTECTED]> wrote:
> First, I can't find any reference to this on the web. Is everyone
> rendering this font character-by-character manually? Leaving the
> question of what's happening in Gnome/Gtk aside, if I render in GNUstep
> using a call to DPSmoveto() followed by DPSshow() for every character,
> the problem goes away. It looks like this is what Terminal.app does.
> Surprisingly, on Art this is actually reasonably fast, but on Xlib
> performance is unacceptable.
Since pango is integrating with cairo.. Owen may wanna do like this..
typedef struct {
unsigned longindex;
double x;
double y;
} cairo_glyph_t;
void
cairo_show_glyphs (cairo_t *cr, cairo_glyph_t *glyphs, int num_glyphs);
I think GS normally use GSShowGlyphs, so it needs to do moveto only once
to render some glyphs. Though it didn't passed point values so you need
one moveto for each call. May be passing addition informations on x,y along
with the glyph stream in some cases is a good idea esp for future typesetters
(eg. vertical) to be less depending on back-end? Please correct me.
--
__ Banlu Kemiyatorn
/ /\ \ Free Software Yogi
| / \ | -_-~-_-~-_-~-_-~-_-~-_-~-_-~-_
| /\ | QSTORAD, Qing Shan Tian Xia
\/ \/ 136 Nivesana 7, Jangwattana 14
QingShanLaksi, Bangkok, Thailand 10210
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Rendering of fixed-width fonts
On Mar 16, 2005, at 5:12 AM, Banlu Kemiyatorn wrote: On Tue, 15 Mar 2005 23:57:45 -0500, Adrian Robert <[EMAIL PROTECTED]> wrote: For another, I'm not sure when the y advancement should be used. I guess even the Japanese are mostly writing horizontally now, at least on computers? ;-) I have seen a *lot* of japanese text in the field of publishing that use vertical layout. Well, my confusion was this: since, at least in Chinese and Japanese, the same font can be used for either horizontal or vertical layout (correct me if I'm wrong here), and presumably has both x and y advancements set nonzero, how should a PS command like moveshow(txt) know to advance the point vertically or horizontally per character? The current implementation in Art just assumes horizontal. It seems like some type of layout preference info would need to be passed from a higher level. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Rendering of fixed-width fonts
On Mar 16, 2005, at 12:57 AM, Banlu Kemiyatorn wrote:
On Tue, 15 Mar 2005 22:12:02 -0700, Adam Fedor <[EMAIL PROTECTED]> wrote:
On Mar 15, 2005, at 9:57 PM, Adrian Robert wrote:
Ah. Attached is a patch implementing these functions in back-art.
;-)
It modifies the existing DPSshow implementation to handle DPSxyshow,
DPSxshow, and DPSyshow. Partial support is there for DPSwidthshow.
Right now I just patched ftfont-old.m since that's what I'm using
(freetype-2.1.2), and anyway this patch needs some feedback.
Well, I may have led you astray. I think we were trying to make these
functions obsolete. Although, I'm not sure why now. If you find they
make a big speed improvement, I suppose we could reconsider
It's true that I saw these particular functions (DPS{x,y,xy}show)
deprecated in the NSGraphicsContext documentation. I couldn't find
indication of why though, either here or on the web relating to DPS in
general. But they seem to provide useful functionality that doesn't
directly duplicate something else, and are not hard to implement, so
why not leave them?
Hmmm, I didn't know any attempt to make DPS functions obsolete
so I keep using them a lot :( BTW, it seems PSops still working
on OSX last time I tried them on jaguar, but they are buggy and I
have no idea about panther.
I tried this on Panther but I just get "blank" rendering. ;) Or do I
need to do something in addition to:
NSGraphicsContext *ctxt = [NSGraphicsContext currentContext];
DPSgsave(ctxt);
[font set];
[color set];
PSmoveto(x,y);
PSshow(txt);
PSstroke();
DPSrestore(ctxt);
I also tried throwing a PSflush() in, and anyway the window is flushed
later, which works on GNUstep.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Rendering of fixed-width fonts
Adrian Robert wrote: On 2005-03-15 12:38:44 -0500 Adam Fedor <[EMAIL PROTECTED]> wrote: On Mar 15, 2005, at 7:33 AM, Adrian Robert wrote: Is there any more efficient way to render with regular spacing than repeated calls to moveto and show? Try DPSxyshow and variants. Ah. Attached is a patch implementing these functions in back-art. ;-) It modifies the existing DPSshow implementation to handle DPSxyshow, DPSxshow, and DPSyshow. Partial support is there for DPSwidthshow. Right now I just patched ftfont-old.m since that's what I'm using (freetype-2.1.2), and anyway this patch needs some feedback. Not sure if this patch is really needed. I remember moving the implementation of these methods up to the GSC level. So removing the current art implementation should give the full behaviour. Perhaps not optimized for speed, but as we want to get rid of them anyway, it should do. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Rendering of fixed-width fonts
On Mar 16, 2005, at 4:45 PM, Fred Kiefer wrote: Adrian Robert wrote: On 2005-03-15 12:38:44 -0500 Adam Fedor <[EMAIL PROTECTED]> wrote: On Mar 15, 2005, at 7:33 AM, Adrian Robert wrote: Is there any more efficient way to render with regular spacing than repeated calls to moveto and show? Try DPSxyshow and variants. Ah. Attached is a patch implementing these functions in back-art. ;-) It modifies the existing DPSshow implementation to handle DPSxyshow, DPSxshow, and DPSyshow. Partial support is there for DPSwidthshow. Right now I just patched ftfont-old.m since that's what I'm using (freetype-2.1.2), and anyway this patch needs some feedback. Not sure if this patch is really needed. I remember moving the implementation of these methods up to the GSC level. So removing the current art implementation should give the full behaviour. Perhaps not optimized for speed, but as we want to get rid of them anyway, it should do. OK, I see in GSGState.m the DPSxyshow family is implemented, yet plain DPSshow is left to the subclass. Accordingly, in Art, DPSshow gets its own implementation. It seems like there are merits both to consolidating backend code as much as possible in GSC and in allowing individual backends to handle things in a way more optimal for their nature. But wherever this decision ends up for DPSshow for a particular backend, DPSxshow etc. should be in the same place, since their implementations are so similar (only difference is advancements between glyphs, which is a very small fraction of the code). Or is the split relating to the desire to deprecate [xy|x|y|width]show? I still can't find any reference on the web as to why, whether searching for DPS or just regular postscript. These operators continue to be actively supported in recent Ghostscript, for instance. Since they are useful at least for dealing sanely with monospaced fonts that are not monospaced, such as VeraSansMono-Roman, and the implementations are all there (assuming some form of this patch can be accepted), could we just undeprecate them? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Rendering of fixed-width fonts
On Mar 17, 2005, at 9:27 AM, Adrian Robert wrote: Since they are useful at least for dealing sanely with monospaced fonts that are not monospaced, such as VeraSansMono-Roman, and the implementations are all there (assuming some form of this patch can be accepted), could we just undeprecate them? Sure. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Rendering of fixed-width fonts
Adrian Robert wrote: On Mar 16, 2005, at 5:12 AM, Banlu Kemiyatorn wrote: On Tue, 15 Mar 2005 23:57:45 -0500, Adrian Robert <[EMAIL PROTECTED]> wrote: For another, I'm not sure when the y advancement should be used. I guess even the Japanese are mostly writing horizontally now, at least on computers? ;-) How very gaijin of you. How very gwailo of you. I have seen a *lot* of japanese text in the field of publishing that use vertical layout. Well, my confusion was this: since, at least in Chinese and Japanese, the same font can be used for either horizontal or vertical layout (correct me if I'm wrong here), and presumably has both x and y advancements set nonzero, how should a PS command like moveshow(txt) know to advance the point vertically or horizontally per character? The current implementation in Art just assumes horizontal. It seems like some type of layout preference info would need to be passed from a higher level. Welcome to the wonderful world of complex script layout. Truth is, it needs to be much more complicated than just "preference info". If Chinese & Japanese are confusing you, just wait til you hit Farsi! Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Rendering of fixed-width fonts
Sheldon Gill wrote: Adrian Robert wrote: On Mar 16, 2005, at 5:12 AM, Banlu Kemiyatorn wrote: On Tue, 15 Mar 2005 23:57:45 -0500, Adrian Robert <[EMAIL PROTECTED]> wrote: For another, I'm not sure when the y advancement should be used. I guess even the Japanese are mostly writing horizontally now, at least on computers? ;-) How very gaijin of you. How very gwailo of you. I have seen a *lot* of japanese text in the field of publishing that use vertical layout. Well, my confusion was this: since, at least in Chinese and Japanese, the same font can be used for either horizontal or vertical layout (correct me if I'm wrong here), and presumably has both x and y advancements set nonzero, how should a PS command like moveshow(txt) know to advance the point vertically or horizontally per character? The current implementation in Art just assumes horizontal. It seems like some type of layout preference info would need to be passed from a higher level. Welcome to the wonderful world of complex script layout. Truth is, it needs to be much more complicated than just "preference info". If Chinese & Japanese are confusing you, just wait til you hit Farsi! or Arabic, or Hebrew :) RTL scripts in general are a PITA to implement/support :) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
