Re: New release of libart/freetype-backend

[Fred Kiefer]

Alexander Malmberg 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.

> 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
> (tries to) transform the center and radius and makes a circular arc
>  in device space. My code currently builds the entire path in user
> space and transforms when drawing, so elliptical arcs are possible,
>  but this means that switching the ctm during during path
> building/drawing isn't handled properly.

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.

> 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
>  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.

> c. What exactly am I supposed to do about view flipping? Does it
> belong in the backend at all? Currently I just flip the y axis when
>  drawing text if viewIsFlipped is YES, and this seems to work.

I also have the impression that we need most flipped test in the backend
to undo conversions in gui. Perhaps we should check the output in the
PostScript file for all the different cases. When this is correct the
flipping in the backend is needed, if not, we might be able to remove
most of this.

> d. How sophisticated should my font rendering be? Should I do
> kerning and stuff in DPSshow:?

No this should be part of the gui string drawing.

> e. To get good unicode coverage with all fonts, I've implemented a
> simple fallback-font scheme. If a glyph can't be found for a
> character in the current font, it will try to find it in the global
>  fallback font and render that instead. I'm considering extending
> 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.

> f. To test various DPS features I wrote a quick DPSTest.app (heavily
>  based on GSTest.app):
>
> http://w1.423.telia.com/~u42308495/alex/DPSTest-0.3.tar.gz
>
> It probably isn't very intuitive to use, but I've found it very
> useful. Basically, tests with a 'Draw' button actually render
> something to the window, and tests that are 'Active' modify the
> gstate in some way before each draw (current color, dash pattern,
> ctm, path,...). Everything should run (though not necessarily with
> correct results) with xgps except the path analyzer (uses a backart
>  specific method to get the current path) and 'Activate' in the
> Text-test (uses charpath).

Great, this might help track down the errors in the Windows backend.

Cheers Fred