Re: New release of libart/freetype-backend

[Alexander Malmberg]

Fred Kiefer wrote:
>  > arct::::: Should be implemented in gsc. I'll probably get around to
>  > it soon.
> 
> Would be great if you could do this. But remember this is something to
> implement in NSBezierPath.

That would make it a GNUstep extension, but it seems reasonable.

>  > ashow, widthshow, awidthshow, xshow, yshow, xyshow Easy, but I want
>  > to clean the code up first to avoid excessive code duplication.
> 
> I Think we should drop all of these. Or if anybody really thinks these
> operations are useful, we should move them into gsc and implement them
> via show.
> 
>  > A few DPS-related questions:
>  >
>  > a. Arcs aren't handled properly currently. The arc needs to created
>  > in user space and then transformed to device space. The gsc code
[snip]
> What you describe are exactly the two possibilities we have for the path
> handling. Both have their drawbacks, so when we decide to switch to your
> way we will loose the PostScrips the basic drawing operations to
> NSBezierPath based operations, we can make sure that the transformation
> will not change during one path. Than your interpretation of the path
> methods will fit in perfect.

Does Quartz let you change the ctm while defining a path? Anyway, one
proper solution would be to create an arc as a new NSBezierPath object,
transform it, and manually stitch together the two paths.

>  > b. -gui doesn't seem to use strokeadjust. Should it? I already fudge
> coordinates
>  >  slightly in some cases. A lot of width 1 rectstroke:s appear at
>  > whole point compatibility our current code offers. I would not mind
> this, although it was the original reason to write the code the current
> way. When we ever move over from the PSMoveTo:: PSLine>To:: ... style of
> code ats (eg. (10,10)-(20,20)), which means that the bottom border

This part doesn't make any sense to me (in fact, it looks slightly
messed up). Could you clarify?

>  >  appears as a filled area (10,9.5)-(20,10.5), which is rendered as 50%
>  >  fill in row 9 and 10. I detect this and adjust the coordinates to revent
>  >  it. Technically, I should probably only do this (and some other related
>  >  adjustments) if strokeadjust is active, but then gui would need to
>  >  use it.
> 
> I also had a few problems here. Already the xgps backend did change the
> rectstroke co-ordinates. And I had to do this for the MS Windows backend
> also. All of this looks like a hack to me, and we should try to get rid
> of this. In the current implementation it makes a difference, if
> rectstroke is called or a path is build up with the coordinates of the
> rectangle and than stroke is called. This is wrong, or at least I think so.

If strokeadjust is on, there's nothing wrong with this, but it's ugly
and complicated to do in a consistent way. I think it'd be better if gui
was 'fixed'.

[snip]
>  > this, but I'm not sure it's the right thing to do. Should the
>  > backend try to always find a glyph for a character (with different
>  > fallback fonts for different fonts and stuff like that), or should
>  > it leave all that to -gui?
> 
> This should be done in the NSAttributedString, when a font gets assigned
> to a part of the string.

That doesn't sound like a good place to do this; I was thinking more of
NSStringDrawing. Anyway, I think I'll put a basic system there for now.
I like the idea of never having to switch fonts just because you need
some obscure glyph.
(http://w1.423.telia.com/~u42308495/alex/backart/backart_klingon2.png :)

[snip]
> Cheers Fred

- Alexander Malmberg